[389-users] Data corruption after upgrade.

[Theunis De Klerk]

> 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.
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 at 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 at domain.com': authentication failure for
"/profile/": password Mismatch, referer: https://www.domain.co.za/profile/

Does that help?

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.