Fehlermeldung open LDAP - ldapsearch.exe

[newbi2009 1]

Hallo zusammen,

wir betreiben einen/mehrere LDAP Server (kein Active Directory). Bisher habe ich für Powershell-basierende Abfragen immer die von Lotus Notes mitgeliferten ComandLine-Tools (hier ldapsearch.exe) benutzt, was ganz gut funktioniert hat. Leider wird uns wohl bald der Notes client und somit auch die da mit kommenden LDAP CL-Tools deinstalliert, sodass ich mich nach einer anderen Lösung umschauen musste... Hier bin ich auf "open LDAP for Windows" gestossen. Software ist nun installiert und ich kann auf die cl-Tools zugreifen. Jetzt zu meinem zwei Problem:

Eins vorweg: Egal, ob ich den Bind mit "-x" oder ohne durchführe, ist das Ergebnis das Gleiche

 

 & "C:\OpenLDAP\ClientTools\ldapsearch.exe" -H ldap://XXXXX.home.local:2390 -D $username -w $script:pw -b $script:DN -s base "objectClass=*" userCertificate > $safepath

 oder Bind mit „-x“ – kein Unterschied:

& "C:\OpenLDAP\ClientTools\ldapsearch.exe" -x -H ldap://XXXXX.home.local:2390 -D $username -w $script:pw -b $script:DN -s base "objectClass=*" userCertificate > $safepath

 

ich bekomme IMMER folgende Fehlermeldung im Programmfenster (Powershell ISE) angezeigt (auch ein Umleiten mit 2>&1 bringt nicht mehr Fehlermeldungs-Text in der Ausgabe-Datei)

 

ldapsearch.exe : ldap_bind: Success (0)

In C:\Users\xxxxx\Documents\Powershell-Scripte\Benutzer von PROD in TEST\Benutzer_von_PROD_nach_TEST.ps1:498 Zeichen:18

+ ...             & "C:\OpenLDAP\ClientTools\ldapsearch.exe" -H ldap://xxxx ...

+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (ldap_bind: Success (0):String) [], RemoteException

    + FullyQualifiedErrorId : NativeCommandError

 

       additional info: Bind succeeded.

 

Ich verstehe nicht, was hier "angemeckert" wird. Es steht explizit  in der Meldung, dass der Bind funktioniert hat, und auch die Ausgabe funktioniert korrekt

 

Dies ist der Text der Ausgabedatei)

--------------------------------------- 

# extended LDIF

#

# LDAPv3

# base < cn=DoeJohn,ou=Extern,ou=Three,o=Two,c=One > with scope baseObject

# filter: objectClass=*

# requesting: userCertificate

#

# DoeJohn, Extern, Three, Two, One

dn: cn=DoeJohn,ou=Extern,ou=Three,o=Two,c=One

userCertificate;binary:: MIIHaDCCBVCgAwIBAgIDSHYqMA0GCSqGSIb3DQEBCwUAMFwxCzAJB

gNVBAYTAkRFMRkwFwYDVQQKExBQS0ktMS1WZXJ3YWx0dW5nMRMwEQYDVQQLEwpCdW5kZXN3ZWhyMR

0wGwYDVQQDExRCdyBWLVBLSSBDQSAyMDIyIC0gMjAeFw0yMzAyMTUxMDEwMDlaFw0yODAyMTUxMDE

wMDlaMFgxCzAJBgNVBAYTAkRFMQ0wCwYDVQQKEwRidW5kMQ0wCwYDVQQLEwRibXZnMRAwDgYDVQQL

EwdwZXJzbWlsMRkwFwYDVQQDExBHZXV0aW5nIFRob3JzdGVuMIICIjANBgkqhkiG9w0BAQEFAAOCA

qvkJ++i7MSkz6FguCrewZ+d3QiogHFh5QI77zQklognb+6GhGyH9Iv0amzRLCVWyWgxPMw0OUs92K

7H4thYcNpl/l8QB5rf0v/R23vSEOgMqypkORkNGRZ2hf36kWuJPil60657xAbfoArGXdiF+Hs+tv8

zPkdwrTtg9flgDVVeceRfGDzuaUf0NYU2ee7xBVO2oJyd1mgBDdZfMihRTrYM70+ewmqDYp4wiuCb

wsh++XX9hts9BI+ldO2Lm4FMmoOjQjg5/SrdWh6gLEeLeZDmxSXtl8WafGlLpLDRNK3zYiaR+soW4

EEWI6kz0ZhqRAs0AQlQcD5qqCTmWvylvtjPyRnW1NA4fpc7RIi02Zcj2v7pdsd+lnwZ8sr9UblQFi

WqKSFk/hvvgdzCVwA==

# search result

search: 2

result: 0 Success

text: Search succeeded. Found 1 Entries (0 Aliases), 1 Attributes, 1 Values. (C

hainedResult=no)

# numResponses: 2

# numEntries: 1

----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

 

Was ich aber noch viel merkwürdiger finde, ist der Fakt, dass ich bei JEDEM 2. VERSUCH, das Skript laufen zu lassen, den Fehler bekomme, dass das Bind NICHT funktioniert hat: 

 

ldapsearch.exe : ldap_bind: Success (0)

In C:\Users\xxxxx\Documents\Powershell-Scripte\Benutzer von PROD in TEST\Benutzer_von_PROD_nach_TEST.ps1:498 Zeichen:18

+ ...             & "C:\OpenLDAP\ClientTools\ldapsearch.exe" -x -H ldap://x ...

+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (ldap_bind: Success (0):String) [], RemoteException

    + FullyQualifiedErrorId : NativeCommandError

       additional info: Bind succeeded.

ldap_result: Can't contact LDAP server (-1)

 

Dann ist die Ausgabedatei auch "quasi" leer:

 

# extended LDIF

#

# LDAPv3

# base < cn=DoeJohn,ou=Extern,ou=Three,o=Two,c=One > with scope baseObject

# filter: objectClass=*

# requesting: userCertificate

#

# numResponses: 0

 

 

Kann mich hier irgend jemand erleuchten, wo/was genau mein Fehler ist?

 

Vielen Dank

Gruß

Holger

[Dukel 468]

Funktioniert die Zeile in der CMD statt der Powershell?

 

[Damian 1.793]

Moin

 

@newbi2009 Verwende bei mehreren und/oder längeren Codeblöcken oder Kommandoausgaben bitte die Formatierungshilfe im Editor, die da ---> </>

 

Und die pastell-bunte Farbgebung macht das Lesen auch nicht einfacher.

 

VG

Damian

[newbi2009 1]

ja - die Zeile funktiniert ja auch in der Powershell, wirft nur diese blöde Fehlermeldung

[cj_berlin 1.508]

Ich würde sagen, die EXE schreibt die Ausgabe in den Error-Stream statt nach StdOut, und PowerShell interpretiert es korrekterweise als Exception  Wäre nicht das erste DOS-Tool, das sowas macht. Kannst vor dem Aufruf $ErrorActionPreference auf 'SilentlyContinue' und danach zurück auf den vorherigen Wert setzen.

 

Besser wäre natürlich, einfach PowerShell zu nutzen  Es gibt den System.DirectoryServices-Namespace, es gibt das OpenAD-Modul von Jordan Borean in der Gallery, die Möglichkeiten sind schier endlos.

[newbi2009 1]

Hi Evgenij,

 

danke für den Tipp mit $ErrorActionPreference. Das ist okay für mich. 

Unsere Firmen-Policies sind relativ strikt, sodass es ein schier endloser Prozess ist, neue Software (auch Powershell-Module sind "neue Software") genehmigt zu bekommen, daher der Weg über die externen *.exe-Dateien

 

Bleibt meine zweite Frage: Warum funktioniert der Bind nur bei jedem zweiten Lauf???

 

Gruß

Holger

bearbeitet 29. April von newbi2009

[daabm 1.428]

Wird hier keiner beantworten können - niemand weiß, was die exe intern veranstaltet Warum "exterene exe-Dateien" einfacher zu bekommen sind als ein Powershell-Modul, weiß vermutlich auch nur Euer CSO...