[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Slapd-ldap proxy between replica and mirror
>> 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/msg00180.html
>>
>> 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.
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: 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"
the entry "cn=replicator,dc=example,dc=com" does not have the right to
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 respectively 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.