One of issues with my previous post (that i’m not going to go into at the moment) was that I hadn’t cross-compiled openssl and cyrus-sasl2 so my version of slapd didn’t support either. I think i’ve now resolved this and you can download my latest slapd here: https://dl.dropboxusercontent.com/u/713/slapd

#1- I needed the slave to refer changes to the master

Documentation and discussion everywhere seems to suggest simply adding a line to the slave slapd.conf;

updateref ldap://192.168.10.250

Would ensure any changes were written to the master but I couldn’t get this working (even with debug enabled). The only error I could really find (from memory) was an err=49 which I believe refers to invalid credentials but i’m unsure which credentials or how this is possible.

After further research, I found that there is an alternatively openldap configuration referred to as n-way multi master. Rather than specifying a master and slave, both nodes are masters and changes are replicated both ways. This was relatively easy to setup and “just worked” (not to mention, a better solution as before it was possible the “master” server would be unreachable (if the site-to-site VPN was down) and changes would fail).

You will find config details for n-way multi master / mirrormode in my next blog post.

This was a real curve ball. Google sent me in completely the wrong direction, but I recalled a discussion about multiple passwords being stored in the LDAP database, which led me to wonder if the userPassword wasn’t the only field needing to be updated.

A colleague stumbled across the documentation for pGina fork: http://mutonufoai.github.io/pgina/documentation/plugins/ldap.html which shows a rather more complete “Change Password” configuration for the LDAP plugin. Unfortunately pGina main doesn’t support the DES or Timestamp methods so we couldn’t configure sambaLMPassword, shadowLastChange or sambaPwdLastSet, but adding sambaNTPassword (MD4) alongside userPassword (SHA1) seems to have done the trick.

#3- Data was replicating but the users could not login

I’m not sure exactly how I figured this one out. I think I had a vague recollection of reading a discussion about passwords not replication because default permissions do not allow them to be read from the database.

I added a line in slapd.conf above the existing ACL include;

include /usr/syno/etc/openldap/acls.conf
include /usr/syno/etc/openldap/slapd-acls.conf

The contents of which;

access to attrs=userPassword,sambaLMPassword,sambaNTPassword
by dn.base="cn=replication,cn=users,dc=example,dc=com" write

Allow the password to be read from the database by the replication user.