Theunis De Klerk wrote:
Yes. The upgrade doesn't touch the actual data, but 1.2.1 may have slightly altered the way password comparisons are done.I'm still trying to reproduce this problem. el5 i386 does not have the problem - now trying el5 x86_64Well, 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?
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@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
