Re: ACLs & sasl-regexp

[Jose Gonzalez Gomez <jgonzalez@opentechnet.com>]

   Matt,

   If your purpose is to force simple binds over SSL use this:

       security simple_bind=64

   I found that in my case

access to attrs=krb5PrincipalName
   by anonymous auth

   was needed in order to sasl-regexp work correctly with GSSAPI 
authentication.

   Best regards
   Jose

Matthew J. Smith 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?
>
> Any insight is greatly appreciated,
> -Matt
>
>