On Friday 26 January 2007 14:09, Thierry Lacoste wrote:
> According to Faq-O-Matic:
>
> The command
> slappasswd -h {SHA} -s abcd123
> will generate
> {SHA}fDYHuOYbzxlE6ehQOmYPIfS28/E=
> so, in your entry, an attribute like this could be specified:
> userPassword: {SHA}fDYHuOYbzxlE6ehQOmYPIfS28/E=
> but when you do a slapcat or ldapsearch and the output is in LDIF format,
> the userpassword will be base_64 encoded, and it will look like this:
> userPassword:: e1NIQX1mRFlIdU9ZYnp4bEU2ZWhRT21ZUElmUzI4L0U9
>
> Just out of curiosity why is it further encoded as everything in
> the userPassword is already base_64 encoded except the string {SHA}?
> I thought it may be because of the brackets but putting brackets in
> another attribute (e.g. mail) doesn't trigger an encoding.
Look at the schema definition for userPassword. You will note it's syntax is
1.3.6.1.4.1.1466.115.121.1.40, which is Octet String. Some other
attributetypes on my LDAP server include "javaSerializedData", which is an
example of the kind of use you could apply to Octet String, and is most
likely not something you want to print to a terminal without any encoding.
The fact that the common use for userPassword is for ascii text followed by a
password hashing schema which is already suitably encoded is irrelevant ...
If you really want to use commandline tools to see the data un-base64-encoded,
just pipe the value into openssl, e.g.:
$ echo "e1NIQX1mRFlIdU9ZYnp4bEU2ZWhRT21ZUElmUzI4L0U9"|openssl base64 -d
{SHA}fDYHuOYbzxlE6ehQOmYPIfS28/E=
Regards,
Buchan
--
Buchan Milne
ISP Systems Specialist - Monitoring/Authentication Team Leader
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpx3FTmmHMom.pgp
Description: PGP signature