Theunis De Klerk wrote: >> I'm still trying to reproduce this problem. el5 i386 does not have the >> problem - now trying el5 x86_64 >> > > Well, I got 1 step closer. Along with users not being able to login, when > they reset their passwords (done via a perl module; which worked before the > upgrade), it would update ldap, but they still couldn't login. Then taking a > shot in the dark in the code that updated/created the password instead of > passing an SSHA'd password to ldap update command, I now pass a plaintext > password and it works. > > Is it possible that in the latest 389 version, that the values for the > userPassword attributes are being stored/read differently? > Yes. The upgrade doesn't touch the actual data, but 1.2.1 may have slightly altered the way password comparisons are done. In general, you should always pass the clear text password to the directory server, and let it hash it and compare it. This also allows you to use the password policy features of the directory server (e.g. password syntax checking does not work with pre-hashed passwords). Were these applications that pre-hashed the SSHA passwords, then sent the pre-hashed SSHA password to the server, when adding a user or modifying the password? If so, then it could be that the legacy SSHA handling was broken. > -- > 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/4a0ba332/attachment.bin
