Hi, I'm trying to migrate my directory from one server to another (I'm building a replacement server and want to test everything before changing over). The old server is FreeBSD 5 with openldap-server-2.3.39 The new one is FreeBSD 7.1 with openldap-server-2.3.43
I thought I would be able to use ldapsearch to dump the contents of the old server to an ldif file and then import it into the new one using ldapadd.
That seemed to work, but when I tried to login on a workstation which is configured to use ldap authentication (and works fine when attached to the old server), my login fails. If I change my password to what it's supposed to be and then try to login, it works.
So it appears that the passwords for user objects are not being transferred correctly from the old system to the new (all the other information seems correct).
I'm using md5 passwords on both systems (the freebsd default) and I've checked that the new server & the workstation are set to use md5.
I also tried using slapcat to create the ldif file, but that made no difference. 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. I've tried this several times and can't get it to work.
Do I need to do something else to transfer passwords correctly from one server to another?
Ian Moore wrote:
Hi, I'm trying to migrate my directory from one server to another (I'm building a replacement server and want to test everything before changing over). The old server is FreeBSD 5 with openldap-server-2.3.39 The new one is FreeBSD 7.1 with openldap-server-2.3.43
Why not use OpenLDAP 2.4.16 on the new server. It's marked stable and 2.3.x is not actively maintained anymore.
I thought I would be able to use ldapsearch to dump the contents of the old server to an ldif file and then import it into the new one using ldapadd. [..] So it appears that the passwords for user objects are not being transferred correctly from the old system to the new (all the other information seems correct).
LDAP search is subject to access control. It's good news that you couldn't download userPassword values.
For various reasons I'd strongly recommend to use slapcat on the old server to export the data and slapadd on the new server to import it.
I'm using md5 passwords on both systems (the freebsd default) and I've checked that the new server & the workstation are set to use md5. [..] I also tried using slapcat to create the ldif file, but that made no difference.
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}).
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.
Ciao, Michael.
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
openldap-technical@openldap.org
-
Andrew Findlay -
Ian Moore -
Michael Ströder