openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#8377) Normalized 'olcDbIndex' values
by michael＠stroeder.com 22 Feb '16

22 Feb '16

Full_Name: Version: master OS: URL: Submission from: (NULL) (213.240.182.49) A suggestion for 2.5: Index lines read from slapd.conf should be converted to normalized 'olcDbIndex' values. With this approach it would be possible to determine index configuration for a certain attribute type. Likewise the format of accepted attribute values should be constrained. Example from slapd.conf: index foo,bar eq,sub would be normalized to 4 values: olcDbIndex: foo eq olcDbIndex: foo sub olcDbIndex: bar eq olcDbIndex: bar sub

1 0

(ITS#8376) Use getaddrinfo to resolve FQDN
by hguo＠suse.com 22 Feb '16

22 Feb '16

Full_Name: Howard Guo Version: 2.4.44 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.135.221.2) In a pure IPv6 environment, if LDAP is used as the host resolve, the host may hang when it attempts to resolve its own host name due to usage of gethostbyname*, in the following sequence of events: nss_ldap: locks mutex nss_ldap: calls libldapA-A-> libldap: gethostbyname -> nss_ldap: lock mutex and hang See patch file "howard-guo-160222.patch".

1 0

(ITS#8375) paged results control results in full db search?
by geert＠hendrickx.be 22 Feb '16

22 Feb '16

Full_Name: Geert Hendrickx Version: 2.4.44 OS: Linux URL: http://www.openldap.org/lists/openldap-technical/201602/msg00094.html Submission from: (NULL) (2a02:1810:4d03:d00:18e9:3ca5:a68f:c7f4) We found an odd issue when using LDAP Admin (www.ldapadmin.org), which by defaults uses the paged results control (RFC 2696) to limit search results. This client initially issues an objectclass=* search with one-level scope to list the first-level objects/trees on the LDAP DIT, which you can then browse/expand by clicking on them. On a large db, we noticed this initial search hits the timelimit, even though the equivalent command line search is instant. I found the difference is in using the paged result control: ldapsearch -s one -E \!pr=100 objectclass=\* objectclass => slow ldapsearch -s one objectclass=\* objectclass => fast The slapd stats+trace logging of each is in attachment. Notice the large number of objects being skipped with "scope not okay" in the first, where this does not happen in the second. This slows down the search, and on a very large db, makes it exceed the configured 60 seconds timelimit. A third variant, setting the sizelimit explicitly, avoids the issue: ldapsearch -s one -E \!pr=100 -z 100 objectclass=\* objectclass => fast Is this expected behaviour?

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 21 Feb '16

21 Feb '16

Ok, retested with latest code built from source. I also reconfirmed using a publicly available openldap server, to make sure it isn't something stupid I am doing locally. So you can reproduce easily, the test pseudo code is: ldap_initialize (ldaps://ldap.andrew.cmu.edu) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_sasl_bind_s ldap_initialize (ldap://128.2.11.104) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_start_tls_s ldap_sasl_bind_s The results are: Server with valid certificate, all values of LDAP_OPT_X_TLS_REQUIRE_CERT for both ldaps and ldap+starttls connect. This is what I would expect. Server with invalid certificate (IP does not match the cert FQDN), only NEVER and ALLOW values of LDAP_OPT_X_TLS_REQUIRE_CERT succeed for ldaps (this is what I would expect) however all values of LDAP_OPT_X_TLS_REQUIRE_CERT for ldap+starttls succeed, which is not what I would expect: I think that the certificate check should fail the connection, as per the ldaps behaviour. Martin...

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 21 Feb '16

21 Feb '16

Hi, This is a piece of code that I'm working on, rather than any bundled commands. The code works just fine (has for months) however I noticed in unit testing the operations empirically that the LDAP_OPT_X_TLS_REQUIRE_CERT option was handled differently depending on whether the TLS was provided implicitly over an ldaps: URI, or explicitly on an ldap: URI with STARTTLS. The pseudo sequence of functions is as follows: ldap_initialize ldap_set_option (various) if uri != ldaps: then ldap_start_tls_s ldap_sasl_bind_s Martin...

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by hyc＠symas.com 20 Feb '16

20 Feb '16

dog(a)pavlov.com wrote: > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then drop you a line with the results. What commands are you testing with? Are you using STARTTLS as a critical extension? If not, failures will be ignored. Note that this is already documented. -- -- 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#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by quanah＠zimbra.com 20 Feb '16

20 Feb '16

--On Saturday, February 20, 2016 6:06 PM +0000 dog(a)pavlov.com wrote: > > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap > to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then > drop you a line with the results. Again, you could just install the builds from the LTB project. In any case, all options work fine for me with a self-signed cert with ldaps:/// URIs. (2.4.44, linked to OpenSSL). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 20 Feb '16

20 Feb '16

Hi, The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. If I get time I'll run up a test platform and install from source, then drop you a line with the results. Martin...

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by quanah＠zimbra.com 20 Feb '16

20 Feb '16

--On Friday, February 19, 2016 4:02 PM +0000 dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 As already noted by Michael, that is an ancient release. In addition, since you're using a build provided by Debian/Ubuntu, it links to GnuTLS which has its own numerous issues. I'd strongly advise you: (a) Use a current OpenLDAP release (b) Use an OpenLDAP release that is linked to OpenSSL rather than GnuTLS If after both of those conditions are true you can still reproduce a problem, please follow up. If building OpenLDAP software is not in your line of expertise, you may wish to examine the options from the LTB project or Symas. <http://ltb-project.org/wiki/download#openldap> <https://symas.com/products/openldap-directory/> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by michael＠stroeder.com 20 Feb '16

20 Feb '16

dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 Note that 2.4.31 is almost for years old. Hence the standard question: Can you reproduce this with current release 2.4.44? Ciao, Michael.

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