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.

Is it the same problem with the propagation of identity?

Is there any way to avoid the problem?

Thanks in advance.

Javier Manteiga wrote:

We are trying to set a system with the DIT split in several servers, using the Meta backend to proxy the LDAP requests among them. In the remote servers we would like to check the ACLs using the identity of the

client that sent the request, instead of the identity used to create the proxy connections. For this we have configured the idassert parameters in the meta targets as follows:

idassert-bind bindmethod=simple

binddn="cn=manager,dc=operator,dc=com" (root user of the backend receiving the proxied query) credentials="manager" mode=self iddassert-authzFrom "dn:*"

When the first proxy is made everything is OK. The proxyAuthz extension control is added to the LDAP message and the remote server behaves as expected.

Our problem is that in some cases we have requests that must be proxied

several times. E.g: consider a scenario with three servers in A, B and C. in which the LDAP request sent by the external client is received in A, this server proxies it to B. Finally B proxies it to C. When B tries

to set the proxyAuthz control it detects that there is already one and it returns the error "proxyAuthz not allowed within namingContext".

Is there anyway in which we can avoid this error and propagate the

credentials of the external client to the last server?.

No. If you use proxyAuthz to propagate the client's identity to a remote server, then the remote server cannot use the same trick to propagate what it believes the client's identity, while it's actually the first proxy's identity. By design we decided to disallow nested identity assertion. This mechanism requires distributed procedures, where any control like *proxyAuthz would be wrapped by procedure distribution information, thus *allowing nested chaining and so. This was discussed long ago when chaining and identity assertion were first implemented. The I.D. about distributed procedures expired long ago, and was never revitalized, so this functionality is not available.

p.