openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.50.194) If one trys to set the userPassword with a Password Modify ext. op. request but the object classes of the entry does not allow userPassword slapd could add automagically AUXILIARY object class simpleSecurityObject to the entry. (I'm doing this in web2ldap since years when changing the userPassword with a normal modify operation which client-side hashing.)

1 0

(ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.50.194) I'd like to request that a Password Modify ext. op. request should succeed on a LDAP connection as anonymous if the LDAP client provides the correct old password. E.g. OpenDS implements it like this and it makes sense to me regarding a user setting a new password in case of an expired password.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 11 Aug '09

11 Aug '09

On 08/11/2009 04:44 AM, Howard Chu wrote: > Ed(a)vanGasteren.net wrote: >> Full_Name: Ed van Gasteren >> Version: 2.4.12 and 2.4.15 >> OS: linux (Fedora 10, 11) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (85.223.76.221) >> >> >> On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server >> and clients. >> The configuration is such that things work as expected even with security >> tightened up to "TLSVerifyClient demand". ldapsearch (either to -H >> ldaps or with >> -ZZ), nss and gq with TLS work like a charm. >> >> On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), >> gq and >> Thunderbird connecting to the server on lt2. TLS/SSL only works if I >> run slapd >> with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS >> trace: >> SSL_connect:SSLv3 read server certificate A". >> >> Seems as if the normal code path has a flaw which gets >> corrected/bypassed by the >> debugging code. > > Doesn't sound familiar, I've never had this problem. However, the TLS > code was refactored in rev 2.4.14, and it's always possible we missed > something in the churn. How does openssl s_client react under the same > conditions? If it hangs the same way, then that points to a bug on the Should have mentioned that. It indeed hangs the same way, in the middle of getting over the "Acceptable client certificate CA names". The last debug info from s_client suggests it is getting less of the list then in expects: read from 0x8c13300 [0x8c19915] (16384 bytes => 10395 The last one coming across correctly is: /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network The one not coming is: /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com > server, and the answer is just to upgrade since .12 is rather out of Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 repo's running on lt2 first. > date now. If s_client works, then we probably have to look at our client > code. >

1 0

(ITS#6248) Support multiple CA Cert directories
by quanah＠zimbra.com 11 Aug '09

11 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.x OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Both openssl and gnutls support loading CA certs from multiple directories. It would be handy to be able to do this for slapd and the ldap clients. For example, zimbra puts its CA certs in /opt/zimbra/conf/ca, but the system it is installed upon is going to have a different default destination for where its ldap clients look for CA certs. By having support for the multiple paths, the configuration can be adjusted to look in both the system location, and any number of specialized ones.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by hyc＠symas.com 11 Aug '09

11 Aug '09

Ed(a)vanGasteren.net wrote: > Full_Name: Ed van Gasteren > Version: 2.4.12 and 2.4.15 > OS: linux (Fedora 10, 11) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.223.76.221) > > > On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. > The configuration is such that things work as expected even with security > tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with > -ZZ), nss and gq with TLS work like a charm. > > On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and > Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd > with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: > SSL_connect:SSLv3 read server certificate A". > > Seems as if the normal code path has a flaw which gets corrected/bypassed by the > debugging code. Doesn't sound familiar, I've never had this problem. However, the TLS code was refactored in rev 2.4.14, and it's always possible we missed something in the churn. How does openssl s_client react under the same conditions? If it hangs the same way, then that points to a bug on the server, and the answer is just to upgrade since .12 is rather out of date now. If s_client works, then we probably have to look at our client code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6247) slapd-modules/now: New matching rules that enable comparisone slapd's current server time against timestamp attributes
by daniel＠pluta.biz 10 Aug '09

10 Aug '09

Full_Name: Daniel Pluta Version: CVS OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090810.tgz Submission from: (NULL) (91.12.197.171) Please see the README for details. Currently only a DUMMY_OID is assigned to the matching rules and the limited internal attribute and objectclass definitions. I would appreciate your feedback. Thanks!

1 0

(ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 10 Aug '09

10 Aug '09

Full_Name: Ed van Gasteren Version: 2.4.12 and 2.4.15 OS: linux (Fedora 10, 11) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.223.76.221) On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. The configuration is such that things work as expected even with security tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with -ZZ), nss and gq with TLS work like a charm. On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: SSL_connect:SSLv3 read server certificate A". Seems as if the normal code path has a flaw which gets corrected/bypassed by the debugging code. What puzzels me is that I find few references (google) to these kind of problems as if nobody uses it this way. - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412706 There they blame it on GnuTLS. Here the symptoms are similar but GnuTLS is not in the picture. - I have searched the openldap Mailing Lists archives for "ssl;client;server;-d 2". That gives a few hits with very similar problems but the threads provide no solution. I can provide loads of additional detail about my configuration and debug output of the server and the ldapsearch client but I prefer to get some pointers about what to test, look for or provide.

1 0

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristo-jose.camarero＠ericsson.com 10 Aug '09

10 Aug '09

=20 It looks that I sent an email that was unreadable. Sorry for that. I recap the content: The traffic model we are testing contains search and modify operations. = The search response contains usually a single entry about 3KB in LDIF = format. There is only a reduce number of LDAP clients (usually one or = two), that are using async LDAP API and sending a lot of operations per = second (> 1000 TPS per client). The client side is an OS Delta box. Under these conditions we have tested that increasing the sending buffer = of the server has improved the performance. That's the reason I am = proposing this feature request. Pierangelo's proposal allowing hard-set the buffer sizes looks ok. Regards, Evaristo ----- Mensaje reenviado ---- De: Pierangelo Masarati <masarati(a)aero.polimi.it> Para: evaristojosec(a)yahoo.es CC: openldap-its(a)openldap.org Enviado: martes, 4 de agosto, 2009 9:54:19 Asunto: Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST Your message was unreadable, you should use text form for messages sent = to the ITS. In any case, according to many sources, the default values for TCP = buffers can be pretty small. Usually, they can be configured = system-wide at the OS level (see tcp(7)), or even auto-tuned. Personally, I have no objections in optionally allowing to hard-set the = buffer sizes to values one considers appropriate for the intended use of = slapd. Since the optimal size roughly depends on latency and bandwidth, = this may probably need to be configured on a per-listener basis, = actually. However, in deployments where this problem becomes critical, usually = hardware dedicated to slapd is used, so system-wide tuning (and = auto-tuning) would be the preferred option anyway. Manual setting = should be used only when system-wide or auto-tuning is not available or = accessible for some reason. p. =20

1 0

Re: (ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 09 Aug '09

09 Aug '09

--On Saturday, August 08, 2009 10:07 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) I guess they may be liberally legal.. It also updates the contextCSN and the accesslog database. dn: reqStart=20090808223406.000005Z,cn=accesslog objectClass: auditModify reqStart: 20090808223406.000005Z reqEnd: 20090808223409.000000Z reqType: modify reqSession: 214 reqAuthzID: cn=config reqDN: cn=zimbra reqResult: 0 reqMod: entryCSN:= 20090808223406.630393Z#000000#000#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20090808223406Z Seems janky to me. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 09 Aug '09

09 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) [zimbra@freelancer ~]$ ldapmodify -x -H ldapi:/// -D cn=config -W Enter LDAP Password: dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" Log shows it happening, too: Aug 8 15:08:50 freelancer slapd[1937]: conn=16 fd=23 ACCEPT from PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi (PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi) Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" method=128 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 RESULT tag=97 err=0 text= Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 RESULT tag=103 err=0 text= Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 RESULT tag=103 err=0 text= Aug 8 15:09:33 freelancer slapd[1937]: conn=16 fd=23 closed (connection lost)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs