Theunis De Klerk wrote:
> Wait - you mean ldapsearch -D
> "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword works? So
> the user is able to successfully authenticate using the password after
> upgrade using ldapsearch? Just not with some other tool?
> * ldapsearch works
> * OS login fails
> * Apache mod_ldap fails
> * other apps?
>
Yes, if I do an ldapsearch for a specific user, I get all their details just
fine.
I don't mean ldapsearch _for_ a specific user - I mean ldapsearch _as_ a
specific user - ldapsearch -x -D "uid=username,..." -w cleartextpassword
This will send the LDAP BIND operation with the user's DN and clear text
password i.e. will test the internal directory server password
comparison code.
If I use Apache Directory Studio, also fine.
Those are the only to that I can test with to get information out of the
directory server.
Apache is set to authenticate certain website from the Directory Server. And
that's where it fails.
Apache is the only one that uses the directory server for authentication.
Postfix does as well, but none of the users have email accounts.
> I'm trying to figure out what the common thread is here.
>
> For the apps that fail - can you take a look at the directory server
> access log in /var/log/dirsrv/slapd-instance/access and see what the
> sequence of operations is? I just want to see if those apps are
> attempting to retrieve the userPassword attribute and doing the
> password comparison themselves, or using the LDAP Compare operation,
> rather than just doing an LDAP BIND operation with the clear text
> password (which is what ldapsearch -x -D "dn" -w cleartextpw does
>
There is nothing in the dirsrv access log. But there is this in the apache
logs:
auth_ldap authenticate: user user(a)domain.com authentication failed; URI
/profile/ [ldap_simple_bind_s() to check user credentials failed][Invalid
credentials], referer:
https://www.domain.com/profile/
mod_auth_form: user 'user(a)domain.com': authentication failure for
"/profile/": password Mismatch, referer:
https://www.domain.co.za/profile/
Does that help?
Yes. It means apache is using the LDAP BIND operation to authenticate
the user, which is what ldapsearch does.
And here is a curve ball that makes no sense, might be useless
information,
but anyway. If do a search on uid=username,ou=people,dc=yoursuffix,dc=com.
All their correct information is there. So the data itself looks perfect.
But if I take their uid and password and try login via apache, I get the
above error. Makes sense, the password could be wrong or data corruption.
Apache Directory Studio has a feature where you can verify a password field.
So I put in the password that I just tried to login with and it verifies!
i.e. Apache Directory Studio tells me the password for that user is correct.
Then just to make it interesting, if copy and paste, that exact password
(that wouldn't let me login via apache, but verified on Apache Directory
Studio) and create a new password via Apache Directory Studio for that same
user, apache then lets me login.
Which is exactly why I think its data corruption, cause as soon as Apache
Directory Studio writes to the password field, it 'repairs' the field.
I'm still trying to reproduce this problem. el5 i386 does not have the
problem - now trying el5 x86_64