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.
On 12 July 2011 18:38, Jonathan Underwood jonathan.underwood@gmail.com wrote:
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:
^^^^ here of course, I mean the olcDatabase={0}config,cn=config database
On Dienstag 12 Juli 2011 19:38:57 Jonathan Underwood wrote:
Hi,
[..]
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.
Why not use a more restrictive ACL that only gives the identities read access that really need it? E.g. by using the UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth DN form that slapd generates when SASL is used. (If you plan add more mirrormode nodes, it might probably be better to create a group for them)
Does anyone have a suggestion as to a good strategy to allow cn=config replication in this situation?
Thanks in advance, Jonathan.
Ralf
openldap-technical@openldap.org