ldapsearch schlägt mit Umlaut im Basiscontainer fehl

2147
Hagen von Eitzen

Ich habe einen ouNamen Münchenin meinem LDAP (Active Directory, um genau zu sein). Um danach zu suchen, muss ich \C3\BCnatürlich die Umlaute eingeben, aber zumindest ouexistiert das, wie dies beweist:

$ ldapsearch -D $ADMIN -w $ADMINPWD -v -u -h $HOST -b 'ou=Benutzer,dc=[obfuscate]' '(ou=M\C3\BCnchen)' ou ldap_initialize( ldap://[obfuscate] ) filter: (ou=M\C3\BCnchen) requesting: ou  # extended LDIF # # LDAPv3 # base <ou=Benutzer,dc=[obfuscate]> with scope subtree # filter: (ou=M\C3\BCnchen) # requesting: ou  #  # M\C3\BCnchen, Benutzer, [obfuscate] dn:: T1U9TcO8b[obfuscate]== ufn: M\C3\BCnchen, Benutzer, [obfuscate] ou:: TcO8bmNoZW4=  # search result search: 2 result: 0 Success  # numResponses: 2 # numEntries: 1 

Allerdings habe ich, während ich suchen für Umlaute (zB Verwendung \C3\BCin Filtern), kann ich nicht suchen in einem Umlaut ou (dh Einsatz \C3\BCin der „Basis“ Parameter):

$ ldapsearch -D $ADMIN -w $ADMINPWD -v -u -h $HOST -b 'ou=M\C3\BCnchen,ou=Benutzer,dc=[obfuscate]'  ldap_initialize( ldap://[obfuscate] ) filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <ou=M\C3\BCnchen,ou=Benutzer,dc=[obfuscate]> with scope subtree # filter: (objectclass=*) # requesting: ALL #  # search result search: 2 result: 32 No such object matchedDN: OU=Benutzer,DC=[obfuscate] text: 0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'OU=Benutzer,DC=[obfuscate]'   # numResponses: 1 

Der Fehler behauptet, dass das ou nicht existiert, während wir gerade gesehen haben, dass es existiert. Was ist also falsch an meiner Anfrage? Das heißt: Wie muss ich Umlaute kodieren -b? Anscheinend unterscheidet sich die Methode von der für Filter verwendeten Kodierung ...

Falls die Informationen benötigt werden: Der LDAP-Server ist ein Microsoft Windows 2003 Active Directory-Server, und ich verwende ldapsearchein aktuelles Ubuntu-Präzisions-Pengulin. Und (obwohl dies nicht gelten sollte, da wir sowieso eine Basckslash-Kodierung haben):

$ locale LANG=de_DE.UTF-8 LANGUAGE=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL=de_DE@euro 
0

2 Antworten auf die Frage

1
Hagen von Eitzen

Ich habe die Lösung gefunden (obwohl ich nicht sicher bin, ob sie für ldap allgemein oder für MS Active Directory spezifisch ist). Umlaute werden mit ihren punktlosen Gegenstücken als gleichwertig behandelt. Anstelle von "München" kann man also "München" angeben. Dies ist auch der Grund, warum ein Objekt namens München nicht dort erstellt werden kann, wo München bereits existiert.

0
Alex Plumb

Nach RFC2849 muss jede Suche, die UTF-8-Daten enthält, Base64-kodiert sein. Versuchen Sie, den gesamten String (einschließlich der von Ihnen entfernten Informationen) mit Base64 zu codieren und danach zu suchen.

Hm, zumindest 'ldapsearch ... -b' T1U9TcO8bmNo ... hbA == '`funktioniert nicht. Anscheinend wäre ein Mechanismus erforderlich, um ldapsearch darüber zu informieren, dass der `-b`-Parameter base64-codiert ist. Hagen von Eitzen vor 10 Jahren 0