(ITS#7745) olcAuthzRegexp lowers cases substitution variables

[whm@stanford.edu]

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

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