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 t...@soe.ucsc.edu 831-459-5354
