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.
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.