Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

2 Answers 2

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.