Re: Hashed Entries

[Josh Miller <joshua@itsecureadmin.com>]

On Apr 2, 2014, at 3:57 AM, Monica Warnock <monica.warnock@ed.ac.uk> wrote:

> …

> dn: dc=name,dc=name
> objectClass: dcObject
> objectClass: organization
> dc:: ZGxpYi1tb25pZHAg
> o:: ZGxpYi1tb25pZHAg
> 
> dn: ou=Users,dc=name,dc=name
> objectClass: organizationalUnit
> ou: Users
> 
> dn: cn=Bob Jones,ou=Users,dc=name,dc=name
> cn: Bob Jones
> sn: Jones
> objectClass: inetOrgPerson
> objectClass: eduPerson
> eduPersonAffiliation: staff
> userPassword:: cGFzc3dvcmQg
> uid: bjones
> 
> 
> When I log in as bjones using the correct password the 'username or password is not valid'.
> 
> What is the relevance of the entries such as the userPassword:: which now appear with two colons?
> 
> I have added more test users and on their entry the uid entry also has the double colons with a hashed entry following.
...

If you modify or create an entry with any trailing spaces the results will be returned base64 encoded (values are stored correctly, but returned this way).

You can decode with something like the following, which shows that you have a trailing space on your “dc” attribute:

> echo -n "ZGxpYi1tb25pZHAg" | base64 -D
dlib-monidp 

I have seen that in many cases if your base64 encoded attributes do not end with a “==" that you have trailing spaces:

> echo -n "test" | base64
dGVzdA==

> echo -n "dGVzdA==" | base64 -D
test

> echo -n "test " | base64
dGVzdCA=

> echo -n "test  " | base64
dGVzdCAg

> echo -n "dGVzdCAg" | base64 -D
test  


HTH,

Josh Miller
ITSA Consulting, LLC
http://itsecureadmin.com/