Theunis De Klerk wrote:
I don't mean ldapsearch _for_ a specific user - I mean ldapsearch _as_ a specific user - ldapsearch -x -D "uid=username,..." -w cleartextpasswordWait - 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.
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.
Yes. It means apache is using the LDAP BIND operation to authenticate the user, which is what ldapsearch does.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. Andthat'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 doesThere is nothing in the dirsrv access log. But there is this in the apache logs: auth_ldap authenticate: user user@xxxxxxxxxx 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@xxxxxxxxxx': authentication failure for "/profile/": password Mismatch, referer: https://www.domain.co.za/profile/ Does that help?
I'm still trying to reproduce this problem. el5 i386 does not have the problem - now trying el5 x86_64And 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.
-- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
<<attachment: smime.p7s>>
-- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
