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