Hi,
We have a similar scenario that the one explained in the post of Javier Manteiga: http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/200907/msg0...
We have deployed two servers: a master and a replica (delta-syncrepl). We added the chaining configuration that appears in openldap 2.4 administrator's guide (12.3.2) to handle the modifications originated from the replica.
Replica slapd.conf:
##################### # Chaining configuration # ##################### overlay chain chain-uri "ldap://192.168.1.10:389" chain-idassert-bind bindmethod="simple" binddn="cn=replicator,dc=example,dc=com" credentials="secret" mode="self" chain-return-error TRUE
########## # Replica # ########## database bdb suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" .... ################## # Syncrepl directives # ################## syncrepl rid=001 provider=ldap://192.168.1.10:389 type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" filter="(objectclass=*)" scope=sub attrs="*" schemachecking=on binddn="cn=replicator,dc=example,dc=com" bindmethod=simple credentials=secret sizelimit=unlimited logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog
# Refer updates to the master updateref ldap://192.168.1.10:389
The problem appears when we change the single master for a mirrormode configuration (administrator guide 18.3.4.1). In addition, we set up a back-ldap proxy between mirror and replica.
back-ldap proxy slapd.conf:
######## # Proxy # ######## database ldap suffix "dc=example,dc=com" rootdn "cn=slapd-ldap"
uri "ldap://192.168.1.20:389 ldap://192.168.1.30:389"
The IP addresses are: 192.168.1.10 -> Back-ldap proxy 192.168.1.20 -> Mirror mode server 1 192.168.1.30 -> Mirror mode server 2
When we try to modify the password through the replica, we get the following messages in the server where is located the proxy:
ldap-proxy[13175]: daemon: activity on 1 descriptor ldap-proxy[13175]: daemon: activity on: ldap-proxy[13175]: 12r ldap-proxy[13175]: ldap-proxy[13175]: daemon: read active on 12 ldap-proxy[13175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap-proxy[13175]: connection_get(12) ldap-proxy[13175]: connection_get(12): got connid=1002 ldap-proxy[13175]: connection_read(12): checking for input on id=1002 ldap-proxy[13175]: op tag 0x66, time 1270632398 ldap-proxy[13175]: conn=1002 op=2 do_modify ldap-proxy[13175]: conn=1002 op=2 do_modify: dn (uid=user,ou=people,dc=example,dc=com) ldap-proxy[13175]: => get_ctrls ldap-proxy[13175]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (noncritical) ldap-proxy[13175]: parseProxyAuthz: conn 1002 authzid="dn:uid=user,ou=people,dc=example,dc=com" ldap-proxy[13175]: slap_sasl_getdn: conn 1002 id=dn:uid=user,ou=people,dc=example,dc=com [len=38] ldap-proxy[13175]: >>> dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[13175]: <<< dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[13175]: ==>slap_sasl2dn: converting SASL name uid=user,ou=people,dc=example,dc=com to a DN ldap-proxy[13175]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[13175]: parseProxyAuthz: conn=1002 "uid=user,ou=people,dc=example,dc=com" ldap-proxy[13175]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com? ldap-proxy[13175]: <== slap_sasl_authorized: return 48 ldap-proxy[13175]: <= get_ctrls: n=1 rc=123 err="not authorized to assume identity" ldap-proxy[13175]: send_ldap_result: conn=1002 op=2 p=3 ldap-proxy[13175]: send_ldap_result: err=123 matched="" text="not authorized to assume identity" ldap-proxy[13175]: send_ldap_response: msgid=3 tag=103 err=123 ldap-proxy[13175]: conn=1002 op=2 RESULT tag=103 err=123 text=not authorized to assume identity ldap-proxy[13175]: conn=1002 op=2 do_modify: get_ctrls failed ldap-proxy[13175]: daemon: activity on 1 descriptor ldap-proxy[13175]: daemon: activity on:
The authorization is denied for cn=replicator,dc=example,dc=com.
The error looks self-explanatory: the identity "cn=replicator,dc=example,dc=com" is not authorized to assume the identity of the client that attempted the write. The failure appears to happen in slap_sasl2dn(), where the user's DN is converted to <nothing> (the "mapping" fails). It is not clear why it fails. You probably do not show enough of your master and replica slapd.conf.
p.