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.