[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Slapd-ldap proxy between replica and mirror



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:

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 modes
>>    are anonymous and self, which respectively mean that  the  empty
>>    or  the  client&#8217;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.
>>
>>
>