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.
Regards, Thierry.
Thierry Lacoste wrote:
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}?
IIRC these tools try to hide the userPassword value from being viewed in case they contain clear-text passwords. It's kind of hard-coded. This protects only against a good admin accidentally reading passwords he don't want to know.
Note the :: before the value. This LDIF syntax indicates that the value is base64-encoded. For reading LDIF files I strongly recommend to use a decent LDIF parser available for your favorite scripting language instead of implementing naive string parsing yourself.
Ciao, Michael.
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
openldap-software@openldap.org
-
Buchan Milne -
Michael Ströder -
Thierry Lacoste