Active Directory Funktionen - Neue Version 1.5.0.0 freigegeben!

    ADFind hatte ich mir auch schon angeschaut. Was mich aber zu LDAPSearch brachte, war die geringere Größe der Datei (308KB) im Vergleich zu 1,2MB bei ADFind. Auch bekomme ich die Fehlermeldung von ADFind nicht so vollständig wie von LDAPSearch.
    Meine ADFind Meldung bei ungültiger Anmeldeinformation sieht wie folgt aus:

    Code
    H:\tools\ADFind>adfind -h "DC.DOMAIN.COM" -u "DOMAIN\user" -up passwort -simple -exterr -maxe 1 -s sub (samaccountname=xyz)


AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010


LDAP_BIND: [DC.DOMAIN.COM] Error 0x31 (49) - Ung³ltige Anmeldeinformationen
Extended Error: No extended error info available.
Terminating program.


    Kann das am Betriebssystem liegen (XP SP 2)? Oder verwendet LDAPFind auch DLLs des Betriebssystemes?

    Also bei mir siehts so aus:

    Code
    adfind.exe -h IP.ADRESSE -u DOMAIN\USER -up passwort-falsch -simple -exterr -maxe 1 -s sub (samaccountname=xyz)


AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010


LDAP_BIND: [172.17.89.196] Error 0x31 (49) - Ung³ltige Anmeldeinformationen
Extended Error: (80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece)
Terminating program.

    Ich hab allerdings auch erst ein wenig mit den Anmeldeverfahren rumgespielt und festgestellt, daß nur bei -simple die Meldungen überhaupt zurück kamen - auch der Netzwerksniffer bestätigte mir dieses Verhalten.
    Wenn du bei LDAPsearch die gesamten dlls, die du auch alle mit "verpacken" müsstest, dazurechnest, dann kommst du bei weit mehr wie die 1,2MB raus.
    Kopier mal die ldapsearch in ein separates Verzeichnis und starte sie einfach, dann kopier die dlls, welche dir die Fehlermeldungen hintereinander ausspucken, mal dazu und dann schau dir mal die Größe an.

    Eventuell hast du aber eine andere ldapsearch.exe wie ich gefunden, eventuell läuft deine auch eigenständig, kannste mir die mal zukommen lassen - ich würds mit der auch mal testen.
    Vielleicht läuft diese auch mit x64-Rechnern wie meinem....

    Ach und noch eine Vermutung, gegen welches LDAP testest du das? Active Directory (2000, 2003 oder 2008) oder ein LINUX-LDAP?
    Es kann hierbei auch hilfreich sein, die LDAP-Protokollversion manuell auf 3 zu setzen (ist nur ne Vermutung, bei meinen Tests hat dies die adfind.exe automatisch gemacht - hat mir der Netwerksniffer verraten).
    Falls du selbst keinen im Einsatz hast, google mal nach "netzwerkmonitor microsoft", der ist dafür prima geeignet. Den kannste auch auf einem anderen als deine Testrechner installieren, er muss nur im gleichen Subnetz hängen, und du musst im Sniffer deine Netzwerkkarte markieren und "P-Mode" aktivieren - dann hört er auf alle Datenpakete, die innerhalb deines Subnetzes herumschwirren. Dann noch "New capture tab..." anklicken und darin unter "Capture Filter" einen Eintrag sinngemäß " Destination == "IP.Testrechner" OR Source == "IP.Testrechner" " (ohne die äußeren" ") setzen und in dem Tab auf Apply drücken. Anschließend oben in der Mitte auf Start - etwas warten - vom Testrechner aus die Anmeldung testen - danach auf Stop - etwas warten, bis alles verarbeitet und dann die Zeilen durchschauen...

    Einmal editiert, zuletzt von card0384 (10. April 2010 um 09:04)

    Zitat von card0384

    Wenn du bei LDAPsearch die gesamten dlls, die du auch alle mit "verpacken" müsstest, dazurechnest, dann kommst du bei weit mehr wie die 1,2MB raus.
    Kopier mal die ldapsearch in ein separates Verzeichnis und starte sie einfach, dann kopier die dlls, welche dir die Fehlermeldungen hintereinander ausspucken, mal dazu und dann schau dir mal die Größe an.

    Eventuell hast du aber eine andere ldapsearch.exe wie ich gefunden, eventuell läuft deine auch eigenständig, kannste mir die mal zukommen lassen - ich würds mit der auch mal testen.
    Vielleicht läuft diese auch mit x64-Rechnern wie meinem....

    Du hast Recht. Ich habe alle von LDAPSEARCH angemeckerten DLLs in ein Verzeichnis kopiert und stehe nun bei 22,5MB - es läuft aber noch nicht und bringt nur den Fehler "Context Initialization Error". Es handelt sich dabei um das LDAPSEARCH von Oracle 10.2. Ich dachte, es wäre ein schönes kleines Standalone Tool analog zu ADFind, nur kleiner.
    Wegen der Größe und der vielen notwendigen DLLs ist es daher gestorben!

    Das Problem der fehlenden extended error information habe ich nun gefunden: Einfach -maxe 1 weglassen.

    Ich werde das AD UDF nun auf ADFind umschreiben und mit der nächsten Version freigeben.
    Vielen Dank für Deine Forschungsarbeit!

    Gern geschehen - keine Ursache...

    Komisch, bei mir klappts auch mit maxe 1 - na vielleicht findest du ne andere Lösung, das Ergebniss im Erfolgsfalle auf einen Rückgabestring zu reduzieren...
    Man könnte z.B. den Namen der DCs abfragen o.ä....

    Jetzt häng ich auch grad wieder fest - ich hab nen Test-Rechner XP-SP3, bei dem spuckt das ADFind die extended-Errors auch nicht aus - obwohl ich befehlstechnisch nichts anders mache - auch mit ohne maxe 1 o.ä. klappts nicht.
    Der Netzwerksniffer bringt den data 525-Error, aber das adfind meint "no extended error...", sprich es verwirft die zurückgegebene Errormeldung.

    Hast du zufällig noch was anders gemacht, damit der error-String zurück kommt?

    Zitat von card0384

    Jetzt häng ich auch grad wieder fest - ich hab nen Test-Rechner XP-SP3, bei dem spuckt das ADFind die extended-Errors auch nicht aus - obwohl ich befehlstechnisch nichts anders mache - auch mit ohne maxe 1 o.ä. klappts nicht.
    Der Netzwerksniffer bringt den data 525-Error, aber das adfind meint "no extended error...", sprich es verwirft die zurückgegebene Errormeldung.

    Hast du zufällig noch was anders gemacht, damit der error-String zurück kommt?

    Genau dieses Problem hatte ich am Wochenende auch. Ich wollte das schlechte Wetter nutzen um diesen Punkt abzuschliessen und musste auch feststellen, dass ADFind die Extended Error Information ausgibt wie der Blinker meines Autos: geht - geht nicht - geht ...
    Ich habe noch kein System entdeckt, wann er die Daten bringt und wann nicht. Im Netzwerksniffer sehe ich die extended errors, aber ADFind bringt sie nicht.
    Da braucht es noch mehr Forschung, aber ich bin nächste Woche im Urlaub.

    Na dann wünsch ich dir einen schönen Urlaub, ich hab mit meinem very bad english dem Entwickler (Joe) mal ne Mail geschrieben - mal sehen ob/wann/wie er antwortet...
    Eine Vermutung hätte ich noch, die Rechner, von denen es aus nicht geht, bekommen ihre Return-Meldung sehr schnell zurück (vielleicht zu schnell), der PC von dem aus es geht, hat nen längeren IP-Weg...

    Dann werden wir wohl inzwischem mal weiter nach nem Tool suchen müssen...
    Der adfind-Entwickler hat auch ein Tool auth.exe liegen, dieses wäre für uns prima geeignet (nur 308kb groß). Kannst du ihm mal schreiben, ob er in dieses Tool den exterr-Switch mit einbaut?
    card

    Zitat von card0384

    Na dann wünsch ich dir einen schönen Urlaub, ich hab mit meinem very bad english dem Entwickler (Joe) mal ne Mail geschrieben - mal sehen ob/wann/wie er antwortet...

    Ich hatte auch schon mal ne Frage an ihn gerichtet (keine Ahnung mehr um was es ging) und er hat ziemlich pronto geantwortet.
    Sollte er bis nach meinem Urlaub nicht reagiert haben, dann prüfe ich mal auth.exe bzw. suche mal intensiv im Internet nach weiteren tools.
    Irgendwann werden wir das Problem schon lösen.

    Was anderes: Sagt dir die Methode ADSGetLastError was? Scroll mal runter zum Text "80071392". Die vom Beispielcode ausgegebene Fehlermeldung sieht doch verdächtig nach dem aus, was wir brauchen.

    die auth.exe hab ich schon getestet - die aktuellste ist schon älteren Datums und hat definitv nicht den exterr-Schalter.

    Die wäre am besten für unser Vorhaben geeignet - noch besser wie die adfind.exe (weil kleiner)...
    Eine Anfrage kann nicht schaden - ich hab aber schon wegen der adfind.exe gestern angefragt - daher wäre es prima, wenn jemand anders ihn wegen der exterr-Erweiterung der auth.exe befragen kann..

    Zitat von card0384

    die auth.exe hab ich schon getestet - die aktuellste ist schon älteren Datums und hat definitv nicht den exterr-Schalter.

    Die wäre am besten für unser Vorhaben geeignet - noch besser wie die adfind.exe (weil kleiner)...
    Eine Anfrage kann nicht schaden - ich hab aber schon wegen der adfind.exe gestern angefragt - daher wäre es prima, wenn jemand anders ihn wegen der exterr-Erweiterung der auth.exe befragen kann..

    Anfrage bei Joe ist gestellt! Warten wir mal ab...

    Antwort ist schon da:

    Zitat

    AUTH isn’t using LDAP for the authentication, it using LogonUser which is RPC based which doesn’t have any extended error info.

    Ich habe nun gleich die Frage nach der fehlenden extended error information von ADFind nachgeschoben.

    Hier meine Antwort zum exterr-Switch:

    The bug is in the LDAP library. AdFind doesn’t look at what is coming in the network traffic stream, it asks for the information from the LDAP API. AdFind doesn’t do anything special at the LDAP client level based on OS levels so if you see something working in one OS level but not in another, it is due to how the underlying libraries are working. If you specify the -exterr switch, it simply asks the LDAP API, hey do you have any more error info for me to display? Whatever the OS provides, AdFind displays.

    Heist soviel wie - kann er auch nichts machen - liegt an den dlls, die er anspricht...

    Ich sag nur, na Klasse - das würde ja bedeuten, wir kommen diesbzgl. nie weiter...

    Ich hab mal weiter gesucht und unter https://autoit.de/www.ldapbrowser.com gibts den ldapbrowser zum download. Der kann die exterror-Meldungen auch auf meinem Test-PC wiedergeben, wo da adfind es nicht kann. Nach genaueren Tests denke ich aber, das der ldapbrowser seine eigenen dlls mitbringt, welche die Verbindung realisieren und entsprechend auch die error-Meldungen abfangen...
    Ich weiß nicht, ob man sich dort "reinhacken" kann, die dll findet, die den ldap-bind macht und diese dazu bewegen kann, direkt aus Autoit heraus die Abfrage zu starten...

    Einmal editiert, zuletzt von card0384 (15. April 2010 um 10:17)

    Zitat von card0384

    Hier meine Antwort zum exterr-Switch:

    The bug is in the LDAP library. AdFind doesn’t look at what is coming in the network traffic stream, it asks for the information from the LDAP API. AdFind doesn’t do anything special at the LDAP client level based on OS levels so if you see something working in one OS level but not in another, it is due to how the underlying libraries are working. If you specify the -exterr switch, it simply asks the LDAP API, hey do you have any more error info for me to display? Whatever the OS provides, AdFind displays.

    Heist soviel wie - kann er auch nichts machen - liegt an den dlls, die er anspricht...

    Ich sag nur, na Klasse - das würde ja bedeuten, wir kommen diesbzgl. nie weiter...

    Sieht mühsam aus, ja.
    Was mich nur stutzig macht: ADFind hat ja schon mal Meldungen geliefert. Und an den Libraries hat sich doch seither nichts geändert?
    Ich habe noch mit ADsGetLastError gespielt:

    [autoit]

    #include <AD.au3>
    _AD_Open("testuser","falschesPasswort")
    $R = _AD_FQDNToSamAccountName("CN=User,OU=Unit,DC=microsoft,DC=com")
    $EC = DllStructCreate("DWord")
    $ED = DllStructCreate("wchar[256]")
    $PN = DllStructCreate("wchar[256]")
    $R = DllCall("Activeds.dll","DWORD","ADsGetLastError","ptr",DllStructGetPtr($EC),"ptr",DllStructGetPtr($ED),"DWORD",256,"ptr",DllStructGetPtr($PN),"DWORD",256)
    ConsoleWrite("EC: " & DllStructGetData($EC,1) & @CRLF)
    ConsoleWrite("ED: " & DllStructGetData($ED,1) & @CRLF)
    ConsoleWrite("PN: " & DllStructGetData($PN,1) & @CRLF)
    _AD_close()
    Exit

    [/autoit]

    Liefert schön die letzte Fehlermeldung - auch mit extended data. Aber derzeit leider nicht in allen Fällen sondern nur wenn die Userid nicht als Domäne\User angegeben wird.
    Aber vielleicht kommen wir hier weiter?

    Ich will die Vorfreude nicht bremsen, aber Activeds.dll gibt die Fehlermeldungen genau so zurück wie adfind.exe - also auf meinem W2008 gehts und auf meinem W-XP-SP3 gehts nicht - gleiches Script...
    Edit - noch ein Test, mit W2003 gehts auch nicht...

    Diese dll ist also auch nicht der Stein des Weißen - man müsste die dlls des ldapbrowsers ansprechen können - aber wie kommt man an die Aufrufroutinen?

    Einmal editiert, zuletzt von card0384 (15. April 2010 um 16:21)

    Zitat von card0384

    Ich will die Vorfreude nicht bremsen, aber Activeds.dll gibt die Fehlermeldungen genau so zurück wie adfind.exe - also auf meinem W2008 gehts und auf meinem W-XP-SP3 gehts nicht - gleiches Script...
    Edit - noch ein Test, mit W2003 gehts auch nicht...

    Diese dll ist also auch nicht der Stein des Weißen - man müsste die dlls des ldapbrowsers ansprechen können - aber wie kommt man an die Aufrufroutinen?

    Ich sehe das so:

    • Manche Meldungen kriegen wir, manche nicht. Nach welchem Schema das abläuft, ist mir noch nicht klar.
    • Mit ADsGetLastError hätten wir sowohl das Performance-Problem als auch das Problem eines externen Programmes im Griff.

    Nach dem Urlaub - und an einem verregneten Tag - starte ich nochmals eine Testserie auf Windows XP und W7. Mal schauen, ob ich hinter die Logik komme :huh:

    Zitat von card0384

    Da hast du recht - mich wundert nur, warum noch keiner im großen google das gleiche Problem bemerkt hat...

    Also wenn ich mir so die Skripte anschaue die ich bei meinen Google Recherchen so finde, dann vermute ich, dass ganz, ganz, ganz wenige Leute nach dem Aufruf eines Befehles überhaupt prüfen, ob Fehler aufgetreten sind.
    Entweder sind wir die einzigen die so neugierig sind oder alle anderen haben es gecheckt - nur wir nicht ;)

    Vermutlich reichen den paarn die Rückinfos, obs geht oder nicht. Nur warum es nicht geht, daß scheint keinen zu interessieren.
    Ich seh allerdings viele sich mit dem Problem in Verbindung mit java und WebProgrammierung rumschlagen...
    Ich hab joe mal auf den ldapbrowser angesetzt, bei dem bekomm ich immer die Rückinfo - vermutlich, weil der seine eigenen dlls mitbringt.
    Vielleicht checkt joe, was der ldapbrowser anders macht...

    Was mir bei Tests noch aufgefallen war, die ADsGetLastError-Abfrage erzeugt keinen IP-Traffic, also die Information wird wirklich vom Memory-Stack der API, die vorher die LDAP-Abfrage iniziiert hat, abgefragt.
    Da scheint dabei schon das Problem zu liegen...
    Die WLDAP32.DLL sieht auch diese Abfrage vor, nur leider hab ichs nicht geschafft, mittels DLL-Call die Info aus ihr rauszukitzeln.

    Mein Codeausschnitt

    [autoit]


    Const $LDAP_AUTH_SIMPLE = 0x80
    Global $ldapldll = DllOpen("WLDAP32.DLL")

    [/autoit][autoit][/autoit][autoit]

    Func ldapinit()
    $Hostptr = DllStructCreate("char[" & (StringLen($Host) + 1) & "]")
    DllStructSetData($Hostptr,1,$Host)
    $fkt = "ldap_open"
    Return DllCall($ldapldll, "ptr", $fkt, "ptr",DllStructGetPtr($Hostptr), "ULONG", "")
    EndFunc

    [/autoit][autoit][/autoit][autoit]

    Func ldap_simple_bind_s()
    $fkt = "ldap_simple_bind_s"
    $dn = DllStructCreate("char[" & (StringLen($domain & "\" & $username) + 1) & "]")
    DllStructSetData($dn,1, $domain & "\" & $username)
    $passwd = DllStructCreate("char[" & (StringLen($Passwort) + 1) & "]")
    DllStructSetData($passwd,1, $Passwort)
    Return DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "ptr",DllStructGetPtr($dn), "ptr",DllStructGetPtr($passwd), "ULONG", $LDAP_AUTH_SIMPLE)
    EndFunc

    [/autoit][autoit][/autoit][autoit]

    Func ldap_get_option()
    $ldaperr = DllStructCreate("ULONG")
    ;DllStructSetData($ldaperr,1, 0)
    $fkt = "ldap_get_option"
    ;$ldaperr = 0
    ;$ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x11, "ptr", DllStructGetPtr($ldaperr))
    $ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x32, "ptr", DllStructGetPtr($ldaperr))
    $ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x33, "ptr", DllStructGetPtr($ldaperr))
    $ergebnis = DllCall($ldapldll, "DWORD", $fkt, "ptr", $ldapinit[0], "int", 0x34, "ptr", DllStructGetPtr($ldaperr))
    $ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x30, "ptr", DllStructGetPtr($ldaperr))

    [/autoit]


    bringt mir eine erfolgreiche Anmeldung, aber als Returncode, bzw. $ldaperr kommt immer nur Kauderwelsch.. Vielleicht hast du ne Idee, wie man die WLDAP32 dazu bekommt, den extended Returnstring auszuspucken..
    Vielleicht ist die WLDAP32 auch der Schlüssel, um immer eine Returnmeldung zu bekommen - wenn sie denn mal eine ausspuckt. Die 0x30-0x34 sind die Parameter, die die verschiedenen Returns ausspucken...
    Const $LDAP_OPT_ERROR_NUMBER = 0x31
    Const $LDAP_OPT_ERROR_STRING = 0x32
    Const $LDAP_OPT_SERVER_ERROR = 0x33
    Const $LDAP_OPT_SERVER_EXT_ERROR = 0x34
    Const $LDAP_OPT_PROTOCOL_VERSION = 0x11

    3 Mal editiert, zuletzt von card0384 (16. April 2010 um 08:51)

    Bin aus dem Urlaub zurück :(
    Sobald ich Zeit finde, spiele ich mal ein bischen damit rum. Obwohl ich sagen muss, dass ich von der DLL-Geschichte sehr, sehr wenig Ahnung habe.

    P.S. Hast Du ne Ahnung, warum Du hier von ADFind die Extended Error Information wie gewünscht kriegst und dann später nicht mehr? Was hat sich geändert? Welches OS hast Du da verwendet?

    Hi Water - wie wars im Urlaub?

    Zitat von water

    Hast Du ne Ahnung, warum Du hier von ADFind die Extended Error Information wie gewünscht kriegst und dann später nicht mehr? Was hat sich geändert? Welches OS hast Du da verwendet?

    Ich hab dies mit meinem W2008-Server getestet - dort bekomm ich sie auch immer noch zurück - ist aber leider der einzige, wo es geht - die gleichen Scripte bei W2003 oder W-XP bringen keine Rückmeldung, trotzt Rückmeldung im Sniffer - also sie ist da, nur die WLDAP32 gibt sie nicht mehr aus...
    Mein W2008 ist übrigens 64bit, die anderen OS sind 32bit - weiß nicht, ob es von Bedeutung ist...

    Ich habe inzwischen mal den Support von ldapbrowser.com angeschrieben - hier die Antwort:

    Dies habe ich an joe weitergegeben - seine Antwort:


    Joe hatte mir in einer früheren Mail bestätigt, daß er WLDAP32 verwendet - daher wird es hier keine Lösung für unser Problem geben - man müsste von https://wiki.mozilla.org/LDAP_C_SDK das SDK kompilen zu ner DLL oder EXE mit nur den von uns benötigten Funktionen oder noch besser, in deren Quellcode (ist im SDK dabei) sehen, wie die das machen und ob man dies in Autoit nachstellen kann - aber dies übersteigt meinen Horizont etwas.
    Kannst dir das SDK ja mal ziehen - es wird nur in ein Verzeichniss entpackt, da ist alles drin, was ldapbrowser.com verwendet, um die Rückinfo aus dem System zu kitzeln...