OpenLDAP ACLs Question

[Tim Gustafson <tjg@soe.ucsc.edu>]

Hi,

We have three OpenLDAP servers: 10.0.0.2, 10.0.0.3 and 10.0.0.4 and one web server 10.0.0.5.

For a long time we've had two baseDN databases running on the OpenLDAP servers with ACLs configured so that anyone on the subnet can read anything in the system and our replication has been working well.

Recently, we've added the third database with more restrictive ACLs that look like this:

============================================================
access to *
 by dn="uid=replicator,ou=People,dc=bar" read
 by * break

access to attrs=userPassword,sambaNTPassword
 by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write
 by self write
 by anonymous auth
 by * none

access to attrs=entry,uid,cn,sn,givenName,title,departmentNumber,mail,telephoneNumber,roomNumber
 by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write
 by users read
 by * none

access to *
 by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write
 by * none
============================================================

With these ACLs, replication works when anyone in the ldap-admins group posts an update to the server.  However, if a user updates their own password, replication does not take place.  If we change the last access clause to this:

============================================================
access to *
 by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write
 by peername.regex="10\.0\.0\.5" read
 by * none
============================================================

then the user self-updates are replicated properly.  Note that 10.0.0.5 is the *web server*.  The way I read this ACL, it means we're granting read access to the web server, and in so doing, the other two LDAP servers (10.0.0.3 and 10.0.0.4) are magically able to replicate data again.

When replication is *not* working in this set-up, re-starting slapd on 10.0.0.3 and 10.0.0.4 (without changing any ACLs anywhere) causes them to suck down all the updates they missed before.

Am I misunderstanding the way these ACLs work?  Is there any way that giving READ access to the web server (which it already has by virtue of the user having bound themselves to the LDAP server) should cause replication for 10.0.0.3 and 10.0.0.4 to work again?  Or is this perhaps a bug in the version of slapd (2.3.43; yes I know it's old; it's a vendor package and that's how we roll around here at the moment) that we're running?

I'm not really asking anyone to fix the problem or to offer a solution to the problem...I just want to know if this sort of replication issue was a known problem in the past?


Tim Gustafson
Baskin School of Engineering
UC Santa Cruz
tjg@soe.ucsc.edu
831-459-5354