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:
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.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?.
p.