4

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=
Brad Mace
  • 1,024
  • 3
  • 17
  • 32
  • did my answer solve your problem ? – Julien Vehent Feb 27 '11 at 19:09
  • @Julien - I think authzRegexp is what I was missing. Won't be able to test it fully until tomorrow but I wanted to make sure the bounty got awarded. Wasn't sure if I can still award it after it expires. – Brad Mace Feb 27 '11 at 19:23
  • there is nothing concerning the proxy authorization in the log you parsed... Can you parse the logs from ldapwhoami ? ldapwhoami -U portal -Y DIGEST-MD5 -X u:mace -H ldap://yorktown -Z – Julien Vehent Mar 03 '11 at 18:33

2 Answers2

5

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

Julien Vehent
  • 3,017
  • 19
  • 26
  • guess I need to configure sasl as well. I've got things to the point that testsaslauthd works, but ldapwhoami failes with "SASL(-13): user not found: no secret in database". Have any links about setting that up? – Brad Mace Feb 28 '11 at 21:44
  • huum... salsauthd and SASL protocol are two different things. I do not use the daemon saslauthd in my setup, and you don't need it to make proxy authorization work. Can you update your question to paste your configuration and the comands that fail ? – Julien Vehent Mar 01 '11 at 00:24
  • updated question. I've also set olcAuthzRegexp to `{0}"^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=example,dc=com??sub?(uid=$1)"`. Not sure how to post the whole config but I'll post any other parts you want to see. – Brad Mace Mar 01 '11 at 16:55
  • 2
    increase your log level in olcDatabase\=\{0\}config.ldif with the directive "olcLogLevel: stats trace args". The logs are sent to local4 facility of syslog so make sure you have a ligne "local4.* /var/log/slapd.log" in /etc/syslog.conf (or /etc/rsyslog.conf). Restart both daemons and your should see "proxy authorization" logs in slapd.log. Also, which user is the proxy and which is the target ? Can you dump their objects using slapcat ? – Julien Vehent Mar 01 '11 at 21:00
  • Between your authRegexp and logging suggestions, storing the password as plain text I got all the `ldapwhoami` tests working. Now I just have to figure out why it doesn't work in Java. – Brad Mace Mar 03 '11 at 20:55
  • been there, done that, know the frustration :) glad it helped ! – Julien Vehent Mar 04 '11 at 03:22
3

After solving several config problems with Julien's help, I discovered a bug in the UnboundID LDAP SDK v2.0.0 which apparently causes modify requests to be sent without their controls. I got excellent support in their forum, they put up a new build for me within a few hours of my posting logs identifying the problem, and it sounds like it will be fixed in the 2.1.0 release. Now my code is working as intended.

Brad Mace
  • 1,024
  • 3
  • 17
  • 32