LDAP replication and CRYPT userPassword

       371 words, 2 minutes

I have just discovered some issues with my previous article on OpenLDAP replication between Synology DSM and OpenBSD OpenLDAP.

In the end, it is not possible to log-in on the OpenBSD LDAP instance using the original userPassword. Short story: CRYPT seem to not be various-platform-compatible.

When I did my replication testings, I changed text values and group memberships. But it seems I didn’t test password modification. So when I changed my password on DSM, the hash was replicated properly on OpenBSD. But I couldn’t bind using it ; getting bind failed: LDAP_INVALID_CREDENTIALS(49).

The thing is, OpenLDAP on Synology stores userPassword using the CRYPT hash. And reading What are {CRYPT} passwords and how do I generate them? :

Crypt(3) behavior not only differs from system to system, but differs from implementation to implementation. For compatibility, slapd(8) must be linked with same crypt(3) implementation, and on the same system, as the program that was used to generate the crypt(3) password values.

{CRYPT} passwords are supported for migration purposes only. Use of {SSHA} passwords is recommended.

This can be seen using the console:

# ldapsearch -x -H ldaps://synology.tumfatig.local -D "cn=config" -W \
  -b "olcDatabase={-1}frontend,cn=config" olcPasswordHash
# {-1}frontend, config
dn: olcDatabase={-1}frontend,cn=config
olcPasswordHash: {CRYPT}

And it can be changed using the console too:

# ldapmodify -x -H ldaps://synology.tumfatig.local -D "cn=config" -W
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
replace: olcPasswordHash
olcPasswordHash: {SSHA}

modifying entry "olcDatabase={-1}frontend,cn=config"

^D

The userPasswords will now be stored and transferred using SSHA.

Unfortunately, one has to change its password so that it is stored in SSHA. In my case, I don’t care forcing my few users to do it. But in case you have thousands, this may suck. Anyway, the SSHA password replicated on OpenBSD/OpenLDAP can now be used properly with tools like /usr/libexec/auth/login_-ldap 😅

While we’re here, I also discovered that setting a proper replication filter in the OpenLDAP consumer allows to prevent dropping the initial LDAP content and inserting it before starting the slave instance. Simply modify the configuration to include:

--- /etc/openldap/slapd.conf.orig Sun Oct 29 18:32:00 2018
+++ /etc/openldap/slapd.conf Mon Nov 5 16:26:15 2018
@@ -78,4 +78,5 @@
retry="5 10 300 +"
searchbase="dc=synology,dc=tumfatig,dc=local"
+ filter="(|(objectClass=posixAccount)(objectClass=posixGroup))"
attrs="*,+"
bindmethod=simple

Start the empty Secondary and let it fill from the Primary.

That’s all by now…

Related posts: