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