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.

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.