Hi,
Ok, i understand that the problem is authorization, but when i sup s the back-ldap proxy from my scenario it works.
I am going to give more details.
First Scenario:
---------------------
A delta syncrepl server replicating from the first server of a mirror.
IPs: delta syncrepl (192.168.1.5), mirror server 1 (192.168.1.10), mirror server 2 (192.168.1.20)
replica slapd.conf
#####################
# Chaining configuration #
#####################
overlay chain
chain-uri "ldap://mirror1:389"
chain-idassert-bind bindmethod="simple"
binddn="cn=replicator,dc=example,dc=com"
Sorry, I take the last sentence back: mapping a DN to nothing means there
was nothing to map. The failure is just later, where (pretty
self-explanatory):
ldap-proxy[13175]: ==>slap_sasl_authorized: canthe entry "cn=replicator,dc=example,dc=com" does not have the right to
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"
assume the identity of "uid=user,ou=people,dc=example,dc=com".
> You probably do not show
> enough of your master and replica slapd.conf.
This is correct. Also, the error may depend on the value of the
authzTo/authzFrom attributes of the identities involved in the mapping.
As clearly stated in slapd-ldap man page about idassert:
[snip] Other identity assertion modes
are anonymous and self, which pectively mean that the empty
or the client’s identity will be asserted; [snip]
For all modes that require
the use of the proxyAuthz control, on the remote server the
proxy identity must have appropriate authzTo permissions, or the
asserted identities must have appropriate authzFrom permissions.
p.