Thx Michael for the precision and the RFC pointer !
On 01.06.14 09:29, Michael Ströder wrote:
Charles Bueche wrote:
I have noticed the same issue when talking to an AD server (very recent version, I think 2012 or so). In fact, I think either AD or ldapsearch is encoding the values values in Base64. I will soon know more because I will start to use the results in a real app. Maybe we have to decode them explicitly.
It's easy to do the detection (emcoded or not), as in ldapsearch, the key is followed by two columns instead of one. Example below:
... cn:: SGFucyBSw7xja21hbm4= ...
is decoding to Hans Rückmann (hope the mailing list will transport it correctly, its a U-umlaut after the R).
This is the LDIF and *not* the attribute value itself.
Everybody who is confused about this base64 stuff should read RFC 2849 now.
Again I recommend to use a decent scripting language with LDAP module.
From http://tools.ietf.org/html/rfc2849
4) Any dn or rdn that contains characters other than those defined as "SAFE-UTF8-CHAR", or begins with a character other than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded.Ciao, Michael.