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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature