Ian wrote:
On Tue, 21 Apr 2009 23:07:11 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}).
Well FreeBSD is using MD5 for it's encryption and so is the linux workstation.
This does not say much since there are also MD5-based password hashes in Unix crypt.
Is the LDAP server encrypting the hashes as well?
No, the clear-text password is hashed depending on the password scheme together with a random salt.
They don't look like the hashes in master.password
What is master.password?
at all, so I guess it is? And that's one reason why you need to use the PADL scripts when you import /etc/passwd into your LDAP directory?
If you import /etc/shadow or whereever your salted Unix password hashes are stored you would use the platform-specific password scheme {CRYPT}.
The password entry looks like this: userPassword:: e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0=
^^ The double-colon indicates that the value is base64-encoded in the LDIF representation.
$ python -c "print 'e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0='.decode('base64')" {md5}547qEjL5yQnfIp7aDAXd8w==
So this is a plain MD5-hashed password. This password scheme is *not* platform-specific. Is this from your original data? Do all entries have password values like this? Check that. If yes, then you should not have a problem to migrate this data.
So I don't know what encoding it's using - is there a setting that controls this? (nothing in slapd.conf that I can see).
There are various relevant settings. But I wonder which component is used for setting the password and which mechanism it uses.
You should also consult the fine articles in the FAQ-O-MATIC:
http://www.openldap.org/faq/data/cache/419.html
Ciao, Michael.
On Wed, Apr 22, 2009 at 09:56:51AM +0930, Ian wrote:
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.
Maybe that's where the problem lies. From what Michael said in his reply, the passwords are plain MD5 hashes. Perhaps I've build the new one with crypt support and it's trying to use that instead of straight MD5?
Unlikely. I don't think it is possible to disable the MD5 hash support.
Yes, that was the first thing I checked when I couldn't login. The hashes are exactly the same on both servers.
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.
But then On Tue, Apr 21, 2009 at 04:43:51PM +0200, Michael Ströder wrote:
$ python -c "print 'e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0='.decode('base64')" {md5}547qEjL5yQnfIp7aDAXd8w==
So this is a plain MD5-hashed password. This password scheme is *not*
... and the interesting thing there is that you are using a *non-salted* hash scheme. That means that a given password should always produce the same hash, yet you have found that resetting the password produces a different hash.
To diagnose this further I would use ldapsearch directly, rather than involving the Linux or FreeBSD nss_ldap client. Something like this:
ldapsearch -x -H ldap://oldserver/ -D <user account DN> -w <password> \ -b '' -s base '(objectclass=*)'
Try the same account on the old and the new server, having made sure that the password hashes for that account are identical. Run both ldapsearch commands from the same window on the same machine. If one server accepts the search and the other one does not then you have a good test case.
One area that might be worth checking is character sets. If your test password has any non-ASCII characters then success may be dependent on the default character set of the client machine (which is why I said to use the same window for both tests above).
If you still get different results for your old and new servers then I would start to suspect a bug in the MD5 implementation, though this is very unlikely as OpenLDAP has its own copy of MD5 which has not changed since July 2000:
http://www.openldap.org/devel/cvsweb.cgi/libraries/liblutil/md5.c.diff?r1=1....
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Michael Ströder