LDAP replication change

Up to today LDAP replication was done using slurpd-style replication. In this setup the LDAP master pushes changes to the various slaves. For this to work the slave must be accessible by the master. This was setup using encryption (self signed certificates). This replication method is deprecated as of OpenLDAP 2.3 in favour of ‘syncrepl’. OpenLDAP 2.4 doesn’t even have slurpd-style replication. Changing the replication method is important as I want to be able to upgrade to RHEL6 without being forced to do other changes at the same time.

The biggest drawback about slurpd is that it only replicates the changes. Meaning: If you have a new slave, you first have to stop the master, dump the database, then load this database on the slave, then start the slave and the master. Really annoying and during this time your master LDAP server is down!

With syncrepl-style replication the slaves contact the master. Slaves are now called consumers and the master is the provider. I don’t like consumers contacting the provider as I don’t want a security issue on some external host to cause security problems on the LDAP master db. I’ve tried to minimize the risk by using encryption (self signed certificates, server won’t accept any other certificates), using iptables, restricting the LDAP logon to just one user (to ensure brute forcing userPassword entries by logging in often will not work), not replicating the userPassword attribute, not allowing database modifications from external clients and some ACL restrictions.

There are two things I like about syncrepl.

1. After it connecting with the provider it checks the consistency of the database. At one point the SVN machine missed just one uid entry. That person couldn’t log in. With sycnrepl such a problem is not possible (ignoring possible config errors like ACLs).
2. You can restrict what is replicated to the slave using ACLs on the master.

Syncrepl has two ways of working, using refreshOnly it checks for LDAP changes every x minutes (configurable). This isn’t as nice as slurpd as I want all LDAP changes to be propagated instantly (even if the SSH sync script only runs once an hour). Fortunately it also has a refreshAndPersist, where it first checks and then waits for change notifications from the provider.

Tips to ensure a working syncrepl:

• Make sure the DNS entry points to the right server
• Make sure that DNS entry has not been manually added in /etc/hosts
• Make sure the userid running slapd can actually access the various certificate files
• If you test using ldapsearch, make sure /etc/openldap/ldap.conf has a TLS_CACERT entry
• Make sure the TLS_CACERT file can actually be read by the user running ldapsearch
• slapd (etc) -d 1023 contains the debug messages, you won’t find them anywhere else (by default)
• Kill any running nscd and wipe it off the system
• etc etc etc