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