July 2010 - openldap-bugs

by manu＠netbsd.org

Daniel Pluta <daniel(a)pluta.biz> wrote: > As I'm not (yet ;-)) an OTP-expert I have not tested any further because > I currently just don't know how to calculate the one-time password based > on the challenge ... skey(1) can do it for you. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

12 years, 8 months

1
0
0 / 0

(ITS#6591) Openldap 2.4.16 with BDB 4.7.25 slapd 200% issue

by dsbrar16＠yahoo.com

Full_Name: Devender Singh Version: 2.4.16 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.180.61.218) Hi All, I need help for openldap slapd 200% cpu utilization issue. I have configured three openldap servers(2 Masters and 1 Slave). I have configure PEN load balancer for failover setup on 2 master openldap servers.It means application server first of all hit the loadbalancer port and than PEN LB will forwad that request to Master 1 or 2 openldap server. Hardware configuration on all boxes: OS: RHEL5(x86_64) RAM: 2GB Number of CPU: 2(Intel(R) Xeon(R)2.00GHz) Number of BDB databases: 2 Databse1: Number of users : 830000 Number of dns: 830000 Database2: Number of users: 2000 Number of dns: 800000 My Application1 using Databse1 and Application2 using Databse2. Application2 just authenticating the users and store last 10 password history only, It means Application1 is not using openldap too much. In Application2(90% dependent on openldap) every user have 1000+ sub leafs entries. when I want to do major changes(number of leafs write) into this, its got hanged and got socket closed error in application logs and CPU utilization goes 200% and RAM 52%. My DB_CONFIG file is below: # $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27 ghenry Exp $ # Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. # # See the Oracle Berkeley DB documentation # <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_...> # for detail description of DB_CONFIG syntax and semantics. # # Hints can also be found in the OpenLDAP Software FAQ # <http://www.openldap.org/faq/index.cgi?file=2> # in particular: # <http://www.openldap.org/faq/index.cgi?file=1075> # Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment. # one 0.25 GB cache set_cachesize 0 268435456 1 # Data Directory #set_data_dir db # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 #set_lg_dir logs # Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option). Please help me here that what I need to do for better performance. Thanks in advance. My contact number is +919650477441

12 years, 8 months

1
0
0 / 0

Re: (ITS#6475) SASL OTP and syncrepl

by daniel＠pluta.biz

Hi, I've received segmentation faults during some basic SASL OTP testing using CVS HEAD. Below you'll find a small patch (against HEAD) which seems to fix this issue ... Before the patch: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) (<== slapd segfault) After the patch has been applied: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started Challenge: otp-md5 498 ti6311 ext Please enter your one-time password: huhu ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: (<== slapd still running ;-) ) As I'm not (yet ;-)) an OTP-expert I have not tested any further because I currently just don't know how to calculate the one-time password based on the challenge ... Best regards, Daniel Index: servers/slapd/sasl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v retrieving revision 1.274 diff -u -r1.274 sasl.c --- servers/slapd/sasl.c 15 Apr 2010 16:13:54 -0000 1.274 +++ servers/slapd/sasl.c 19 Jul 2010 19:55:11 -0000 @@ -548,7 +548,7 @@ op.o_req_ndn.bv_val = (char *)pr[i].values[0]; } #ifdef SLAP_AUXPROP_DONTUSECOPY - { + if ( slap_dontUseCopy_propnames != NULL ) { struct berval bv; ber_str2bv( &pr[i].name[1], 0, 1, &bv ); for ( j = 0; !BER_BVISNULL( &slap_dontUseCopy_propnames[ j ] ); j++ ) {

12 years, 8 months

1
0
0 / 0

(ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config

by daniel＠pluta.biz

Full_Name: Daniel Pluta Version: HEAD OS: Lnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig settings. Steps to reproduce: 1.) cat > slapd.conf <<EOF include /tmp/openldap/etc/openldap/schema/core.schema pidfile /tmp/openldap/var/run/slapd.pid argsfile /tmp/openldap/var/run/slapd.args database hdb dbconfig set_cachesize 0 1048576 0 dbconfig set_lg_bsize 2097152 suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/openldap/var/openldap-data index objectClass eq EOF 2.) convert slapd.conf into cn=config: mkdir slapd.d && slaptest -f slapd.conf -F slapd.d 3.) search slapd.d directory for "olcdbconfig" attribute values: grep -R -i olcDbConfig slapd.d/ the string "olcDbConfig" cannot be found (only in schema definition)...

12 years, 8 months

1
0
0 / 0

ITS#6576

by marco.pizzoli＠gmail.com

--0016e6de0432b2d346048b6a8223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use of grep. My initial request is motivated by a heavy trafficated deployment in which access log files are rotated every 3h and the information about the binddn/ip_src fall often in the rotated file. Worst of this, IBM Unix AIX systems permit LDAP integration using a daemon (secldapclntd) which creates a *permanent* pool of connections againts all ldap servers configured. IBM DB2 v9.5+ permit a native ldap integration and the behaviour is analogous to the AIX one. So, if I need to extract specific information about a binddn/ip I have to follow many files and correlate many informations (conn=3D<number>) For my purposes it would be sufficient an extension to slapo-accesslog permitting me to define a filter on the binddn of the activity. Thanks Marco --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --0016e6de0432b2d346048b6a8223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use = of grep. My initial request is motivated by a heavy trafficated depl= oyment in which access log files are rotated every 3h and the information a= bout the binddn/ip_src fall often in the rotated file. Worst of this, IBM Unix AIX systems permit LDAP integration using a dae= mon (secldapclntd) which creates a *permanent* pool of connections againts = all ldap servers configured. IBM DB2 v9.5+ permit a native ldap integrat= ion and the behaviour is analogous to the AIX one. So, if I need to extract specific information about a binddn/ip I have = to follow many files and correlate many informations (conn=3D<number>= ) For my purposes it would be sufficient an extension to slapo-acces= slog permitting me to define a filter on the binddn of the activity. Thanks =A0=A0=A0 Marco -- _________= ________________________________ Non =E8 forte chi non cade, ma chi cade= ndo ha la forza di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ji= m Morrison <div style=3D"visibility: hidden; display: inline;" id=3D"avg_ls_inline_pop= up"></div><style type=3D"text/css">#avg_ls_inline_popup { position:absolut= e; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; = width: 240px; overflow: hidden; word-wrap: break-word; color: black; fo= nt-size: 10px; text-align: left; line-height: 13px;}</style> --0016e6de0432b2d346048b6a8223--

12 years, 8 months

1
0
0 / 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs

by rmeggins＠redhat.com

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> Rich Megginson wrote: >>>> Howard Chu wrote: >>>>> rmeggins(a)redhat.com wrote: >>>>>> Full_Name: Rich Megginson >>>>>> Version: 2.4.23 >>>>>> OS: Fedora >>>>>> URL: >>>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714... >>>>>> >>>>>> >>>>>> >>>>>> Submission from: (NULL) (76.113.111.209) >>>>>> >>>>>> >>>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>>> case >>>>>> so, see if the cert and issuer are the same cert, and allow the >>>>>> use of it (with a warning) >>>>> >>>>> If you checked to see if the issuer is already trusted, I guess the >>>>> patch is OK. >>>>> >>>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>>> documentation says to use explicit CA certs, separate from the server >>>>> cert. Is it really a good idea to break this validation check? >>>> Probably not, but openssl seems to allow it. This provides parity >>>> with >>>> the openssl implementation. >>>> >>>> This issue came up when testing openldap with NSS support in Fedora. >>>> The Fedora package creates a self signed CA cert using openssl req >>>> -x509. This works with openldap+openssl, but fails with >>>> openldap+moznss. >>> >>> In the OpenSSL case, it only succeeds if the cert is configured as >>> both a CA cert and a server cert. I.e., the client must have been >>> configured to trust the cert already. I believe for your patch, it >>> should fail when CERT_FindCertIssuer() returns NULL. No? >> You are correct. I've uploaded a new patch. > > OK, committed. Thanks for the patch. And thank you for your help. > >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714...<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714...> >> >> >> Here is the diff between the two patches: >> 32,34c32 >> < + /* no issuer - warn and >> allow */ >> < + status = SECSuccess; >> < + rc = 0; >> --- >> > + /* no issuer - fail */ >> 36c34 >> < + "TLS: warning: the >> server certificate %s has no issuer - " >> --- >> > + "TLS: error: the >> server certificate %s has no issuer - " >> >>> >>>>> Also, where does this check occur in the main sequence of >>>>> verification >>>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>>> been checked successfully? >>>> Yes. This check occurs in the cert chain processing, which is done >>>> last. >>> >>> OK. >>> >> >> > >

12 years, 8 months

1
0
0 / 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs

by hyc＠symas.com

Rich Megginson wrote: > Howard Chu wrote: >> Rich Megginson wrote: >>> Howard Chu wrote: >>>> rmeggins(a)redhat.com wrote: >>>>> Full_Name: Rich Megginson >>>>> Version: 2.4.23 >>>>> OS: Fedora >>>>> URL: >>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714... >>>>> >>>>> >>>>> Submission from: (NULL) (76.113.111.209) >>>>> >>>>> >>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>> case >>>>> so, see if the cert and issuer are the same cert, and allow the >>>>> use of it (with a warning) >>>> >>>> If you checked to see if the issuer is already trusted, I guess the >>>> patch is OK. >>>> >>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>> documentation says to use explicit CA certs, separate from the server >>>> cert. Is it really a good idea to break this validation check? >>> Probably not, but openssl seems to allow it. This provides parity with >>> the openssl implementation. >>> >>> This issue came up when testing openldap with NSS support in Fedora. >>> The Fedora package creates a self signed CA cert using openssl req >>> -x509. This works with openldap+openssl, but fails with >>> openldap+moznss. >> >> In the OpenSSL case, it only succeeds if the cert is configured as >> both a CA cert and a server cert. I.e., the client must have been >> configured to trust the cert already. I believe for your patch, it >> should fail when CERT_FindCertIssuer() returns NULL. No? > You are correct. I've uploaded a new patch. OK, committed. Thanks for the patch. > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714...<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714...> > > Here is the diff between the two patches: > 32,34c32 > < + /* no issuer - warn and allow */ > < + status = SECSuccess; > < + rc = 0; > --- > > + /* no issuer - fail */ > 36c34 > < + "TLS: warning: the > server certificate %s has no issuer - " > --- > > + "TLS: error: the > server certificate %s has no issuer - " > >> >>>> Also, where does this check occur in the main sequence of verification >>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>> been checked successfully? >>> Yes. This check occurs in the cert chain processing, which is done >>> last. >> >> OK. >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 8 months

1
0
0 / 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs

by rmeggins＠redhat.com

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> rmeggins(a)redhat.com wrote: >>>> Full_Name: Rich Megginson >>>> Version: 2.4.23 >>>> OS: Fedora >>>> URL: >>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714... >>>> >>>> >>>> Submission from: (NULL) (76.113.111.209) >>>> >>>> >>>> MozNSS doesn't like self-signed CA certs that are also used for >>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>> case >>>> so, see if the cert and issuer are the same cert, and allow the >>>> use of it (with a warning) >>> >>> If you checked to see if the issuer is already trusted, I guess the >>> patch is OK. >>> >>> But that aside, MozNSS's behavior sounds correct to me, and our >>> documentation says to use explicit CA certs, separate from the server >>> cert. Is it really a good idea to break this validation check? >> Probably not, but openssl seems to allow it. This provides parity with >> the openssl implementation. >> >> This issue came up when testing openldap with NSS support in Fedora. >> The Fedora package creates a self signed CA cert using openssl req >> -x509. This works with openldap+openssl, but fails with >> openldap+moznss. > > In the OpenSSL case, it only succeeds if the cert is configured as > both a CA cert and a server cert. I.e., the client must have been > configured to trust the cert already. I believe for your patch, it > should fail when CERT_FindCertIssuer() returns NULL. No? You are correct. I've uploaded a new patch. URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714... <ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714...> Here is the diff between the two patches: 32,34c32 < + /* no issuer - warn and allow */ < + status = SECSuccess; < + rc = 0; --- > + /* no issuer - fail */ 36c34 < + "TLS: warning: the server certificate %s has no issuer - " --- > + "TLS: error: the server certificate %s has no issuer - " > >>> Also, where does this check occur in the main sequence of verification >>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>> been checked successfully? >> Yes. This check occurs in the cert chain processing, which is done >> last. > > OK. >

12 years, 8 months

1
0
0 / 0

ITS#6570 published: SECURITY: Two OpenLDAP preauth vulnerabilities

by openldap-its＠OpenLDAP.org

Private ITS#6570 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6570

12 years, 8 months

1
0
0 / 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs

by hyc＠symas.com

Rich Megginson wrote: > Howard Chu wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 >>> OS: Fedora >>> URL: >>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714... >>> >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> MozNSS doesn't like self-signed CA certs that are also used for >>> TLS/SSL server certs (such as generated by openssl req -x509) >>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>> case >>> so, see if the cert and issuer are the same cert, and allow the >>> use of it (with a warning) >> >> If you checked to see if the issuer is already trusted, I guess the >> patch is OK. >> >> But that aside, MozNSS's behavior sounds correct to me, and our >> documentation says to use explicit CA certs, separate from the server >> cert. Is it really a good idea to break this validation check? > Probably not, but openssl seems to allow it. This provides parity with > the openssl implementation. > > This issue came up when testing openldap with NSS support in Fedora. > The Fedora package creates a self signed CA cert using openssl req > -x509. This works with openldap+openssl, but fails with openldap+moznss. In the OpenSSL case, it only succeeds if the cert is configured as both a CA cert and a server cert. I.e., the client must have been configured to trust the cert already. I believe for your patch, it should fail when CERT_FindCertIssuer() returns NULL. No? >> Also, where does this check occur in the main sequence of verification >> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >> been checked successfully? > Yes. This check occurs in the cert chain processing, which is done last. OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 8 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2010