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, <[email protected]> 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: > > 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, <[email protected]> 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 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. > >> > >> > > > > >
