Is there a way to copy passwords between OpenLDAP directories?

I am trying to migrate an old OpenLDAP instance from Centos-7 to Rocky-9. I have created an Ansible playbook and everything works except the user passwords. I used slapcat to extract the accounts and then ldapadd to import them. e.g.

ldapadd -x -D cn=Manager,dc=example,dc=com -W -f /root/newusers.yml -v

I recently updated the old server to Centos-7.9 so it had the latest possible available patches, and have noticed that the migration works for users that have recently been created or have changed their passwords, but not for older accounts.

Is there a better way to migrate users without having to reset all user passwords?

The directory does store hash of password, doesn’t it?
The old passwords were hashed with method “A”. The new ones with method “B”.
The el7 ldap clearly supports both methods. The el9 version supports only the B.

A logical question is what was the A and is there any chance to re-enable it in el9?
(Naturally, the A is now weak, so use of it is probably not recommended even if possible.)


hashing is a one-way function (i.e., it is impossible to “decrypt” a hash and obtain the original plaintext value)

Which means that one cannot “re-hash” those old hashes with B.

Thanks for taking the time to reply, it is greatly appreciated.

I understand that I cannot decrypt a hash and that was not my intention, only to preserve the 500+ users’ passwords so they didn’t have to re-enter them.

The key seems to be that when I patched the OS something was updated in OpenLDAP that changed the hashing algorithm, or method A was replaced by B as you put it. I wonder now if there is a way to activate the weaker (A) method as read-only/legacy for existing users?

It’s an interesting idea and I’ll do some digging.

You shouldn’t use ldapadd. You should be using slapcat on the old instance and then slapadd on the new instance. When you perform an ldapadd, the expectation is that userPassword is in cleartext so that openldap can actually perform the hashing itself. If you’re using slapcat/slapadd, you have a better chance of that hash actually working for that object.

1 Like

I have been using slapcat to export the user data as an LDIF file and the copied it to my new server and used ldapadd (as you said), but the strange thing is that I created a couple of new accounts after patching the Centos 7 server to 7.9.2011 and those passwords still work so there must be something else at play here?

I also deleted a test user account and reimported using slapadd and the user still can’t login?

You can view the password hashes in the

  • directory that runs on CentOS 7
  • (slapcat) exported file
  • directory that runs on Rocky (after import with ldapadd)
  • directory that runs on Rocky (after import with slapadd)

The assumption is that ‘ldapadd’ hashes the input – directory gets different value than in the file – and ‘slapadd’ copies value verbatim into the directory.

If values change on export/import, then a hash gets re-hashed and use for auth checks should fail.

If the directory in Rocky gets exact same hashed value as is in the CentOS directory, then the issue is logically that ldap version in Rocky does not support the hash method in auth check.

1 Like

I found I can use strings on the db files and get the {sha} string. I copied this to the ldif file on my new machine and the users I tested could login.
I need to see if I can improve this solution.