--On Wednesday, November 13, 2013 11:07:55 PM +0100 Pierangelo Masarati <[email protected]> wrote:
> On 11/13/2013 07:11 PM, [email protected] 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 >> [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 > > 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:[email protected])" > > or something like that. Much more elegant work around than I had in mind. Thanks. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University
