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.
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.
Hi,
Ok, i understand that the problem is authorization, but when i supress 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 http://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" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_forward_updates ppolicy_hash_cleartext overlay memberof
################## # Syncrepl directives # ################## syncrepl rid=001 provider=ldap://mirror1:389 http://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://mirror1:389 http://192.168.1.10:389/
------------------------- -------------------------
slapd.conf of mirror server #1 ------------------------------------------- # Global section
serverID 1
moduleload memberof
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword,userPKCS12 by self write by dn.base="cn=replicator,dc=example,dc=com" read by * auth
access to attrs=shadowLastChange by self write by * read
# Give the replica DN unlimited read access. This ACL needs to be # merged with other ACL statements, and/or moved within the scope # of a database. The "by * break" portion causes evaluation of # subsequent rules. See slapd.access(5) for details.
access to * by dn.base="cn=replicator,dc=example,dc=com" read by * break
access to * by * read
# Load the accesslog overlay moduleload accesslog.la
#Load the syncprov overlay moduleload syncprov.la
# Accesslog database definitions database bdb
monitoring off
suffix cn=accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################### # BDB database definitions #######################################################################
database bdb
monitoring off
suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_hash_cleartext overlay memberof
# Habilitar authz-policiy authz-policy to
index entryCSN eq index entryUUID eq
# syncrepl Provider for primary db overlay syncprov syncprov-checkpoint 1000 60
# accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ####################################################
# MirrorMode - Syncrepl directive syncrepl rid=001 provider=ldap://mirror2:389 bindmethod=simple binddn="cn=Administrator,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on
--------------- ---------------
In the mirror servers we have set the attribute authzTo for the replicator dn:
ldapsearch -x -b 'cn=replicator,dc=example,dc=com' -H ldap://mirror1:389 -D 'cn=Administrator,dc=example,dc=com' -w secret authzTo
# replicator, example.com dn: cn=replicator,dc=example,dc=com authzTo: ldap:///dc=example,dc=com??sub?(objectClass=person)
When we launch the following modification through the replica: ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=example,dc=com"
In the mirror server we get:
ldap-mirror1[2649]: conn=1002 op=2 PROXYAUTHZ dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD attr=userPassword ldap-mirror1[2649]: conn=1002 op=2 RESULT tag=103 err=0 text=
Therefore modifying through the replica server is possible with the chaining configuration.
Second sceneario -------------------------- The problem appears when we introduce the back-ldap proxy server to set the high availability feature that provides the mirror mode.
IPs: ----- 192.168.1.5 -> delta syncrepl 192.168.1.10 -> Back-ldap proxy 192.168.1.20 -> Mirror mode server 1 192.168.1.30 -> Mirror mode server 2
back-ldap proxy slapd.conf:
database ldap suffix "dc=example,dc=com" uri "ldap://mirror1:389 ldap://mirror2:389" rootdn "cn=Administrator,dc=example,dc=com"
overlay ppolicy
Launching the modification to the proxy, it works:
ldapmodify -x -H ldap://proxy:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=udg77530,ou=people,dc=example,dc=com"
The /var/log/messages of proxy and mirror shows the following:
ldap-proxy[4051]: conn=1000 fd=8 ACCEPT from IP=192.168.1.5:42921 (IP= 192.168.1.10:389) ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1015 fd=19 ACCEPT from IP=192.168.1.10:18103 (IP= 192.168.1.20:1389) ldap-mirror1[3438]: conn=1015 op=0 BIND dn="" method=128 ldap-mirror1[3438]: conn=1015 op=0 RESULT tag=97 err=0 text= ldap-mirror1[3438]: conn=1015 op=1 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 fd=20 ACCEPT from IP=192.168.1.10:18104 (IP= 192.168.1.20:1389) ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1016 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1015 op=2 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-proxy[4051]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-proxy[4051]: conn=1000 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1015 op=3 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[3438]: conn=1016 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1016 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=2 UNBIND ldap-mirror1[3438]: conn=1016 op=2 UNBIND ldap-mirror1[3438]: conn=1016 fd=20 closed ldap-proxy[4051]: conn=1000 fd=8 closed
But when the modification is made through the replica server we get the error:
ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=rexample,dc=com" ldap_modify: unknown result code (123)
ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: 12r ldap-proxy[3688]: ldap-proxy[3688]: daemon: read active on 12 ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap-proxy[3688]: connection_get(12) ldap-proxy[3688]: connection_get(12): got connid=1001 ldap-proxy[3688]: connection_read(12): checking for input on id=1001 ldap-proxy[3688]: op tag 0x66, time 1271064513 ldap-proxy[3688]: conn=1001 op=2 do_modify ldap-proxy[3688]: conn=1001 op=2 do_modify: dn (uid=user,ou=people,dc=example,dc=com) ldap-proxy[3688]: => get_ctrls ldap-proxy[3688]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (noncritical) ldap-proxy[3688]: parseProxyAuthz: conn 1001 authzid="dn:uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: slap_sasl_getdn: conn 1001 id=dn:uid=user,ou=people,dc=example,dc=com [len=38] ldap-proxy[3688]: >>> dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: <<< dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: ==>slap_sasl2dn: converting SASL name uid=user,ou=people,dc=example,dc=com to a DN ldap-proxy[3688]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[3688]: parseProxyAuthz: conn=1001 "uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com? ldap-proxy[3688]: <== slap_sasl_authorized: return 48 ldap-proxy[3688]: <= get_ctrls: n=1 rc=123 err="not authorized to assume identity" ldap-proxy[3688]: send_ldap_result: conn=1001 op=2 p=3 ldap-proxy[3688]: send_ldap_result: err=123 matched="" text="not authorized to assume identity" ldap-proxy[3688]: send_ldap_response: msgid=3 tag=103 err=123 ldap-proxy[3688]: conn=1001 op=2 RESULT tag=103 err=123 text=not authorized to assume identity ldap-proxy[3688]: conn=1001 op=2 do_modify: get_ctrls failed ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
The file pass1_user.ldif has:
dn: uid=user,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: ####CRYPT PASSWORD####
Thank you for your help.
On Fri, Apr 9, 2010 at 19:51, masarati@aero.polimi.it wrote:
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 modesare 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.
Hi,
Ok, i understand that the problem is authorization, but when i supress 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 http://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" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_forward_updates ppolicy_hash_cleartext overlay memberof
################## # Syncrepl directives # ################## syncrepl rid=001 provider=ldap://mirror1:389 http://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://mirror1:389 http://192.168.1.10:389/
slapd.conf of mirror server #1
# Global section
serverID 1
moduleload memberof
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword,userPKCS12 by self write by dn.base="cn=replicator,dc=example,dc=com" read by * auth
access to attrs=shadowLastChange by self write by * read
# Give the replica DN unlimited read access. This ACL needs to be # merged with other ACL statements, and/or moved within the scope # of a database. The "by * break" portion causes evaluation of # subsequent rules. See slapd.access(5) for details.
access to * by dn.base="cn=replicator,dc=example,dc=com" read by * break
access to * by * read
# Load the accesslog overlay moduleload accesslog.la
#Load the syncprov overlay moduleload syncprov.la
# Accesslog database definitions database bdb
monitoring off
suffix cn=accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################### # BDB database definitions #######################################################################
database bdb
monitoring off
suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_hash_cleartext overlay memberof
# Habilitar authz-policiy authz-policy to
index entryCSN eq index entryUUID eq
# syncrepl Provider for primary db overlay syncprov syncprov-checkpoint 1000 60
# accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ####################################################
# MirrorMode - Syncrepl directive syncrepl rid=001 provider=ldap://mirror2:389 bindmethod=simple binddn="cn=Administrator,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on
In the mirror servers we have set the attribute authzTo for the replicator dn:
ldapsearch -x -b 'cn=replicator,dc=example,dc=com' -H ldap://mirror1:389 -D 'cn=Administrator,dc=example,dc=com' -w secret authzTo
# replicator, example.com dn: cn=replicator,dc=example,dc=com authzTo: ldap:///dc=example,dc=com??sub?(objectClass=person)
When we launch the following modification through the replica: ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=example,dc=com"
In the mirror server we get:
ldap-mirror1[2649]: conn=1002 op=2 PROXYAUTHZ dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD attr=userPassword ldap-mirror1[2649]: conn=1002 op=2 RESULT tag=103 err=0 text=
Therefore modifying through the replica server is possible with the chaining configuration.
Second sceneario
The problem appears when we introduce the back-ldap proxy server to set the high availability feature that provides the mirror mode.
IPs:
192.168.1.5 -> delta syncrepl 192.168.1.10 -> Back-ldap proxy
^^^ The proxy takes the IP that was of the master; thus, the replica will refer modifications to the proxy
192.168.1.20 -> Mirror mode server 1 192.168.1.30 -> Mirror mode server 2
back-ldap proxy slapd.conf:
database ldap suffix "dc=example,dc=com" uri "ldap://mirror1:389 ldap://mirror2:389" rootdn "cn=Administrator,dc=example,dc=com"
overlay ppolicy
Launching the modification to the proxy, it works:
ldapmodify -x -H ldap://proxy:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=udg77530,ou=people,dc=example,dc=com"
The /var/log/messages of proxy and mirror shows the following:
ldap-proxy[4051]: conn=1000 fd=8 ACCEPT from IP=192.168.1.5:42921 (IP= 192.168.1.10:389) ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1015 fd=19 ACCEPT from IP=192.168.1.10:18103 (IP= 192.168.1.20:1389) ldap-mirror1[3438]: conn=1015 op=0 BIND dn="" method=128 ldap-mirror1[3438]: conn=1015 op=0 RESULT tag=97 err=0 text= ldap-mirror1[3438]: conn=1015 op=1 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 fd=20 ACCEPT from IP=192.168.1.10:18104 (IP= 192.168.1.20:1389) ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1016 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1015 op=2 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-proxy[4051]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-proxy[4051]: conn=1000 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1015 op=3 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[3438]: conn=1016 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1016 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=2 UNBIND ldap-mirror1[3438]: conn=1016 op=2 UNBIND ldap-mirror1[3438]: conn=1016 fd=20 closed ldap-proxy[4051]: conn=1000 fd=8 closed
But when the modification is made through the replica server we get the error:
ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=rexample,dc=com" ldap_modify: unknown result code (123)
ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: 12r ldap-proxy[3688]: ldap-proxy[3688]: daemon: read active on 12 ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap-proxy[3688]: connection_get(12) ldap-proxy[3688]: connection_get(12): got connid=1001 ldap-proxy[3688]: connection_read(12): checking for input on id=1001 ldap-proxy[3688]: op tag 0x66, time 1271064513 ldap-proxy[3688]: conn=1001 op=2 do_modify ldap-proxy[3688]: conn=1001 op=2 do_modify: dn (uid=user,ou=people,dc=example,dc=com) ldap-proxy[3688]: => get_ctrls ldap-proxy[3688]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (noncritical) ldap-proxy[3688]: parseProxyAuthz: conn 1001 authzid="dn:uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: slap_sasl_getdn: conn 1001 id=dn:uid=user,ou=people,dc=example,dc=com [len=38] ldap-proxy[3688]: >>> dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: <<< dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: ==>slap_sasl2dn: converting SASL name uid=user,ou=people,dc=example,dc=com to a DN ldap-proxy[3688]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[3688]: parseProxyAuthz: conn=1001 "uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com? ldap-proxy[3688]: <== slap_sasl_authorized: return 48 ldap-proxy[3688]: <= get_ctrls: n=1 rc=123 err="not authorized to assume identity" ldap-proxy[3688]: send_ldap_result: conn=1001 op=2 p=3 ldap-proxy[3688]: send_ldap_result: err=123 matched="" text="not authorized to assume identity" ldap-proxy[3688]: send_ldap_response: msgid=3 tag=103 err=123 ldap-proxy[3688]: conn=1001 op=2 RESULT tag=103 err=123 text=not authorized
The proxy receives the PROXYAUTHZ request, and doesn't know how to map the authorization identity. You need to tell your proxy how to collect the required information, which basically consists in setting an "acl-bind" line like
acl-bind bindmethod="simple" binddn="cn=replicator,dc=example,dc=com" credentials="secret"
Use whatever identity lets you collect security related operational data like authzTo and authzFrom
I note that there are a couple of bugs that would prevent this from working as expected:
1) back-ldap's ldap_back_entry_get() function uses whatever controls were set for the operation. As a consequence, who results in calling backend_attribute(), in this case slap_sasl_check_authz(), needs to clear the controls attached to the original request, otherwise the lookup of operational data required for the authorization would occur with the authorization taking place, which is not what we want.
2) authzSyntax validate function does not deal with the ordering prefix ("{X}"), and thus validation of returned data fails, so authorization data (authzTo and authzFrom) can't be collected.
Please file an ITS http://www.openldap.org/its/; in the meanwhile, I'll take care of the issues.
Thanks, p.
to assume identity ldap-proxy[3688]: conn=1001 op=2 do_modify: get_ctrls failed ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
The file pass1_user.ldif has:
dn: uid=user,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: ####CRYPT PASSWORD####
Thank you for your help.
On Fri, Apr 9, 2010 at 19:51, masarati@aero.polimi.it wrote:
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 modesare 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.
We have created the ITS#6518 ( http://www.openldap.org/its/index.cgi?findid=6518)
We have tested the acl.-bind stanza but we got the same message:
ldap-proxy[19961]: conn=1000 fd=8 ACCEPT from IP=192.168.1.5:41051 (IP= 192.168.1.10:389) ldap-proxy[19961]: conn=1000 op=0 BIND dn="cn=replicator,dc=example,dc=com" method=128 ldap-mirror1[19568]: conn=1006 fd=17 ACCEPT from IP=192.168.1.10:11998 (IP= 192.168.1.20:1389) ldap-mirror1[19568]: conn=1006 op=0 BIND dn="cn=replicator,dc=example,dc=com" method=128 ldap-mirror1[19568]: conn=1006 op=0 BIND dn="cn=replicator,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[19568]: conn=1006 op=0 RESULT tag=97 err=0 text= ldap-mirror1[19568]: conn=1006 op=1 SRCH base="cn=replicator,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[19568]: conn=1006 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[19568]: conn=1007 fd=18 ACCEPT from IP=192.168.1.10:11999 (IP= 192.168.1.20:1389) ldap-mirror1[19568]: conn=1007 op=0 BIND dn="cn=replicator,dc=example,dc=com" method=128 ldap-mirror1[19568]: conn=1007 op=0 BIND dn="cn=replicator,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[19568]: conn=1007 op=0 RESULT tag=97 err=0 text= ldap-proxy[19961]: conn=1000 op=0 BIND dn="cn=replicator,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[19568]: conn=1006 op=2 SRCH base="cn=replicator,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[19568]: conn=1006 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-proxy[19961]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[19961]: conn=1000 op=1 RESULT tag=103 err=123 text=not authorized to assume identity ldap-proxy[19961]: conn=1000 op=1 do_modify: get_ctrls failed
Anyway we have solved the problem with a workaround:
We have deleted the chaining stanza from the replica slapd.conf:
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
And we have added another back-ldap proxy server between clients (proxy-client: 192.168.1.2) and replica, with the following slapd.conf:
database ldap
chase-referrals true rebind-as-user true
suffix "dc=example,dc=com" uri "ldap://192.168.1.5"
By this way, all modifications are launched against this new proxy, that are redictered to the replica. The replica replies with a referral and the new proxy launch the modification to the proxy of the mirror.
ldapmodify -x -H ldap://proxy-client:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=example,dc=com"
The /var/log/messages of the replica and proxy-client shows the following:
proxy-client[14870]: conn=1000 fd=8 ACCEPT from IP=ldap-client:58246 (IP= 192.168.1.2:389) proxy-client[14870]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-replica[14767]: conn=1002 fd=12 ACCEPT from IP=192.168.1.2:35156 (IP= 192.168.1.5:389) ldap-replica[14767]: conn=1002 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-replica[14767]: conn=1002 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-replica[14767]: conn=1002 op=0 RESULT tag=97 err=0 text= proxy-client[14870]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 proxy-client[14870]: conn=1000 op=0 RESULT tag=97 err=0 text= proxy-client[14870]: conn=1000 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" proxy-client[14870]: conn=1000 op=1 MOD attr=userPassword ldap-replica[14767]: conn=1002 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-replica[14767]: conn=1002 op=1 MOD attr=userPassword ldap-replica[14767]: conn=1002 op=1 RESULT tag=103 err=10 text= proxy-client[14870]: conn=1000 op=1 RESULT tag=103 err=0 text= proxy-client[14870]: conn=1000 op=2 UNBIND ldap-replica[14767]: conn=1002 op=2 UNBIND ldap-replica[14767]: conn=1002 fd=12 closed proxy-client[14870]: conn=1000 fd=8 closed
In the mirror and proxy we get the following messages:
ldap-proxy[19961]: conn=1014 fd=11 ACCEPT from IP=192.168.1.5:40330 (IP= 192.168.1.10:389) ldap-proxy[19961]: conn=1014 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[19568]: conn=1006 op=24 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[19568]: conn=1006 op=24 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[19568]: conn=1019 fd=35 ACCEPT from IP=192.168.1.10:26211 (IP= 192.168.1.20:1389) ldap-mirror1[19568]: conn=1019 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[19568]: conn=1019 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[19568]: conn=1019 op=0 RESULT tag=97 err=0 text= ldap-proxy[19961]: conn=1014 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[19568]: conn=1006 op=25 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[19568]: conn=1006 op=25 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-proxy[19961]: conn=1014 op=0 RESULT tag=97 err=0 text= ldap-proxy[19961]: conn=1014 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-proxy[19961]: conn=1014 op=1 MOD attr=userPassword ldap-mirror1[19568]: conn=1006 op=26 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[19568]: conn=1006 op=26 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[19568]: conn=1019 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[19568]: conn=1019 op=1 MOD attr=userPassword ldap-mirror1[19568]: conn=1019 op=1 RESULT tag=103 err=0 text= ldap-proxy[19961]: conn=1014 op=1 RESULT tag=103 err=0 text= ldap-proxy[19961]: conn=1014 op=2 UNBIND ldap-proxy[19961]: conn=1014 fd=11 closed ldap-mirror1[19568]: conn=1019 op=2 UNBIND ldap-mirror1[19568]: conn=1019 fd=35 closed
Thank you for your help.
On Mon, Apr 12, 2010 at 15:10, masarati@aero.polimi.it wrote:
Hi,
Ok, i understand that the problem is authorization, but when i supress 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 http://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" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_forward_updates ppolicy_hash_cleartext overlay memberof
################## # Syncrepl directives # ################## syncrepl rid=001 provider=ldap://mirror1:389 http://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://mirror1:389 http://192.168.1.10:389/
slapd.conf of mirror server #1
# Global section
serverID 1
moduleload memberof
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword,userPKCS12 by self write by dn.base="cn=replicator,dc=example,dc=com" read by * auth
access to attrs=shadowLastChange by self write by * read
# Give the replica DN unlimited read access. This ACL needs to be # merged with other ACL statements, and/or moved within the scope # of a database. The "by * break" portion causes evaluation of # subsequent rules. See slapd.access(5) for details.
access to * by dn.base="cn=replicator,dc=example,dc=com" read by * break
access to * by * read
# Load the accesslog overlay moduleload accesslog.la
#Load the syncprov overlay moduleload syncprov.la
# Accesslog database definitions database bdb
monitoring off
suffix cn=accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################### # BDB database definitions #######################################################################
database bdb
monitoring off
suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_hash_cleartext overlay memberof
# Habilitar authz-policiy authz-policy to
index entryCSN eq index entryUUID eq
# syncrepl Provider for primary db overlay syncprov syncprov-checkpoint 1000 60
# accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ####################################################
# MirrorMode - Syncrepl directive syncrepl rid=001 provider=ldap://mirror2:389 bindmethod=simple binddn="cn=Administrator,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on
In the mirror servers we have set the attribute authzTo for the
replicator
dn:
ldapsearch -x -b 'cn=replicator,dc=example,dc=com' -H ldap://mirror1:389 -D 'cn=Administrator,dc=example,dc=com' -w secret authzTo
# replicator, example.com dn: cn=replicator,dc=example,dc=com authzTo: ldap:///dc=example,dc=com??sub?(objectClass=person)
When we launch the following modification through the replica: ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=example,dc=com"
In the mirror server we get:
ldap-mirror1[2649]: conn=1002 op=2 PROXYAUTHZ dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD attr=userPassword ldap-mirror1[2649]: conn=1002 op=2 RESULT tag=103 err=0 text=
Therefore modifying through the replica server is possible with the chaining configuration.
Second sceneario
The problem appears when we introduce the back-ldap proxy server to set the high availability feature that provides the mirror mode.
IPs:
192.168.1.5 -> delta syncrepl 192.168.1.10 -> Back-ldap proxy
^^^ The proxy takes the IP that was of the master; thus, the replica will refer modifications to the proxy
192.168.1.20 -> Mirror mode server 1 192.168.1.30 -> Mirror mode server 2
back-ldap proxy slapd.conf:
database ldap suffix "dc=example,dc=com" uri "ldap://mirror1:389 ldap://mirror2:389" rootdn "cn=Administrator,dc=example,dc=com"
overlay ppolicy
Launching the modification to the proxy, it works:
ldapmodify -x -H ldap://proxy:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=udg77530,ou=people,dc=example,dc=com"
The /var/log/messages of proxy and mirror shows the following:
ldap-proxy[4051]: conn=1000 fd=8 ACCEPT from IP=192.168.1.5:42921 (IP= 192.168.1.10:389) ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1015 fd=19 ACCEPT from IP=192.168.1.10:18103(IP= 192.168.1.20:1389) ldap-mirror1[3438]: conn=1015 op=0 BIND dn="" method=128 ldap-mirror1[3438]: conn=1015 op=0 RESULT tag=97 err=0 text= ldap-mirror1[3438]: conn=1015 op=1 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 fd=20 ACCEPT from IP=192.168.1.10:18104(IP= 192.168.1.20:1389) ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1016 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1015 op=2 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-proxy[4051]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-proxy[4051]: conn=1000 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1015 op=3 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[3438]: conn=1016 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1016 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=2 UNBIND ldap-mirror1[3438]: conn=1016 op=2 UNBIND ldap-mirror1[3438]: conn=1016 fd=20 closed ldap-proxy[4051]: conn=1000 fd=8 closed
But when the modification is made through the replica server we get the error:
ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=rexample,dc=com" ldap_modify: unknown result code (123)
ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: 12r ldap-proxy[3688]: ldap-proxy[3688]: daemon: read active on 12 ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap-proxy[3688]: connection_get(12) ldap-proxy[3688]: connection_get(12): got connid=1001 ldap-proxy[3688]: connection_read(12): checking for input on id=1001 ldap-proxy[3688]: op tag 0x66, time 1271064513 ldap-proxy[3688]: conn=1001 op=2 do_modify ldap-proxy[3688]: conn=1001 op=2 do_modify: dn (uid=user,ou=people,dc=example,dc=com) ldap-proxy[3688]: => get_ctrls ldap-proxy[3688]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (noncritical) ldap-proxy[3688]: parseProxyAuthz: conn 1001 authzid="dn:uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: slap_sasl_getdn: conn 1001 id=dn:uid=user,ou=people,dc=example,dc=com [len=38] ldap-proxy[3688]: >>> dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: <<< dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: ==>slap_sasl2dn: converting SASL name uid=user,ou=people,dc=example,dc=com to a DN ldap-proxy[3688]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[3688]: parseProxyAuthz: conn=1001 "uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com? ldap-proxy[3688]: <== slap_sasl_authorized: return 48 ldap-proxy[3688]: <= get_ctrls: n=1 rc=123 err="not authorized to assume identity" ldap-proxy[3688]: send_ldap_result: conn=1001 op=2 p=3 ldap-proxy[3688]: send_ldap_result: err=123 matched="" text="not authorized to assume identity" ldap-proxy[3688]: send_ldap_response: msgid=3 tag=103 err=123 ldap-proxy[3688]: conn=1001 op=2 RESULT tag=103 err=123 text=not authorized
The proxy receives the PROXYAUTHZ request, and doesn't know how to map the authorization identity. You need to tell your proxy how to collect the required information, which basically consists in setting an "acl-bind" line like
acl-bind bindmethod="simple" binddn="cn=replicator,dc=example,dc=com" credentials="secret"
Use whatever identity lets you collect security related operational data like authzTo and authzFrom
I note that there are a couple of bugs that would prevent this from working as expected:
- back-ldap's ldap_back_entry_get() function uses whatever controls were
set for the operation. As a consequence, who results in calling backend_attribute(), in this case slap_sasl_check_authz(), needs to clear the controls attached to the original request, otherwise the lookup of operational data required for the authorization would occur with the authorization taking place, which is not what we want.
- authzSyntax validate function does not deal with the ordering prefix
("{X}"), and thus validation of returned data fails, so authorization data (authzTo and authzFrom) can't be collected.
Please file an ITS http://www.openldap.org/its/; in the meanwhile, I'll take care of the issues.
Thanks, p.
to assume identity ldap-proxy[3688]: conn=1001 op=2 do_modify: get_ctrls failed ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
The file pass1_user.ldif has:
dn: uid=user,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: ####CRYPT PASSWORD####
Thank you for your help.
On Fri, Apr 9, 2010 at 19:51, masarati@aero.polimi.it wrote:
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 modesare 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.
openldap-technical@openldap.org
-
masarati＠aero.polimi.it -
Ubay Dorta