[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: (ITS#7745) olcAuthzRegexp lowers cases substitution variables

To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#7745) olcAuthzRegexp lowers cases substitution variables
From: pierangelo.masarati@polimi.it
Date: Wed, 13 Nov 2013 22:08:45 GMT
Auto-submitted: auto-generated (OpenLDAP-ITS)
On 11/13/2013 07:11 PM, whm@stanford.edu wrote:
> Full_Name: Bill MacAllister
> Version: 2.4.35
> OS: Debian 7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (67.180.239.194)
>
>
> We have noticed a problem with authentication for some Kerberos
> principals.  The olcAuthzRegexp processing seems to be lower casing
> the input when forming substition variables.  Since Kerberos
> principals are case sensitive this causes authentications to fail.
>
> We have the following olcAuthzRegexp entries in our directory.
>
> % ldapsearch -b cn=config -LLL -Q "olcAuthzRegexp=*" olcAuthzRegexp
> dn: cn=config
> olcAuthzRegexp: {0}"uid=(.*)@win.stanford.edu,cn=stanford.edu,cn=gssapi,cn=aut
>   h" "ldap:///cn=service-win,cn=Applications,dc=stanford,dc=edu??sub?krb5Princi
>   palName=$1@WIN.STANFORD.EDU"
> olcAuthzRegexp: {1}"uid=(.*)/cgi,cn=stanford.edu,cn=gssapi,cn=auth" "ldap:///c
>   n=cgi,cn=applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1/cgi@stanfo
>   rd.edu"
> olcAuthzRegexp: {2}"uid=host/(.*),cn=stanford.edu,cn=gssapi,cn=auth" "ldap:///
>   cn=Host,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=host/$1@sta
>   nford.edu"
> olcAuthzRegexp: {3}"uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth" "ldap:
>   ///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=servi
>   ce/$1@stanford.edu"
> olcAuthzRegexp: {4}"uid=smtp/(.*),cn=stanford.edu,cn=gssapi,cn=auth" "ldap:///
>   cn=smtp,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=smtp/$1@sta
>   nford.edu"
> olcAuthzRegexp: {5}"uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth" "ldap:
>   ///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webau
>   th/$1@stanford.edu"
> olcAuthzRegexp: {6}"uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth" "ldap:///uid=$
>   1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active"
>
> We have the following entries in the directory holding Kerberos
> principals.
>
> % ldapsearch -Q -LLL -b cn=service-win,cn=Applications,dc=stanford,dc=edu
> "krb5PrincipalName=*" krb5PrincipalName
> dn: cn=adharvservice,cn=service-win,cn=applications,dc=stanford,dc=edu
> krb5PrincipalName: adharvservice@WIN.STANFORD.EDU
>
> dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
> krb5PrincipalName: EmailGroupMgr.svc@WIN.STANFORD.EDU
>
> Searches using adharvservice@WIN.STANFORD.EDU work as expected, but searches
> using EmailGroupMgr.svc@WIN.STANFORD.EDU fail.  Here is what we see in
> the log for a EmailGroupMgr.svc@WIN.STANFORD.EDU search:
>
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 fd=572 ACCEPT from
> IP=171.64.18.139:3902 (IP=0.0.0.0:389)
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=0 SRCH base="" scope=0
> deref=0 filter="(objectClass=*)"
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=0 SRCH
> attr=subschemaSubentry dsServiceName namingContexts defaultNamingContext
> schemaNamingContext configurationNamingContext rootDomainNamingContext
> supportedControl supportedLDAPVersion supportedLDAPPolicies
> supportedSASLMechanisms dnsHostName ldapServiceName serverName
> supportedCapabilities
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=0 SEARCH RESULT tag=101
> err=0 nentries=1 text=
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=1 BIND dn="" method=163
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=1 RESULT tag=97 err=14
> text=SASL(0): successful result: mech EXTERNAL is too weak
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=2 BIND dn="" method=163
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=2 RESULT tag=97 err=14
> text=SASL(0): successful result: mech EXTERNAL is too weak
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 BIND dn="" method=163
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 BIND
> authcid="EmailGroupMgr.svc@WIN.STANFORD.EDU"
> authzid="EmailGroupMgr.svc@WIN.STANFORD.EDU"
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 BIND
> dn="uid=emailgroupmgr.svc@win.stanford.edu,cn=stanford.edu,cn=gssapi,cn=auth"
> mech=GSSAPI sasl_ssf=56 ssf=56
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 RESULT tag=97 err=0
> text=
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=4 SRCH
> base="cn=accounts,dc=stanford,dc=edu" scope=2 deref=0 filter="(uid=whm)"
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=4 SRCH attr=uid
> suSeasLocal
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=4 SEARCH RESULT tag=101
> err=0 nentries=0 text=
> Nov 12 14:37:43 directory1 slapd[8804]: conn=2649928 op=5 UNBIND
> Nov 12 14:37:43 directory1 slapd[8804]: conn=2649928 fd=572 closed
>
> Note that the authcid is EmailGroupMgr.svc@WIN.STANFORD.EDU, but it
> gets mapped into:
>
>     uid=emailgroupmgr.svc@win.stanford.edu,cn=stanford.edu,cn=stanford.edu,cn=gssapi,cn=auth

This is because the construction of such DN makes use of "uid", whose 
matching rule is case insensitive.

As a workaround (assuming this is acceptable for you), you could 
probably modify your olcAuthzRegexp rules to force case-insensitive 
lookup of krb5PrincipalName, something like

olcAuthzRegexp: 
{0}"uid=(.*)@win.stanford.edu,cn=stanford.edu,cn=gssapi,cn=auth" 
"ldap:///cn=service-win,cn=Applications,dc=stanford,dc=edu??sub?(krb5PrincipalName:caseIgnoreIA5Match:=$1@WIN.STANFORD.EDU)"

or something like that.

p.

>
> I guessed that the substitution in the olcAuthzRegex is the problem
> and that the principal is being converted to lower case.
>
> Our attribute definition for krb5PrincipalName is:
>
> olcAttributeTypes: {0}( 1.3.6.1.4.1.5322.10.1.1
>    NAME 'krb5PrincipalName'
>    DESC 'The unparsed Kerberos principal name'
>    EQUALITY caseExactIA5Match
>    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>    SINGLE-VALUE )
>
> But, if I change the krb5PrincipalName in the directory to be all
> lower case as follows:
>
> % ldapsearch -Q -LLL -b cn=service-win,cn=Applications,dc=stanford,dc=edu
> krb5PrincipalName=* krb5PrincipalName
> dn: cn=adharvservice,cn=service-win,cn=applications,dc=stanford,dc=edu
> krb5PrincipalName: adharvservice@WIN.STANFORD.EDU
>
> dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
> krb5PrincipalName: emailgroupmgr.svc@WIN.STANFORD.EDU
>
> Then the authentication succeeds:
>
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 fd=46 ACCEPT from
> IP=171.64.18.139:5897 (IP=0.0.0.0:389)
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=0 SRCH base="" scope=0
> deref=0 filter="(objectClass=*)"
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=0 SRCH
> attr=subschemaSubentry dsServiceName namingContexts defaultNamingContext
> schemaNamingContext configurationNamingContext rootDomainNamingContext
> supportedControl supportedLDAPVersion supportedLDAPPolicies
> supportedSASLMechanisms dnsHostName ldapServiceName serverName
> supportedCapabilities
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=0 SEARCH RESULT tag=101
> err=0 nentries=1 text=
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=1 BIND dn=""
> method=163
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=1 RESULT tag=97 err=14
> text=SASL(0): successful result: mech EXTERNAL is too weak
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=2 BIND dn=""
> method=163
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=2 RESULT tag=97 err=14
> text=SASL(0): successful result: mech EXTERNAL is too weak
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=3 BIND dn=""
> method=163
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=3 BIND
> authcid="EmailGroupMgr.svc@WIN.STANFORD.EDU"
> authzid="EmailGroupMgr.svc@WIN.STANFORD.EDU"
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=3 BIND
> dn="cn=emailgroupmgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu"
> mech=GSSAPI sasl_ssf=56 ssf=56
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=3 RESULT tag=97 err=0
> text=
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=4 SRCH
> base="cn=accounts,dc=stanford,dc=edu" scope=2 deref=0 filter="(uid=whm)"
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=4 SRCH attr=uid
> suSeasLocal
> Nov 13 08:13:38 directory2 slapd[31590]: conn=3197185 op=4 SEARCH RESULT tag=101
> err=0 nentries=1 text=
> Nov 13 08:15:16 directory2 slapd[31590]: conn=3197185 op=5 UNBIND
> Nov 13 08:15:16 directory2 slapd[31590]: conn=3197185 fd=46 closed
>
>
>
>


-- 
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
Prev by Date: (ITS#7745) olcAuthzRegexp lowers cases substitution variables
Next by Date: Re: (ITS#7745) olcAuthzRegexp lowers cases substitution variables
Index(es):
- Chronological
- Thread