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

Re: ACLs & sasl-regexp



--On Friday, August 20, 2004 3:32 PM -0400 "Matthew J. Smith" <matt.smith@uconn.edu> wrote:

All-
  I am running OpenLDAP 2.2.15 on SuSE Linux.  I am having an
interesting problem with SASL/GSSAPI authentication.  Here is my
sasl-regexp:

        sasl-regexp
          uid=(.*),cn=uconn.edu,cn=gssapi,cn=auth
          ldap:///dc=uconn,dc=edu??sub?(krb5PrincipalName=$1@UCONN.EDU)


I have an ACL protecting the krb5PrincipalName field:

        access to attrs=krb5PrincipalName
                by ssf=128 * auth

My goal with the ACL is to force simple binds over SSL, and not allow
plaintext.  (Although, as I re-read this ACL, I question it's usefulness
-- however, I do not want Krb5principalNames readable, and I want simple
({SASL}) binds to occur only over SSL/TLS).

This ACL seems to prevent the sasl-regexp from functioning.  With this
ACL in place, ldapwhoami gives me:

        SASL/GSSAPI authentication started
        SASL username: mas02041@UCONN.EDU
        SASL SSF: 56
        SASL installing layers
        dn:uid=mas02041,cn=uconn.edu,cn=gssapi,cn=auth

If I modify the ACL's by clause to "by * auth", then ldapwhoami returns
correctly, with the following proper info:

        SASL/GSSAPI authentication started
        SASL username: mas02041@UCONN.EDU
        SASL SSF: 56
        SASL installing layers
        dn:uid=mas02041,ou=people,dc=uconn,dc=edu

Noting the SSF tag in the ldapwhoami, I tried adjusting my ACL to
specify ssf=56, with no success.

Here is a snippet from the debug output with -d 128:
        => access_allowed: auth access to
"uid=mas02041,ou=people,dc=uconn,dc=edu" "krb5PrincipalName" requested
        => dn: [1] dc=uconn,dc=edu
        => acl_get: [1] matched
        => dn: [2] dc=uconn,dc=edu
        => acl_get: [2] matched
        => dn: [3] dc=uconn,dc=edu
        => acl_get: [3] matched
        => dn: [4] dc=uconn,dc=edu
        => acl_get: [4] matched
        => dn: [5] dc=uconn,dc=edu
        => acl_get: [5] matched
                => dn: [6] dc=uconn,dc=edu
        => acl_get: [6] matched
        => acl_get: [6] attr krb5PrincipalName
        => acl_mask: access to entry
"uid=mas02041,ou=people,dc=uconn,dc=edu", attr
"krb5PrincipalName"         requested
        => acl_mask: to value by "", (=n)
        <= check a_dn_pat: *
        <= check a_authz.sai_ssf: ACL 128 > OP 0
        <= acl_mask: no more <who> clauses, returning =n (stop)
        => access_allowed: auth access denied by =n

So ... after all that (hopefully useful) information, could someone tell
me if it is possible to use the sasl-regexp I listed above without
granting anonymous auth rights to the krb5principal over an unprotected
channel?  My original assumption (proven wrong) was that the sasl-regexp
would resolve outside of the ACLs. If it needs to go through the ACLs as
well, can I give it a (high-level) DN to perform it's search as? Am I
completely misusing the SSF an "auth" syntax of my ACL, or blowing the
sasl-regexp syntax?


I simply do:

access to attrs=krb5PrincipalName,member,suseasstatus
       by anonymous compare
       by * break

In that case, you don't get to read the attribute only perform compares for validity.

You may want to do:

by * sasl_ssf=56 auth

That will set the SASL security factor. Note that any ACL with the sasl_ssf set will be protected then. I put the sasl_ssf=56 on every ACL, and don't worry about TLS or SSL, since many things are broken in that regard (not openldap, but client software).

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html