openldap proxied authorization

I'm having some trouble doing updates with proxied authorization. I'm using UnboundID's LDAP SDK to connect to OpenLDAP, and sending a ProxiedAuthorizationV2RequestControl for dn: uid=me,dc=People,dc=example,dc=com with the update. I've tested and verified that the target user has permission to perform the operation, but I get

insufficient access rights

when I try to do it via proxy auth.

I've configured olcAuthzPolicy=both in cn=config and authzTo={0}ldap:///dc=people,dc=example,dc=com??subordinate?(objectClass=inetOrgPerson) on the original user. The authzTo seems to be working; when I change it I get

not authorized to assume identity

when I try the update (also for searches).

I've got this ldapwhoami -U portal -Y DIGEST-MD5 -X u:mace -H ldap://yorktown -Z working now without saslauthd. I just needed to store the proxy user (portal)'s password as plain text. But I'm still getting 'insufficient access rights' when I try to update anything.

Proxy user

dn: uid=portal,ou=Special Accounts,dc=example,dc=com
objectClass: inetOrgPerson
cn: portal
sn: portal
uid: portal
userPassword: test
authzTo: {0}ldap:///dc=People,dc=example,dc=com??sub?(objectClass=inetOrgPerson)

Effective user:

dn: employeeNumber=1400,dc=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: sambaSamAccount
objectClass: shadowAccount
uid: mace
...

Here's the log from the update attempt, trying to add employeeNumber=1385 as a member of cn=Data Management. It seems to be looking through the nested groups correctly, but it seems like it ought to do indicate a match once it gets to employeeNumber=1400 in cn=administrators.

op tag 0x66, time 1299022001
conn=31595 op=2 do_modify
conn=31595 op=2 do_modify: dn (cn=Data Management,dc=Roles,dc=example,dc=com)
>>> dnPrettyNormal: <cn=Data Management,dc=Roles,dc=example,dc=com>
<<< dnPrettyNormal: <cn=Data Management,dc=Roles,dc=example,dc=com>, <cn=data management,dc=roles,dc=example,dc=com>
conn=31595 op=2 modifications:
  replace: member
          multiple values
conn=31595 op=2 MOD dn="cn=Data Management,dc=Roles,dc=example,dc=com"
conn=31595 op=2 MOD attr=member
>>> dnPretty: <employeeNumber=1020,dc=People,dc=example,dc=com>
<<< dnPretty: <employeeNumber=1020,dc=People,dc=example,dc=com>
>>> dnPretty: <employeeNumber=1385,dc=People,dc=example,dc=com>
<<< dnPretty: <employeeNumber=1385,dc=People,dc=example,dc=com>
>>> dnNormalize: <employeeNumber=1020,dc=People,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1020,dc=people,dc=example,dc=com>
>>> dnNormalize: <employeeNumber=1385,dc=People,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1385,dc=people,dc=example,dc=com>
dnMatch -1        "employeeNumber=1020,dc=people,dc=example,dc=com"     "employeeNumber=1385,dc=people,dc=example,dc=com"
bdb_dn2entry("cn=data management,dc=roles,dc=example,dc=com")
==> unique_modify <cn=Data Management,dc=Roles,dc=example,dc=com>
bdb_modify: cn=Data Management,dc=Roles,dc=example,dc=com
bdb_dn2entry("cn=data management,dc=roles,dc=example,dc=com")
bdb_modify_internal: 0x00000043: cn=Data Management,dc=Roles,dc=example,dc=com
>>> dnNormalize: <cn=Administrators,ou=LDAP,dc=Applications,dc=example,dc=com>
<<< dnNormalize: <cn=administrators,ou=ldap,dc=applications,dc=example,dc=com>
=> bdb_entry_get: ndn: "cn=administrators,ou=ldap,dc=applications,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("cn=administrators,ou=ldap,dc=applications,dc=example,dc=com")
bdb_entry_get: rc=0
>>> dnNormalize: <cn=system administrators,dc=roles,dc=example,dc=com>
<<< dnNormalize: <cn=system administrators,dc=roles,dc=example,dc=com>
=> bdb_entry_get: ndn: "cn=system administrators,dc=roles,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("cn=system administrators,dc=roles,dc=example,dc=com")
bdb_entry_get: rc=0
>>> dnNormalize: <employeeNumber=1306,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1306,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1306,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1306,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1329,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1329,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1329,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1329,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1401,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1401,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1401,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1401,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1400,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1400,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1400,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1400,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
bdb_modify: modify failed (50)
send_ldap_result: conn=31595 op=2 p=3
send_ldap_result: err=50 matched="" text=""
send_ldap_response: msgid=3 tag=103 err=50
conn=31595 op=2 RESULT tag=103 err=50 text=

I went through that about a year ago, proxy authorization use to drive me crazy. So I may not have the definitive answer, but maybe I can help.

First of all: increase your loglevel on slapd ! It's verbose but it helps. Second: use ldapwhoami to test proxy authorization. The you can specify a target user with the -X option, and your proxy user in -U.

# ldapwhoami -U proxyuser -Y DIGEST-MD5 -X u:targetuser -H ldap://localhost

You should have two parameters enabled in your configuration. The olcAuthzPolicy (that you have) and the olcAuthzRegexp (used to build the SASL authentication string). Here is what I have in my configuration:

olcAuthzRegexp: "^uid=([^,]+).*,cn=[^,]*,cn=auth$"
                "ldap:///dc=example,dc=net??sub?(uid=$1)"
olcAuthzPolicy: to

And, finally, as you stated, your proxyuser should have a authzTo attribute. Here is the definition of one of my proxy user:

dn: cn=proxyuser,dc=example,dc=net
uid: proxyuser
mail: proxyuser@example.net
sn: proxyuser
cn: proxyuser
objectClass: inetOrgPerson
objectClass: top
structuralObjectClass: inetOrgPerson
authzTo: {0}ldap:///dc=example,dc=net??sub?(objectClass=inetOrgPerson)
userPassword:: iodqwhdowihw0123hef92e=

Now that should be enough to make proxy authorization work (once again, test it with ldapwhoami). I have written a chapter on this on my wiki (SASL and proxy authorization), since I needed it to connect from cyrus-imapd and postfix to openldap. For more information, take a look at it: http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:openldap:openldap_debian#sasl