[389-users] Data corruption after upgrade.

[Rich Megginson]

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://listman.redhat.com/archives/fedora-directory-users/attachments/20090819/af1f498c/attachment.bin>