(ITS#7747) smbk5pwd with translucent overlay
by jdescamps＠capensis.fr
Full_Name: descamps jérémy
Version: 2.4.28
OS: Linux Debian/RH
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (77.242.202.229)
This is not an issue report but a enhancement idea for the smbk5pwd overlay.
I'm having a translucent LDAP instance over a simple LDAP instance. This
translucent instance performs the LDAP samba attributes and objectclasses on
each entries.
Thereby, I'm not able to use smbk5pwd overlay in order to change samba
attributes when 'userPassword' attribute changed, cause 'userPassword' and
'sambaNTPassword' aren't on the same LDAP instance.
It will be very useful to send a PasswordModify operation to a remote server in
order to update samba attributes.
Thank you team !
Regards,
10 years
(ITS#7746) adding weird cert crashes slapd
by michael＠stroeder.com
Full_Name:
Version: 2.4.37
OS: Debian Squeeze
URL:
Submission from: (NULL) (212.227.35.93)
Adding the following weird test cert to attribute 'userCertificate' of an
existing entry crashed slapd. I will provide more details later if needed.
-----BEGIN CERTIFICATE-----
MIIBfjCCASSgAwIBAgIBATAKBggqhkjOPQQDAjAAMB4XDTEzMTExNDA4NTgzNloX
DTEzMTIxNDA4NTgzNlowADBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABCaMbYk9
kWfPT3gEKoIlQD6FPT+ea3PeB91l4c6reksafBuzWqG6tjZ9JhGf/AZNQEPhuaBg
KvppUO+AVpZXls6jgY4wgYswCQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwHQYDVR0OBBYEFFh0Ssh8tqESHytVtEPHU1IoTSmbMCgGA1Ud
IwQhMB+AFFh0Ssh8tqESHytVtEPHU1IoTSmboQSkAjAAggEBMBYGA1UdEQQPMA2C
C2V4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCICZVDrN0xlLkOv8odyXQASYy
Vy68ynjW3vZQndia3gQSAiEAvOn2JZEJmlfwPr3EglREs8CnXeqYfREqYfIfVufC
0zM=
-----END CERTIFICATE-----
10 years
Re: (ITS#7745) olcAuthzRegexp lowers cases substitution variables
by whm＠stanford.edu
--On Wednesday, November 13, 2013 11:07:55 PM +0100 Pierangelo Masarati <pierangelo.masarati(a)polimi.it> wrote:
> On 11/13/2013 07:11 PM, whm(a)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=(.*)(a)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(a)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(a)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(a)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(a)WIN.STANFORD.EDU
>>
>> dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
>> krb5PrincipalName: EmailGroupMgr.svc(a)WIN.STANFORD.EDU
>>
>> Searches using adharvservice(a)WIN.STANFORD.EDU work as expected, but searches
>> using EmailGroupMgr.svc(a)WIN.STANFORD.EDU fail. Here is what we see in
>> the log for a EmailGroupMgr.svc(a)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(a)WIN.STANFORD.EDU"
>> authzid="EmailGroupMgr.svc(a)WIN.STANFORD.EDU"
>> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 BIND
>> dn="uid=emailgroupmgr.svc(a)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(a)WIN.STANFORD.EDU, but it
>> gets mapped into:
>>
>> uid=emailgroupmgr.svc(a)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=(.*)(a)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
--
Bill MacAllister
Infrastructure Delivery Group, Stanford University
10 years
Re: (ITS#7745) olcAuthzRegexp lowers cases substitution variables
by pierangelo.masarati＠polimi.it
On 11/13/2013 07:11 PM, whm(a)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=(.*)(a)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(a)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(a)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(a)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(a)WIN.STANFORD.EDU
>
> dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
> krb5PrincipalName: EmailGroupMgr.svc(a)WIN.STANFORD.EDU
>
> Searches using adharvservice(a)WIN.STANFORD.EDU work as expected, but searches
> using EmailGroupMgr.svc(a)WIN.STANFORD.EDU fail. Here is what we see in
> the log for a EmailGroupMgr.svc(a)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(a)WIN.STANFORD.EDU"
> authzid="EmailGroupMgr.svc(a)WIN.STANFORD.EDU"
> Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 BIND
> dn="uid=emailgroupmgr.svc(a)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(a)WIN.STANFORD.EDU, but it
> gets mapped into:
>
> uid=emailgroupmgr.svc(a)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=(.*)(a)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(a)WIN.STANFORD.EDU
>
> dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
> krb5PrincipalName: emailgroupmgr.svc(a)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(a)WIN.STANFORD.EDU"
> authzid="EmailGroupMgr.svc(a)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
>
>
>
>
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
10 years
(ITS#7745) olcAuthzRegexp lowers cases substitution variables
by 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=(.*)(a)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(a)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(a)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(a)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(a)WIN.STANFORD.EDU
dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
krb5PrincipalName: EmailGroupMgr.svc(a)WIN.STANFORD.EDU
Searches using adharvservice(a)WIN.STANFORD.EDU work as expected, but searches
using EmailGroupMgr.svc(a)WIN.STANFORD.EDU fail. Here is what we see in
the log for a EmailGroupMgr.svc(a)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(a)WIN.STANFORD.EDU"
authzid="EmailGroupMgr.svc(a)WIN.STANFORD.EDU"
Nov 12 14:36:04 directory1 slapd[8804]: conn=2649928 op=3 BIND
dn="uid=emailgroupmgr.svc(a)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(a)WIN.STANFORD.EDU, but it
gets mapped into:
uid=emailgroupmgr.svc(a)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(a)WIN.STANFORD.EDU
dn: cn=EmailGroupMgr.svc,cn=service-win,cn=applications,dc=stanford,dc=edu
krb5PrincipalName: emailgroupmgr.svc(a)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(a)WIN.STANFORD.EDU"
authzid="EmailGroupMgr.svc(a)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
10 years
Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by jsynacek＠redhat.com
On 11/04/2013 03:11 PM, hyc(a)symas.com wrote:
> jsynacek(a)redhat.com wrote:
>> On 10/15/2013 01:10 PM, michael.vishchers(a)7p-group.com wrote:
>>> It is not the client loop that is multithreading but the ldap server.
>>>
>>> And it is not a misuse of the API but a problem that may be raised by day t=
>>> o day network problems.
>>>
>>> I've boiled down the problem to a few simple configurations that work (or b=
>>> etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup =
>>> with start script and testclient is attached. It should be sufficient to re=
>>> produce the fault.
>>>
>>> The problem occurs only if we use session variable substitution in the rwm =
>>> overlay, and only if a search is *immediately* (e.g. caused by network loss=
>>> and client timeout) followed by an unbind.
>>>
>>
>> I modified the reproducer a bit (the start script) and find out a few things.
>> You can find the reproducer I'm using at [1].
>>
>> Valgrind's helgrind shows some lock problems in the rwm overlay and also in
>> back-ldap and connection.c. After correcting those the issue seems to be gone.
>>
>> You can find helgrind logs at [2] (before the fix) and [3] (after).
>>
>> Also, ElectricFence reveals some problems [4], which I didn't fix yet.
>>
>> A fix attempt can be found at [5]. I'm not sure if that is a correct fix, or it
>> just masked the real issue. But I didn't to manage to reproduce the problem
>> after applying it.
>
> I already explained the problem. The other issues you identified are not
> relevant, and your patch is not correct. Reread Followup #4 of this ITS.
>
Another take on the fix:
http://jsynacek.fedorapeople.org/openldap/its7723/0001-ITS-7723-fix-refer...
--
Jan Synacek
Software Engineer, Red Hat
10 years
Re: (ITS#7743) bdb_idl_intersection() seems to expand the search candidates unnecessarily
by nishino-yoshinori＠mxc.nes.nec.co.jp
Dear Howard,
Thank you for your prompt reply.
>This is certainly no bug in idl_intersection(), it is an
>optimizatio that makes subsequent intersection operations faster.
>As such, your suggested fix is wrong.
I understood the line 1094-1099 part of idl.c was implemented
to optimize subsequent intersection oprations.
On the other hands, in this case, bdb_idl_intersection(C,D)
(as I described before) returns the range-type candidate set
despite its having only two elements.
Then, by subsequent bdb_idl_union() with A (list-type: the number of
elements=296, minID=296,maxID=858689), the candidate set becomes
very huge.
#bdb_idl_union() seems to change the candidate set into "range-type"
#if one of the two sets is a "range-type".
The impact of removing the optimization of bdb_idl_intersection() is
only that subsequent bdb_idl_intersection() oprations become slower
in certain cases?
If the aforementioned optimization becomes effective when the number of
the element is more than certain threshold number(ex.1024),
I would like to change bdb_idl_intersection() like that:
ex)
1091 if ( BDB_IDL_IS_RANGE( b )
1092 && BDB_IDL_RANGE_FIRST( b ) <=
BDB_IDL_RANGE_FIRST( a )
1093 && BDB_IDL_RANGE_LAST( b ) >=
BDB_IDL_RANGE_LAST( a ) ) {
1094 if (idmax - idmin + 1 == a[0] && a[0] > 1024)
1095 {
1096 a[0] = NOID;
1097 a[1] = idmin;
1098 a[2] = idmax;
1099 }
1100 goto done;
1101 }
The issue occurs in the environment of our user and makes some trouble
because of the slow response of the ldapsearch.
So, I would like to find some fix of the issue.
>If you want to suggest a fix, you should look at idl_union() instead.
Thank you for your advice.
I'll also try to check bdb_idl_union().
If you have other good idea to fix the issue, could you let me know?
Best Regards,
--
*********************************************
Yoshinori Nishino
NEC Soft, Ltd.
E-MAIL: nishino-yoshinori(a)mxc.nes.nec.co.jp
*********************************************
10 years
Re: (ITS#7743) bdb_idl_intersection() seems to expand the search candidates unnecessarily
by nishino-yoshinori＠mxc.nes.nec.co.jp
Dear Quanah,
Thank you for your prompt reply.
> back-bdb is deprecated, I suggest you use back-mdb instead.
Would you tell me why you recommend using back-mdb?
It's because the collision of the hash key in the bdb index
occurs more easily than in the mdb index?
Best Regards,
--
*********************************************
Yoshinori Nishino
NEC Soft, Ltd.
E-MAIL: nishino-yoshinori(a)mxc.nes.nec.co.jp
*********************************************
10 years
Re: (ITS#7743) bdb_idl_intersection() seems to expand the search candidates unnecessarily
by hyc＠symas.com
nishino-yoshinori(a)mxc.nes.nec.co.jp wrote:
> Full_Name: Yoshinori Nishino
> Version: 2.4.37
> OS: RedHatEL 5.5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (210.143.35.12)
>
>
> Dear sir,
>
> OS:Red Hat Enterprise Linux 5.5(x86) (2.6.18-194.el5)
> Version: 2.4.37 + BDB 4.4.20
>
> In our environment, the issue occurs that the ldapsearch command using the
> following filter always took about 15`30 seconds.
> The response of the ldapsearch command becomes faster by modifying idl.c like
> that:
>
> 1087 /* If a range completely covers the list, the result is
>
> 1088 * just the list. If idmin to idmax is contiguous, just
>
> 1089 * turn it into a range.
>
> 1090 */
> 1091 if ( BDB_IDL_IS_RANGE( b )
>
> 1092 && BDB_IDL_RANGE_FIRST( b ) <= BDB_IDL_RANGE_FIRST( a )
>
> 1093 && BDB_IDL_RANGE_LAST( b ) >= BDB_IDL_RANGE_LAST( a ) )
> {
> 1094 /* if (idmax - idmin + 1 == a[0])
>
> 1095 {
>
> 1096 a[0] = NOID;
>
> 1097 a[1] = idmin;
>
> 1098 a[2] = idmax;
>
> 1099 } */
>
> 1100 goto done;
>
> 1101 }
>
> By the aforementioned modification, the search candidate set becomes (list-type:
> the number of elements=298, minID=296,maxID=858689).
>
> I think the line 1094-1099 part of idl.c seems to be a bug.
> The part seems to be implemented in order to just make "ids[]" smaller.
> If the reason is so, would you please consider fixing idl.c?
This is certainly no bug in idl_intersection(), it is an optimization that
makes subsequent intersection operations faster. As such, your suggested fix
is wrong.
If you want to suggest a fix, you should look at idl_union() instead.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years
