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 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? > 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 > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20090819/af1f498c/attachment.bin
