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
[email protected]"
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/[email protected]"
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/[email protected]"
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: [email protected]
dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
krb5PrincipalName: [email protected]
Searches using [email protected] work as expected, but searches
using [email protected] fail. Here is what we see in
the log for a [email protected] 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="[email protected]"
authzid="[email protected]"
Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 BIND
dn="[email protected],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 [email protected], but it
gets mapped into:
[email protected],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: [email protected]
dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
krb5PrincipalName: [email protected]
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="[email protected]"
authzid="[email protected]"
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
