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 <[email protected]>
> 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.
>
