Сбой ldapsearch с умлаутом в базовом контейнере

1989
Hagen von Eitzen

У меня есть ouимя Münchenв моем LDAP (активный каталог, если быть точным). Чтобы найти его, я, \C3\BCконечно, должен ввести умлаут, но, по крайней мере, ouсуществует, как это доказывает:

$ 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

Тем не менее, я пока я могу найти для умляутов (т.е. использовать \C3\BCв фильтрах), я не могу найти в умляуте оу (т.е. использования \C3\BCв параметре «базового»):

$ 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

Ошибка утверждает, что ou не существует, а мы только что видели, что она существует. Так что не так с моим запросом? То есть: как мне кодировать умлауты в -b? Видимо, метод будет отличаться от кодировки, используемой для фильтров ...

В случае, если требуется информация: Сервер LDAP является сервером Active Directory для MS Windows 2003, и я использую ldapsearchновейшую версию Ubuntu с точным пенгулином. И (хотя это не должно применяться, так как у нас в любом случае есть basckslash-кодировка):

$ 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 ответа на вопрос

1
Hagen von Eitzen

I found the solution (though I am unsure whether it applies to ldap ingeneral or is something specific to MS active directory). Umlauts are treated as equivalent with their dotless (i.e. dieresis-less) counterparts. Thus instead of specifying "München" one can specify "Munchen". This is also the reason why an object named Munchen cannot be created where München already exists.

0
Alex Plumb

Согласно RFC2849, любой поиск, содержащий данные UTF-8, должен быть закодирован в base64. Попробуйте base64-кодирование всей строки (включая удаленную информацию) и поиск по ней.

Хм, по крайней мере `ldapsearch ... -b 'T1U9TcO8bmNo ... hbA =='` не работает. По-видимому, потребуется какой-то механизм для информирования ldapsearch о том, что параметр `-b` закодирован в base64. Hagen von Eitzen 11 лет назад 0

Похожие вопросы