Hi Dieter, thanks for the reply.

Yeah, 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. 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,

Marcelo.

On Wed, Apr 7, 2010 at 2:04 AM, Dieter Kluenter dieter@dkluenter.de wrote:

Am Tue, 6 Apr 2010 13:28:27 -0500 schrieb Marcelo de Moraes Serpa celoserpa@gmail.com:

...

Hello list,

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: OneLogin LLC objectClass: dcObject objectClass: organization o: OneLogin LLC

#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 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!

You may run slapd in debugging mode, that is slapd(8) -dacl

-Dieter

-- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

Hello all,

Thank you for the insights.

In general: if you haven't explicitly defined an ACL, OpenLDAP is

configured to allow anonymous reads -- this is *not* sufficient to auth. You will want to allow anonymous auth to the appropriate DNs.

Yeah, I figured that out. I probably created a situation where: 1) I tried authenticating without the proper ACL, it failed; 2) Entered trial and error mode, tried changing userPassword to {CLEARTEXT}secret_12345 3) Didn't work either; 4) Put the: "access to * by * read" ACL, restarted server. 5) Tried authenticating with secret_12345, didn't work 6) Too much time spent, couldn't spend more time on the issue. Tried just converting secret_12345 to SHA-1 and updating the value of userPassword 7) Worked! 8) Could finally relax and get out to get some fresh air ;)

So, the point is, I could get it to work. This is not to say I wouldn't like to know what happened, it is on my list, I might go through the process again next weekend and document my findings, but I think you guys already said what was to be said about the issue.

Cheers and peace!

Marcelo.

2010/4/7 Michael Ströder michael@stroeder.com

Marcelo de Moraes Serpa wrote:

...

Hi Dieter, thanks for the reply.

Yeah, 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. 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.

There's nothing wrong with storing a clear-text password like

userPassword: secret_12345

in the directory entry. In fact you have to when e.g. using SASL/DIGEST-MD5 bind with in-directory passwords.

When processing a simple bind slapd looks whether a password is stored in hashed form by looking at a magic prefix like {SSHA}. If that prefix is not there it is assumed that the password is stored in clear and this gets compared.

...

So, issue solved!

Hmm, I think you mixed up something.

Ciao, Michael.