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.