openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: (ITS#7686) Feature request: TLS prot/cipher retrievable with ldap_get_option()
by hyc＠symas.com 09 Sep '13

09 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.227.140.201) > > > Similar to logging at server-side (see ITS#7683) it should be possible for a > LDAP client to retrieve the TLS protocol version and cipher suites actually > negotiated by call to ldap_get_option(3) to be able to make decisions according > to local security policy. > > Added in master, tho I logged it against ITS#7683. -- -- 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#7686) Feature request: TLS prot/cipher retrievable with ldap_get_option()
by michael＠stroeder.com 09 Sep '13

09 Sep '13

Full_Name: Version: OS: URL: Submission from: (NULL) (79.227.140.201) Similar to logging at server-side (see ITS#7683) it should be possible for a LDAP client to retrieve the TLS protocol version and cipher suites actually negotiated by call to ldap_get_option(3) to be able to make decisions according to local security policy.

1 0

Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by hyc＠symas.com 09 Sep '13

09 Sep '13

Ivan Nejgebauer wrote: > On 06.09.2013. 21:56, hyc(a)symas.com wrote: >> ian(a)uns.ac.rs wrote: >>> If a minimal chaining configuration is dynamically added to a consumer server in >>> a provider/consumer pair running delta-syncrepl, it will stop working when the >>> consumer is restarted. The configuration is modelled after the one used in >>> test022 in the OpenLDAP source distribution: >> >> Sorry this report was neglected for so long, and thanks for the excellent test >> case. This is now fixed in git master. > > Tested against git master (721e46fe6695077d63a3df6ea2e397920a72308d) with the original > use case and it works, thanks. However, slapd now segfaults if started with cn=config > obtained by converting an existing chaining configuration from slapd.conf. Steps to > reproduce, using the scripts from the archive attached to the original report: Ah thanks. Previous commit changed too much. Fixed now in master. > $ make clean-all replica-chaining > $ ./start-replica.sh # segfault > > The crash is in chain_ldadd, and occurs because the first back-ldap instance in the > converted configuration lacks an olcDbURI. I have attached a patch which inserts a > dummy URI in the common parameter structure when it's allocated. This URI > (ldap://0.0.0.0) should never match any actual referral, so the instance can only > serve to initialize common parameters (which happens with the first instance anyway, > if I understood the code correctly.) > -- -- 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

Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by ian＠uns.ac.rs 09 Sep '13

09 Sep '13

This is a multi-part message in MIME format. --------------070406020601050207030907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06.09.2013. 21:56, hyc(a)symas.com wrote: > ian(a)uns.ac.rs wrote: >> If a minimal chaining configuration is dynamically added to a consumer server in >> a provider/consumer pair running delta-syncrepl, it will stop working when the >> consumer is restarted. The configuration is modelled after the one used in >> test022 in the OpenLDAP source distribution: > > Sorry this report was neglected for so long, and thanks for the excellent test > case. This is now fixed in git master. Tested against git master (721e46fe6695077d63a3df6ea2e397920a72308d) with the original use case and it works, thanks. However, slapd now segfaults if started with cn=config obtained by converting an existing chaining configuration from slapd.conf. Steps to reproduce, using the scripts from the archive attached to the original report: $ make clean-all replica-chaining $ ./start-replica.sh # segfault The crash is in chain_ldadd, and occurs because the first back-ldap instance in the converted configuration lacks an olcDbURI. I have attached a patch which inserts a dummy URI in the common parameter structure when it's allocated. This URI (ldap://0.0.0.0) should never match any actual referral, so the instance can only serve to initialize common parameters (which happens with the first instance anyway, if I understood the code correctly.) -- Ivan Nejgebauer Glavni sistem inženjer CIT-UNS/ARMUNS Univerzitet u Novom Sadu Trg Dositeja Obradovića 5 21000 Novi Sad +381 21 485 2025 ian(a)uns.ac.rs www.uns.ac.rs --------------070406020601050207030907 Content-Type: text/x-patch; name="0001-Fix-crash-w-converted-chain-config.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Fix-crash-w-converted-chain-config.patch" >From 49dc118a97cc5b7e0723905faf08480facb78912 Mon Sep 17 00:00:00 2001 From: Ivan Nejgebauer <ian(a)uns.ac.rs> Date: Mon, 9 Sep 2013 11:33:02 +0200 Subject: [PATCH] Fix crash w/converted chain config As a result of the fix for ITS#7381 (4d02a43ec9a4be422d83094e8d39b7ef3bc290c5) slapd segfaults if started with dynamic configuration after converting a slapd.conf chaining setup to cn=config. This is because the common back-ldap parameters, emitted as the first olcDatabase entry, lack an olcDbURI attribute. This patch adds a dummy LDAP URI which should never match a real one (ldap://0.0.0.0) to the common parameter structure. --- servers/slapd/back-ldap/chain.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/servers/slapd/back-ldap/chain.c b/servers/slapd/back-ldap/chain.c index a7c53ed..ab71b21 100644 --- a/servers/slapd/back-ldap/chain.c +++ b/servers/slapd/back-ldap/chain.c @@ -2019,6 +2019,7 @@ ldap_chain_db_init_common( BackendInfo *bi = be->bd_info; ldapinfo_t *li; int rc; + char *dummy_uri = "ldap://0.0.0.0"; be->bd_info = lback; be->be_private = NULL; @@ -2029,6 +2030,8 @@ ldap_chain_db_init_common( li = (ldapinfo_t *)be->be_private; li->li_urllist_f = NULL; li->li_urllist_p = NULL; + li->li_uri = ch_strdup( dummy_uri ); + li->li_bvuri = ch_calloc( sizeof( struct berval ), 1 ); be->bd_info = bi; -- 1.8.1.2 --------------070406020601050207030907--

1 0

Re: (ITS#7685) Config directive TLSProtocolMin not converted to attribute olcTLSProtocolMin
by michael＠stroeder.com 08 Sep '13

08 Sep '13

Howard Chu wrote: > michael(a)stroeder.com wrote: >> TLSProtocolMin 3.2 >> >> I'd expect this to appear as attribute 'olcTLSProtocolMin' in cn=config but >> it's >> missing. >> > Fixed in master Seems to work. Thanks. Ciao, Michael.

1 0

Re: (ITS#7678) Operational Error propagated from back-meta
by hyc＠symas.com 07 Sep '13

07 Sep '13

Matt Hamilton wrote: > On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc(a)symas.com> wrote: > >> matth(a)netsight.co.uk wrote: >>> Full_Name: Matt Hamilton >>> Version: 2.4.36 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (213.133.64.253) >>> >>> >>> I am using the meta backend to query multiple LDAP (AD) backends. This is to >>> consolidate several directories in different departments into one. We attempt >>> both simple binds with username/password and also anon binds to look up user >>> information. >> >> That doesn't make much sense, since AD disallows anonymous Binds. > > Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP. Hence why the config has credentials in it to use against the backends if not supplied by the client. > >>> At the moment, trying to do an authenticated simple bind to slapd caused an >>> Operational Error to be propagated to the client regardless of the setting of >>> 'onerr'. Even when a result is successfully found. This is due to one server in >>> the backend succeeding and the other returning an operational error due to an >>> invalid bind (as would be expected as the credentials supplied from the client >>> will only work with one of the backends). >>> >>> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that >>> the code is not checking for 'Operational Error' as a specific case above and so >>> uses the default case (line 1665). Hence sres is set to 'Operational Error' too >>> at line 1934. >> >> back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there. > > I'm not talking about binds there. I'm talking about errors being propagated. You said, exactly: >>> At the moment, trying to do an authenticated simple bind to slapd caused an Operational Error to be propagated to the client regardless of the setting of 'onerr'. <<< So again, are you talking about Bind or are you talking about Search? I'm unable to reproduce any of the behavior you're describing since the config snippets you provided reference servers that are private to your network. Nor do I have any local AD servers to test against. Nor have you given exact details of the client side commands being issued. With so little ungarbled information to go on, we cannot investigate. -- -- 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

Re: (ITS#7669) tool_bind in common.c should be doing conditional assert
by hyc＠symas.com 07 Sep '13

07 Sep '13

k.venkata.kiran(a)ericsson.com wrote: > Full_Name: Venkata Kiran K > Version: 2.4.35 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.71.175.12) > > > tool_bind has below assert which might be hit when nsctrls is not updated > > assert(nsctrls < (int) (sizeof(sctrls) / sizeof(sctrls[0]))); nsctrls is initialized to 0. If it is not updated, the assert condition will of course be true, so the problem you describe cannot arise. Please provide a test case to demonstrate the problem you're seeing, otherwise this ITS will be closed. -- -- 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

Re: (ITS#7683) Feature request: write TLS prot/cipher to syslog
by hyc＠symas.com 07 Sep '13

07 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.219.124.115) > > > For debugging which TLS protocol version and cipher suites were actually > negotiated with several LDAP clients this information would be written to the > syslog message. > > Current logging: > > conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 > > Suggestion: > > conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.1 > tls_cipher=DHE-RSA-AES256-SHA256 > > Added to master. MozNSS version is untested due to absence of PEM support in MozNSS. (See https://bugzilla.mozilla.org/show_bug.cgi?id=402712 - whatever PEM support that may exist is not of usable quality.) -- -- 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

Re: (ITS#7684) Admin Guide: Correct 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by hyc＠symas.com 07 Sep '13

07 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.219.124.115) > > > The admin guide incorrectly mentions the configuration directive name > 'TLSEphemeralDHParamFile' instead of 'TLSDHParamFile' like described in > slapd.conf(5). Thanks, fixed in master. (Also partly fixed in ITS#7506) > > See: http://www.openldap.org/doc/admin24/tls.html > > See this trivial patch: > > diff --git a/doc/guide/admin/aspell.en.pws b/doc/guide/admin/aspell.en.pws > index 3683f98..9921963 100644 > --- a/doc/guide/admin/aspell.en.pws > +++ b/doc/guide/admin/aspell.en.pws > @@ -23,7 +23,7 @@ ddd > DAs > TLSCACertificateFile > BNF > -TLSEphemeralDHParamFile > +TLSDHParamFile > ppolicy > gavin > ASN > diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf > index 00bf83c..9e3243e 100644 > --- a/doc/guide/admin/tls.sdf > +++ b/doc/guide/admin/tls.sdf > @@ -188,7 +188,7 @@ and it doesn't need very much data to work. > > This directive is ignored with GnuTLS and Mozilla NSS. > > -H4: TLSEphemeralDHParamFile <filename> > +H4: TLSDHParamFile <filename> > > This directive specifies the file that contains parameters for > Diffie-Hellman ephemeral key exchange. This is required in order > > > -- -- 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

Re: (ITS#7685) Config directive TLSProtocolMin not converted to attribute olcTLSProtocolMin
by hyc＠symas.com 07 Sep '13

07 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.219.124.115) > > > I have in my static slapd.conf: > > TLSProtocolMin 3.2 > > I'd expect this to appear as attribute 'olcTLSProtocolMin' in cn=config but it's > missing. > > Fixed in master -- -- 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

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