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