OpenLDAP ACLs Question

[Tim Gustafson]

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

[Andrew Findlay]

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

I assume you are using syncrepl here.

It would be worth checking that the replication process really does
bind as that DN. If it does, then all later access clauses are
irrelevant.

Post by Tim Gustafson
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?

This does not sound like an ACL problem to me. I would suggest setting
up a test environment with the latest 2.4.x release to see what
happens.

Andrew

[Buchan Milne]

Post by Tim Gustafson
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.

How is replication configured? Single master and multiple replicas
synchronising off it (which is the master)? MMR or cascading replication
(provide a diagram or description)?

Post by Tim Gustafson
If we change

I assume "change" implies restarting slapd ...
[...]

Post by Tim Gustafson
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.

So, adding an irrelevant ACL, *and* restarting slapd causes the replication to
resume? So, when this occurs, have you tested just restarting slapd?

Post by Tim Gustafson
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.

So, if the ACLs are not modified, but the a restart of slapd forces
replication, why would this be an ACL issue(or did I misunderstand this
sentence)?

Maybe instead you should post your replication configuration?

Note, there are some still some reliability issues (IMHO) with syncrepl, in
that it doesn't always handle connection failures without manual intervention.
If these are fixed (I haven't been able to test them myself) in 2.4.x, they are
probably still present in 2.3.x. For example, a firewall in between provider
and consumer with infrequent changes where the firewall drops idle connections
and the hosts have incorrect keepalives set would result in replication
failures with refreshAndPersist.

Post by Tim Gustafson
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?

You don't post anything related to your replication configuration when asking
about a replication failure, so it is difficult to provide any more information.

Regards,
Buchan