Re: (ITS#7745) olcAuthzRegexp lowers cases substitution variables

[whm@stanford.edu]

--On Wednesday, November 13, 2013 11:07:55 PM +0100 Pierangelo Masarati <pierangelo.masarati@polimi.it> wrote:

> 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.

Much more elegant work around than I had in mind.  Thanks.

Bill

-- 

Bill MacAllister
Infrastructure Delivery Group, Stanford University