Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an ou named München in my LDAP (active directory, to be precise). To search for it, I have to enter the umlaut as \C3\BC of course, but at least the ou exists as this proves:

$ 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

However, I while I can search for umlauts (i.e. use \C3\BC in filters), I cannot search within an umlaut ou (i.e. use \C3\BC in the "base" 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

The error claims that the ou does not exist, while we have just seen that it exists. So what is wrong with my query? That is: How do I have to encode umlauts in -b? Apparently the method will differ from the encoding used for for filters ...

In case the information is needed: The LDAP Server is a MS Windows 2003 Active Directory server and I run ldapsearch from an up to date Ubuntu precise pengulin. And (though this should not apply as we have basckslash-encoding anyway):

$ 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
share|improve this question
up vote 1 down vote accepted

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.

share|improve this answer

According to RFC2849, any lookup containing UTF-8 data needs to be base64-encoded. Try base64-encoding the entire string (including the information you removed) and searching by that.

share|improve this answer
    
Hm, at least ldapsearch ... -b 'T1U9TcO8bmNo...hbA==' does not work. Apparently some mechanism to inform ldapsearch that the -b parameter is base64-encoded would be needed. – Hagen von Eitzen Aug 25 '13 at 11:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .