Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a local OpenLDAP server with a couple of users. I'm using it for development purposes, here's the ldif:

#Top level - the organization
dn: dc=site, dc=com
dc: site
description: My Organization
objectClass: dcObject
objectClass: organization
o: Organization

#Top level - manager
dn: cn=Manager, dc=site, dc=com
objectClass: organizationalRole
cn: Manager

#Second level - organizational units
dn: ou=people, dc=site, dc=com
ou: people
description: All people in the organization
objectClass: organizationalunit

dn: ou=groups, dc=site, dc=com
ou: groups
description: All groups in the organization
objectClass: organizationalunit

#Third level - people
dn: uid=celoserpa, ou=people, dc=site, dc=com
objectclass: pilotPerson
objectclass: uidObject
uid: celoserpa
cn: Marcelo de Moraes Serpa
sn: de Moraes Serpa
userPassword: secret_12345
mail: marcelo@site.com

So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the 12345678 password (the local server password, setup on slapd.conf).

However, I would like to bind with any user in under the people OU. In this case, I'd like to bind with: dn: uid=celoserpa, ou=people, dc=site, dc=com userPassword: secret_12345

But I'm getting a "(49) - Invalid Credentials" error everytime. I have tried through CLI tools (such as ldapadd, ldapwhoami, etc) and also ruby/ldap. The bind with these credentials fails with a invalid credentials error.

I thought that it could be an ACL issue, however, the ACLs on slapd.conf seem to be right:

access to attrs=userPassword
    by self write
    by dn.sub="ou=people,dc=site,dc=com" read
    by anonymous auth

access to * by * read

I was suspecting that maybe OpenLDAP doesn't compare against userPassword? Or maybe some ACL configuration I am missing that is somehow affecting the read access to userPassword for the specific DN.

I'm really lost here, any suggestion appreciated!

Cheers,

Marcelo.

share|improve this question

1 Answer 1

The folks @ #openladp were kind enough to help me to debug this issue. It turned out that it was a simple detail (as mostly always :)) -- When I created the ldif, I've put the password in clear text, however, I didn't do anything to tell openldap that it was actually cleartext nor I knew I had to (nor I knew or know how to, but that doesn't really matter, as you will see in a moment). The whole time I though it had to do with ACLs (OpenLDAP denying read-access to userPassword), but the problem was that OpenLDAP was trying to authenticate using SHA-1, and the password was stored as clear text.

The solution? Store the password as a SHA-1 hash. Nobody would want to store password as clear-text anyway.

So, issue solved!

Cheers,

share|improve this answer
    
Even better, store the password as SHA512 hash :-) –  Jubal Jul 11 at 23:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.