Recommended strategy for replicating cn=config database

[Jonathan Underwood <jonathan.underwood@gmail.com>]

Hi,

I currently have a working N-way multimaster setup (where N=2) and am
using sasl/gssapi/kerberos for authenticated binding. I am using the
ldap service principals for each host to authenticate, and this is
working fine for allowing me to replicate databases other than the
cn=config database, where I see the following in the logs:

Jul 12 18:28:04 auth1 slapd[4411]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT
Jul 12 18:28:04 auth1 slapd[4411]: do_syncrep2: rid=001
LDAP_RES_SEARCH_RESULT (32) No such object
Jul 12 18:28:04 auth1 slapd[4411]: do_syncrep2: rid=001 (32) No such object
Jul 12 18:28:04 auth1 slapd[4411]: do_syncrepl: rid=001 rc -2 retrying
(29 retries left)

where rid=001 corresponds to the entry:

olcSyncRepl: rid=001
  provider=ldap://auth0.domain
  bindmethod=sasl saslmech=gssapi
  searchbase="cn=config"
  type=refreshAndPersist
  retry="30 30 300 +" timeout=1

The reason this isn't working is clear: slapd on the consumer is not
binding as the rootdn of the cn=config tree, and so therefore cannot
search that database.

I am not sure what the best fix is for this, particularly from a
security point-of-view. My first thought was to add an ACL to the
cn=config database such as olcAccess: to * by users read by * none,
but this then opens up the cn=config tree to be readable by any
authenticated user, which is somewhat undesirable.

Does anyone have a suggestion as to a good strategy to allow cn=config
replication in this situation?

Thanks in advance,
Jonathan.