On Tue, Apr 21, 2009 at 03:37:11PM +0200, Michael Ströder wrote:
Hmm, which password scheme is used? Are the userPassword values prefixed with {MD5} or with {CRYPT}? In the latter case libcrypt on both systems could be incompatible. So this could be another issue. The general advice is not to use {CRYPT}. Recommended is to use salted SHA-1 (password scheme {SSHA}).
You also need to make sure that the new server was built with support for your chosen hash scheme. If using crypt passwords, this means adding the --enable-crypt flag to the initial 'configure' command.
Even with salt, traditional Unix-style crypt is rather weak. It is only supported to allow easy migration of existing password files into LDAP.
Are you certain that the old hashes were loaded into the new server? Try using slapcat on the new server and looking at some entries to make sure.
If I look at the encrypted password before and after resetting it, the password hashes are different, even though they are supposedly the same password.
This could be because a salt is added before generating the hash.
Exactly. This one-to-many mapping is why salted hashes are more secure than unsalted ones. It forces any brute-force attacker to do vastly more work to test each possible password, and makes a lookup-table for inverting password hashes infeasibly large (we hope!)
As Michael says, it would make sense to use 2.4.16 for your new installation.
Andrew