ldapsearch falha com trema no recipiente base

Question

Eu tenho um ou chamado München no meu LDAP (diretório ativo, para ser preciso). Para procurá-lo, preciso inserir o trema como \C3\BC , mas pelo menos o ou existe, pois isso prova:

$ 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

No entanto, embora eu possa pesquisar por umlauts (ou seja, usar \C3\BC em filtros), não consigo pesquisar dentro um trema ou (ou seja, usar \C3\BC em o parâmetro "base"):

$ 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

O erro afirma que o ou não existe, enquanto acabamos de ver que ele existe. Então, o que há de errado com a minha consulta? Ou seja: como codificar os sobrenomes em -b ? Aparentemente, o método será diferente da codificação usada para filtros ...

Caso as informações sejam necessárias: O servidor LDAP é um servidor do Active Directory do MS Windows 2003 e eu executo ldapsearch de um pengulin atualizado do Ubuntu. E (embora isso não deva se aplicar, já que temos a codificação basckslash de qualquer forma):

$ 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

    

Answer 1

Eu encontrei a solução (embora eu não tenha certeza se ela se aplica ao ldap ingeneral ou é algo específico para o diretório ativo MS). Os umlauts são tratados como equivalentes com suas contrapartes sem ponto (isto é, sem dúzia). Assim, em vez de especificar "München", pode-se especificar "Munchen". Esta é também a razão pela qual um objeto chamado Munchen não pode ser criado onde München já existe.

    

Answer 2

De acordo com RFC2849 , qualquer pesquisa que contenha dados UTF-8 precisa ser codificada em base64. Tente codificar com base64 a string inteira (incluindo as informações que você removeu) e procurar por isso.