Beiträge 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...

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...

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..

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

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?

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.ä....

Also bei mir siehts so aus:

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...

Wenn ichs mir richtig bedenke, werde ich die "Erstanmeldung" generell über diese adfind.exe laufen lassen (solange es keine Lösung aufgrund meines Bugreports direkt aus Autoit gibt).
Erst wenn die Ausgabe keinen Fehler zurück gibt, werde ich die AD-Funktionen mittels ADODB-Conn nutzen, um die Gruppenmitgliedschaft meiner Nutzer zu bestimmen und in Abhängigkeit dessen weitere Anmeldespezifikationen zu setzen. Damit reduziert sich die Fehlerquelle erheblich und die adfind.exe ist sehr flink.

Damit bin ich nun in der Lage, dem Benutzer eine definierte Menge Terminalserver vorzusetzen oder ihn abzuweisen oder direkt einen Terminalserverzugang zu starten, um ihm zu ermöglichen, sein Passwort neu zu setzen, falls abgelaufen. Die Passwort-Setzerei, wenn abgelaufen (error 773 oder 532) hab ich noch nicht mittels anderer Möglichkeiten setzen können, wie mit einem Terminalserverzugangslink.
Kennst du da ne andere Lösung?

Hi water,

die variante mit dem externen ldapsearch ist wirklich ein Krückstock - aus mehreren Varianten heraus:
1. ich setze W2008 64bit ein und ich bekomme keine funktionierende ldapsearch.exe, die bei mir läuft - hab mich schon totgegoogelt
2. ich muss mein autoit-script, wenns denn später ne exe wird, auf viele Rechner (die Mitarbeiter meiner Firma, die sich von zu Hause aus einwählen wollen) verteilen. ldapsearch.exe startet, wenn überhaupt, nur mit 5-6 dll-Dateien, die allle samt in meine exe mit includiert werden müssen - dies ist viel Aufwand und birgt noch mehr Fehlerquellen (siehe auch 1.)
3. da du die ldapsearch.exe nicht mit in deinem udf verteilen kannst (copyright etc.) ist es nicht wirklich udf-geeignet...
4. ich greife (aufgrund 2.) auf das LDAP von außen ohne DNS-Namensauflösung, nur mittels IP-Verbindung zu, das ldapsearch scheint damit ein Problem zu haben...

Die eigentliche Idee, die du da aber verfolgt hast, fand ich gut - unabhängig davon, das der Einsatz externer exe'n im Rahmen eines udfs problematisch ist. Ich hab bei meiner googelei aber ne eigenständige exe -> klick mich <- gefunden, die 1. auch in x64-Rechnern läuft und 2. freeware ist.

Wenn du diese mittels:

adfind -h "IP-Adresse oder DNS-Name des LDAP-Servers" -u "DOMAIN\USER" -up Passwort -simple -exterr -maxe 1 -s sub (samaccountname=xyz)

aufrufst, bekommst du auch die entsprechende Returnmeldung. Das -maxe 1 -s sub (samaccountname=xyz) kannste auch weglassen, sollten aber die Anmeldedaten richtig sein, dann wäre sonst der Returnstring schier endlos...
Also falls du überhaupt in ein udf eine externe exe einbinden willst, solltest du eher diese hier von mir beschriebene simplere Lösung nehmen, zumal du die adfind.exe auch direkt (aufgrund freeware) mit in dein udf packen kannst...

Nach $Fehlerout = stderrRead suche ich nach dem "AcceptSecurityContext"-String, wenn der vorhanden ist, dann habe ich die Auswertung so eingerichtet:

$Fehlerout = StringTrimLeft($Fehlerout, StringInStr($Fehlerout, "AcceptSecurityContext", 2))
$Fehlerout = StringTrimLeft($Fehlerout, StringInStr($Fehlerout, " data", 2) + 5)
$Fehlerout = StringTrimRight($Fehlerout, StringLen($Fehlerout) - StringInStr($Fehlerout, ", vece)", 2)+1)
Switch $Fehlerout
Case "525"
$Fehler = "Benutzer nicht gefunden"
Case "52e"
$Fehler = "Passwort falsch"
Case "530"
$Fehler = "Anmeldung mit diesen Logindaten derzeit nicht möglich"
Case "532"
$Fehler = "Passwort abgelaufen"
Case "533"
$Fehler = "Account deaktiviert"
Case "701"
$Fehler = "Account ausgelaufen"
Case "773"
$Fehler = "Passwortgültigkeit ausgelaufen"
Case "775"
$Fehler = "Zu viele Anmeldeversuche mit falschem Passwort"
Case Else
$Fehler = "Unbekannter Fehler: " & $Fehlerout
EndSwitch
ConsoleWrite(@CRLF & "Ausgabe: " & $Fehler & @CRLF)

ne ne - passt schon...
Danke für deinen Eintrag - vielleicht bringts was...

hi water,

es wäre prima, wenn du in dem Ticket einen kleinen sinnvollen Kommentar hinterlassen könntest, der die Dringlichkeit der gesamten Problematik unterstützt.
Es sollte sich hier allerdings nicht unbedingt nur um die AD-Abfragen handeln, eventuell hast du noch eine andere Stelle, wo du die erweiterten Rückmeldestrings benötigst.
Dann hätten die DEVs noch mehr Möglichkeiten der Ursachensuche...

Zitat von water

Vielleicht solltest Du mal einen AutoIt Entwickler kontaktieren.

Falls Du was findest, ich wäre sehr interessiert das Error handling des AD UDFs zu erweitern.

Hi water,

genau dies habe ich heute früh gemacht siehe auf der offiziellen autoitseite Ticket 1516.
Ich hoffe, die kommen weiter.
Das Problem hier scheint zu sein, daß der errorstring nur ne Übersetzung zum error-hex ist, darin aber keine comment-Zeilen des eigentlichen LDAP-Return-Strings zu finden sein können.
Der eigentliche Return-String scheint lt. meinem gegoogle nur bei java/php auswertbar zu sein, da die Bibliothek dort selbst so programmiert ist, daß sie den String zurückgibt (und nicht nur einen einzelnen Hex-Wert)
Beispiel
Das Problem muss doch auch bei vielen anderen DllCalls u.ä. auftauchen - ich kann mir nicht vorstellen, daß da keiner in der Lage ist den String auswertbar zu machen - ich suche wohl nach den falschen Begriffen...
Siehe auch Tread 143348 hier im Forum, da hab ichs mit DllCall probiert...

Gibts ne Möglichkeit die extended-Rückmeldung bei AD-Anmeldung sichtbar zu machen?
Hier mein Problem aus meinem anderen Beitrag, was aber direkt hiermit zu tun hat:

Bei Tests mit einem Netzwerksniffer stelle ich fest, daß er bei folgendem Script die erweiterten Fehlermeldung aufzeichnet:

Global $objDSO = ObjGet ("LDAP:")
Const $ADS_SERVER_BIND= 512 ;0x200
Global $username = "DOMAIN\Username"
Global $Passwort = "secret"
$obj1 = $objDSO.OpenDSObject("LDAP://xxx.xxx.xxx.xxx", $username, $Passwort, $ADS_SERVER_BIND)

So ähnlich wird auch im adfunctions.au3 die Anmeldung absolviert...
Die Rückmeldung mit falschen Userdaten, die das LDAP an das Autoit-Script sendet:

Result: Status: Invalid Credentials, MatchedDN: NULL, ErrorMessage: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

Ich bekomm nur leider die Meldung im Autoit nicht sichtbar - hat hier jemand ne Idee?
Ich brauch den Hex-Code, welcher in der Result-Zeile rechts neben "data" und links neben "vece" steht

Aus den erweiterten Fehlermeldungen kann man nützliche Dinge ableiten.
Diese sind im Beispiel:

525 - user not found
52e - invalid credentials
530 - not permitted to logon at this time
532 - password expired
533 - account disabled
701 - account expired
773 - user must reset password

Gibts ne andere Methode statt $objDSO.OpenDSObject für das LDAP-Objekt, wie ich den Fehlercomment darstellen kann?

Es gibt noch ne kleine Ergänzung:
Ich stelle gerade fest, das der Netzwerksniffer auch bei folgendem Script die erweiterten Fehlermeldung aufzeichnet:

Global $objDSO = ObjGet ("LDAP:")
Const $ADS_SERVER_BIND= 512 ;0x200
Global $username = "DOMAIN\Username"
Global $Passwort = "secret"
$obj1 = $objDSO.OpenDSObject("LDAP://xxx.xxx.xxx.xxx", $username, $Passwort, $ADS_SERVER_BIND)

Die Rückmeldung mit falschen Userdaten, die das LDAP an das Autoit-Script sendet:

Result: Status: Invalid Credentials, MatchedDN: NULL, ErrorMessage: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

Auch hier bekomme ich aber leider die Meldung im Autoit nicht sichtbar - hat hier jemand ne Idee?
Ich brauch den Hex-Code, welcher in der Result-Zeile rechts neben "data" und links neben "vece" steht

Gibts ne andere Methode statt $objDSO.OpenDSObject für das LDAP-Objekt, wie ich den Fehlercomment darstellen kann?
Da bräuchte ich den ganzen DllCall überhaupt nicht ausführen...

Ich hab nen Network-Sniffer auf meine Anfrage "gehetzt" und der ergab im Protokollstapel den Text:

BindResponse: Status: Invalid Credentials, MatchedDN: NULL, ErrorMessage: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

Der Text kam bereits beim ldap_simple_bind_s

Und da steht ja bereits mein gewünschtes Ergebniss drin - ganz hinten vor "vece", der data-Sector

Wie kann ich den Text (String) im Autoit sichtbar machen?

AutoIt gibt mir nur
0: 49 - 00000031 - 49 0
1: 0x0000000000EC16C8 - 00EC16C8 - 15472328 0
2: 0x0000000003B9E910 - 03B9E910 - 62515472 0
3: 0x0000000003B9E970 - 03B9E970 - 62515568 0
4: 128 - 00000080 - 128 0

für mein Array zurück, dies ist aber das Ergebniss - nicht der Error-String.
Wie kann ich den Errorstring in eine Variable packen?

Die Funktion:

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)
$ldapcon = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "ptr",DllStructGetPtr($dn), "ptr",DllStructGetPtr($passwd), "ULONG", $LDAP_AUTH_SIMPLE)
ConsoleWrite(@CRLF & Hex(_WinAPI_GetLastError()) & ": " & _WinAPI_GetLastErrorMessage())
Return $ldapcon
EndFunc

Gibt mir bei ConsoleWrite nur "erfolgreich beendet" zurück - stimmt ja auch der DllCall war ja auch erfolgreich (nur nicht in der Art des Ergebnisses)
Wie bekomm ich die Fehlermeldung, die im TCP-IP-String zurückgegeben wird, in Autoit sichtbar?

Hat das etwas mit dem DllCallbackRegister zu tun?
Oder mit diesem ominösem lparam oder wparam (hab ich immer mal gelesen ohne zu wissen, was dies ist)?
Oder lieg ich da auf dem Holzweg?
Davon hab ich leider noch keine Ahnung...

Die Informationen sind DA, ich bekomm sie nur nicht sichtbar...
Bitte helft mir, ich bin schon so weit in dem Sumpf drin - ich freu mich über jede Hilfe-Leine

ist kein Spezi hier, der sich mit dll-call auskennt und eine Idee hat, wie ich an den String komme?
Der String muss lt. Microsoft ein TCHAR sein, gibts da Besonderheiten in Autoit?

Ja, hab ich, das UDF nutzt angesprochene Variante 1 - ADsDSOObject.
Da bekomm ich aber den erweiterten Fehler nicht zurück.
Ich bekomm als Rückmeldung nur "Geht" oder "Geht nicht".
Ich muss aber "Warum geht es nicht" zurückbekommen. Lt. MS geht dies nur mittels LDAP_OPT_SERVER_ERROR

Für mich ist wichtig, ob z.B. das Passwort abgelaufen oder der Nutzer deaktiviert oder der Nutzer unbekannt oder das Passwort falsch ist.
Je nach Returncode muss ich unterschiedliche Aktionen ausführen - z.B. bei Passwort abgelaufen die Routine zum Passwort ändern durchführen oder bei anderen Fehlern dem Nutzer die entsprechenden Hinweise ausgeben.

Oder kennt jemand eine andere Variante?

ich möchte mich von einem PC außerhalb meiner AD-DOMAIN am LDAP mit Benutzername und Kennwort anmelden und benötige die erweiterten Rückmeldungen wie z.B.:

525 - user not found
52e - invalid credentials
530 - not permitted to logon at this time
532 - password expired
533 - account disabled
701 - account expired
773 - user must reset password

um einen LDAP-CONNECT hinzubekommen, habe ich bislang drei Varianten gefunden:

1. per ADSDSOObject – dies gibt mir aber im Fehlerfall nicht die nötigen Infos zurück - ich hab zumindest keine Möglichkeit gefunden

2. per $objDSO.OpenDSObject – dies gibt mir ebenfalls keine erweiterten RETURN-Meldungen zurück - ich hab zumindest keine Möglichkeit gefunden

3. per DLLCALL auf die WLAPD32.DLL

hierzu habe ich mit folgenden Quellcode experimentiert

#include <array.au3>
#include <WinAPIError.au3>
#include <WINAPI.au3>
$oMyError = ObjEvent("AutoIt.Error", "ComError")
Global $objDSO = ObjGet ("LDAP:")
Global $Host = "xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx"
Global $Port = "389"

Global $fkt
Const $ADS_SECURE_AUTHENTICATION = 1
Const $ADS_USE_SEALING = 64 ;'0x40
Const $ADS_USE_SIGNING = 128 ;'0x80
Const $ADS_SERVER_BIND= 512 ;0x200

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

Const $LDAP_AUTH_NEGOTIATE = 0x0400
Const $LDAP_AUTH_DIGEST = 0x4000
Const $LDAP_AUTH_OTHERKIND = 0x86
Const $LDAP_AUTH_SIMPLE = 0x80
Const $LDAP_AUTH_NTLM = 0x01000

Const $SEC_WINNT_AUTH_IDENTITY_UNICODE = 0x2
Const $SEC_WINNT_AUTH_IDENTITY_ANSI = 0x1

Global $username = "username"
Global $Passwort = "secret"
Global $domain = "DOMAIN"

Global $ldapldll = DllOpen("WLDAP32.DLL")

$ldapinit = ldapinit()
;errorpruefung($ldapinit, $fkt)
$ldapsetOption = ldap_set_option()
;errorpruefung($ldapsetOption, $fkt)
$ldapcon = ldap_simple_bind_s()
errorpruefung($ldapcon, $fkt)
$ldapgetoption = ldap_get_option()
errorpruefung($ldapcon, $fkt)

ldap_unbind()
DllClose("WLDAP32.DLL")
ConsoleWrite(@CRLF)
exit

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

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)
;_WinAPI_ShowError(Hex(_WinAPI_GetLastError()) & ": " & _WinAPI_GetLastErrorMessage())
;Return $ldapcon
EndFunc

Func ldap_get_option()
;If $ldapcon[0] <> 0 Then
$ldaperr = DllStructCreate("char[255]")
DllStructSetData($ldaperr,1, 0)
$fkt = "ldap_get_option"
$ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", $LDAP_OPT_SERVER_ERROR, "ptr", DllStructGetPtr($ldaperr))
;$fkt = "LdapGetLastError"
;$lasterror = DllCall($ldapldll, "ULONG", $fkt)
;errorpruefung($lasterror, $fkt)
;ConsoleWrite(Hex(_WinAPI_GetLastError()) & ": " & _WinAPI_GetLastErrorMessage())
$b = DllStructCreate("DWORD",DllStructGetPtr($ldaperr,1))
errorpruefung($ldaperr, $fkt)
errorpruefung($b, $fkt)
Return $ergebnis
;_ArrayDisplay($ergebnis)
;EndIf
EndFunc

Func ldap_set_option()
;If $ldapcon[0] <> 0 Then
$ldaperr = DllStructCreate("ULONG")
DllStructSetData($ldaperr,1, 3)
$fkt = "ldap_set_option"
;$ldaperr = 0
$ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", $LDAP_OPT_PROTOCOL_VERSION, "ptr", DllStructGetPtr($ldaperr))
If @error <> 0 Then ConsoleWrite(Hex(_WinAPI_GetLastError()) & ": " & _WinAPI_GetLastErrorMessage())
errorpruefung($ldaperr, $fkt)
Return $ergebnis
;_ArrayDisplay($ergebnis)
;EndIf
EndFunc

Func ldap_unbind()
$fkt = "ldap_unbind"
$ldapunbind = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0])
EndFunc

;$ldapfree = DllStructCreate("char[" & (StringLen($LDAP_OPT_SERVER_ERROR) + 1) & "]")
;DllStructSetData($ldapfree,1, $LDAP_OPT_SERVER_ERROR)
;$fkt = "ldap_memfree"
;DllCall($ldapldll, "ptr", $fkt, "ptr", DllStructGetPtr($ldapfree))

;$fkt = "LdapGetLastError"
;$lasterror = DllCall($ldapldll, "ULONG", $fkt)
;errorpruefung($lasterror, $fkt)

Func errorpruefung($ID, $Name = "")
If IsArray($ID) THEN
ConsoleWrite(@CRLF & $Name & " ")
For $I = 0 To UBound($ID)-1
ConsoleWrite(@CRLF & $I & ": " & $ID[$I] & " - " & hex($ID[$I],8) & " - " & dec(hex($ID[$I],8)) & " " & DllStructGetData($ID, $I))
Next
ConsoleWrite(@CRLF)
;_ArrayDisplay($ID)
Else
ConsoleWrite(@CRLF & $Name & " " & DllStructGetData($ID, 1) & " - " & hex(DllStructGetData($ID, 1),8) & " " & DllStructGetData($ID, 2) & " - " & hex(DllStructGetData($ID, 2),8) & @CRLF)
EndIf
EndFunc

Func ComError()
if IsObj($oMyError) then
$Fehlertext = ("Name: " & @TAB & $oMyError.description & @CRLF & _
"Beschreibung: " & @TAB & $oMyError.windescription & @CRLF & _
"Fehlernummer: " & @TAB & hex($oMyError.number,8) & @CRLF & _
"Fehlernummer1: " & @TAB & $oMyError.number & @CRLF & _
"Letzter Fehler: " & @TAB & $oMyError.lastdllerror & @CRLF & _
"Zeile: " & @TAB & $oMyError.scriptline & @CRLF & _
"Quelle: " & @TAB & $oMyError.source & @CRLF & _
"err.helpfile is: " & @TAB & $oMyError.helpfile & @CRLF & _
"err.helpcontext is: " & @TAB & $oMyError.helpcontext )
SetError($Fehlertext)
ConsoleWrite(@CRLF & $Fehlertext & @CRLF)
;SetError(Hex($oError.Number))
else
SetError(1)
endif
EndFunc

- bei Eingabe eines richtigen Usernamens + Kennwort bekomme ich ERROR 0x0 zurück – also alles OK.
- bei Falscheingabe bekomme ich ERROR 0x31 zurück – also LDAP_INVALID_CREDENTIALS – also auch OK.

Wenn ich nun ldap_get_option mit LDAP_OPT_SERVER_ERROR abfrage, bekomme ich leider keine auswertbare Antwort – die letzen 4 HEX-Werte sind immer 1828, egal, ob der Benutzer nicht existiert oder das Passwort falsch ist oder der Benutzer deaktiviert wurde oder oder… Ich bekomme auch keinen String zurück, sondern nur einen HEX-Wert

Wie komme ich zu dem erweiterten Rückgabestring, der z.B. bei Java oder PHP so aussieht:
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 525, v893
Hier steht fast ganz hinten der Wert 525 - also in dem Bsp. User not found

Die Microsoftseiten sind z.B. hier für ldap_get_option und hier für LDAP_OPT_SERVER_ERROR

Ich muss nicht mit DLL-CALL arbeiten, ich benötige nur den erweiterten Rückgabestring in AUTOIT. Gibt’s noch andere Methoden, mit AUTOIT auf LDAP von extern zuzugreifen UND den erweiterten Rückgabestring zu bekommen?
Der LDAP-Server muss die Antwort geben, da ein Linux-System von unserem LDAP auch die Antwort bekommt.
Mir scheint hier, daß ich ein Problem habe, den TCHAR-Rückgabestring auszuwerten - an den komm ich einfach nicht ran...

Ich bitte um Hilfe…

Sorry, wenn mein Quellcode nicht gleich verständlich ist - ich bin Anfänger auf dem Gebiet DLLCall - das ist alles mein Werk der letzten 5 verzweifelten Tage...