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.