[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Proxy authorization not working with ldapdb as auxprop_plugin
Hi List-
I've narrowed this down to a specific issue of proxy authorization
seemingly not working as described in the Admin Guide 10.3 and the
README with ldapdb.c from Howard.
First, my settings (in order of reference from Howard's README):
"Once installed, you need to add some config items to the SASL server's
config file" (The SASL server in this case is Cyrus IMAPd):
/etc/imapd.conf
---------------
sasl_auxprop_plugin: ldapdb
sasl_ldapdb_uri: ldap://tombstone.gnosys.us
sasl_ldapdb_id: saslproxy
sasl_ldapdb_pw: secret_stored_in_userPassword_attribute
sasl_ldapdb_mech: DIGEST-MD5
sasl_ldap_search_base: o=%d # though not listed, seem
sasl_ldap_filter: uid=%U # to be necessary.
=================
(I found that putting these (without the "sasl_" of course) in either
Cyrus.conf or cyrus.conf in /usr/lib/sasl2 with mode 644 had no effect:
no calls to slapd at all were made)
"The LDAP server must be configured to map the SASL authcId "root" into
a DN that has proxy authorization privileges to every account that is
allowed to login to this server." (I used "saslproxy" in place of "root"
here). This is done with the first sasl-regexp. The second is used to
search the directory for a uid (as in Admin Guide 10.2.5)
slapd.conf
----------------
sasl-regexp uid=saslproxy,cn=digest-md5,cn=auth
uid=saslproxy,ou=agents,o=gnosysllc.com
sasl-regexp uid=(.*)@(.*),cn=digest-md5,cn=auth
ldap:///ou=people,o=$2??sub?(uid=$1)
=================
saslAuthz proxy settings in directory entry:
--------------------
dn: uid=saslproxy,ou=agents,o=gnosysllc.com
saslAuthzTo: uid=ma,ou=people,o=gnosysllc.com
saslAuthzTo: uid=kf,ou=people,o=gnosysllc.com
saslAuthzTo: ldap:///ou=people,o=gnosysllc.com??sub?(objectclass=Person)
======================
(First I tried with the top two saslAuthzTo attribute values. When that
didn't work, I replaced the top two with the bottom more general one.
That also didn't work.)
"If you don't like the "auxpropfunc: error -7" message that is sent to
syslog by slapd, you can stop it by creating /usr/lib/sasl2/slapd.conf
with:
auxprop_plugin: slapd"
/usr/lib/sasl2/slapd.conf
----------------
auxprop_plugin: slapd
==================
>From the logs, it seems that proxy authorization is not working like I
think it should (redacted and picked from from the logs) and resulting
from execution of:
imtest -a ma@gnosysllc.com -p 143 tombstone
------------------------------------------------------
Oct 23 01:26:28 tombstone slapd[31780]: ==>slap_sasl_authorized: can
uid=saslproxy,ou=agents,o=gnosysllc.com become
uid=ma,ou=people,o=gnosysllc.com?
Oct 23 01:26:28 tombstone slapd[31780]: ==>slap_sasl_authorized: can
uid=saslproxy,ou=agents,o=gnosysllc.com become
uid=ma,ou=people,o=gnosysllc.com?
Oct 23 01:26:28 tombstone slapd[31780]: <== slap_sasl_authorized: return
48
Oct 23 01:26:28 tombstone slapd[31780]: <== slap_sasl_authorized: return
48
Oct 23 01:26:28 tombstone slapd[31780]: <= get_ctrls: n=1 rc=47 err="not
authorized to assume identity"
Oct 23 01:26:28 tombstone slapd[31780]: <= get_ctrls: n=1 rc=47 err="not
authorized to assume identity"
Oct 23 01:26:28 tombstone slapd[31780]: send_ldap_result: conn=12 op=2
p=3
Oct 23 01:26:28 tombstone slapd[31780]: send_ldap_result: conn=12 op=2
p=3
Oct 23 01:26:28 tombstone slapd[31780]: send_ldap_result: err=47
matched="" text="not authorized to assume identity"
Oct 23 01:26:28 tombstone slapd[31780]: send_ldap_result: err=47
matched="" text="not authorized to assume identity"
==================================================
But why? Quoting from the Admin Guide 10.3, I see:
===============
Once slapd has the authorization DN, the actual approval process begins.
There are two attributes that the LDAP administrator can put into LDAP
entries to allow authorization:
saslAuthzTo
saslAuthzFrom
Both can be multivalued. The saslAuthzTo attribute is a source rule, and
it is placed into the entry associated with the authentication DN to
tell what authorization DNs the authenticated DN is allowed to assume.
The second attribute is a destination rule, and it is placed into the
entry associated with the requested authorization DN to tell which
authenticated DNs may assume it.
The choice of which authorization policy attribute to use is up to the
administrator. Source rules are checked first in the person's
authentication DN entry, and if none of the saslAuthzTo rules specify
the authorization is permitted, the saslAuthzFrom rules in the
authorization DN entry are then checked. If neither case specifies that
the request be honored, the request is denied. Since the default
behaviour is to deny authorization requests, rules only specify that a
request be allowed; there are no negative rules telling what
authorizations to deny.
The value(s) in the two attributes are of the same form as the output of
the replacement pattern of a sasl-regexp directive: either a DN or an
LDAP URL. For example, if a saslAuthzTo value is a DN, that DN is one
the authenticated user can authorize to. On the other hand, if the
saslAuthzTo value is an LDAP URL, the URL is used as an internal search
of the LDAP database, and the authenticated user can become ANY DN
returned by the search. If an LDAP entry looked like:
dn: cn=WebUpdate,dc=example,dc=com
saslAuthzTo: ldap:///dc=example,dc=com??sub?(objectclass=Person)
then any user who authenticated as cn=WebUpdate,dc=example,dc=com could
authorize to any other LDAP entry under the search base
dc=example,dc=com which has an objectClass of Person.
===============
What am I missing here? Seems like I've got everything right, but I
obviously don't because it's apparently not working as advertised.
Thanks for any suggestions.
--
Kevin
http://www.gnosys.us