newbi2009 1 Posted April 29 Report Posted April 29 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 Quote
Dukel 465 Posted April 29 Report Posted April 29 Funktioniert die Zeile in der CMD statt der Powershell? Quote
Damian 1,722 Posted April 29 Report Posted April 29 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 Quote
newbi2009 1 Posted April 29 Author Report Posted April 29 ja - die Zeile funktiniert ja auch in der Powershell, wirft nur diese blöde Fehlermeldung Quote
cj_berlin 1,435 Posted April 29 Report Posted April 29 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. Quote
newbi2009 1 Posted April 29 Author Report Posted April 29 (edited) 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 Edited April 29 by newbi2009 Quote
daabm 1,400 Posted April 29 Report Posted April 29 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... Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.