openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#7048) Non root binding causes assert
by aitor.carrera＠edosoftfactory.com 21 Sep '11

21 Sep '11

Full_Name: Aitor Carrera Version: 2.4.21 OS: SLES10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.126.219.248) When we use a non root user to bind, with multiple threads and some concurrent proxies 1 .- In meta_back_bind_op_result method, in back-meta bind.c file the assert "assert( LDAP_BACK_CONN_BINDING( msc ) );" is evaluated to false. 2.- Next, calls meta_back_cancel (bind.c) and then ldap_abandon_ext and other assert is evaluated to false: slapd: sasl.c:74: ldap_sasl_bind: Assertion `ld != ((void *)0)' failed. That crash the slapd.

1 0

Re: (ITS#7027) [PATCH] Implement priority/weigh for DNS SRV records
by james.leddy＠redhat.com 20 Sep '11

20 Sep '11

> In addition, random seed has to be initialized, otherwise the behavior > is predictable. I didn't think it too big of a deal, since it doesn't have to be cryptographically random. I can submit a patch to call srandom() first. > On the other side, I do not think that calling srand() > in libldap is a good idea. The client application should do that. Or > is there any other option? The function ldap_domain2hostlist returns a list of strings, there isn't any weight/prio information for the client to act on. Furthermore the weight prio section was commented out, I figured the library was the right place to do it. The algo specified in rfc2782 is detailed, and specifies a random number should be generated., I didn't want to implement it because it results in sorting once by prio, once by weight instead of one sort that does both. -- James M. Leddy Technical Account Manager Red Hat Inc.

1 0

(ITS#7047) slapd crash on bad indexed translucent
by hugo.monteiro＠fct.unl.pt 20 Sep '11

20 Sep '11

Full_Name: Hugo Monteiro Version: 2.4.23 OS: Debian Squeeze 64bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.136.124.150) Performing a substring query on a locally stored attribute of a translucent database, with only equality index will result on slapd crash. We have a translucent database set up to handle samba attributes and we observed that some client operations would crash slapd (like when performing user enumeration, while changind folder ACLs). The last logged query was "(&(objectClass=sambaGroupMapping)(sambaGroupType=4)(sambaSID=<OUR_DOMAINSID_HERE>*))" As per samba documentation we only had equality index on sambaSID attribute. We have then reconfigured that attribute to use eq,sub,pres indexes, ran slapindex on the database and slapd stopped crashing with that query.

1 0

Re: (ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by jvcelak＠redhat.com 20 Sep '11

20 Sep '11

On Wednesday 24 August 2011 21:28:03, James Leddy wrote: > on incoming ftp There is a typo in the patch: + hostent_head[hostent_count].priority=priority; -+ hostent_head[hostent_count].weight=priority; ++ hostent_head[hostent_count].weight=weight; + hostent_head[hostent_count].port=port; + strncpy(hostent_head[hostent_count].hostname, host,255); + hostent_count=hostent_count+1; In addition, random seed has to be initialized, otherwise the behavior is predictable. On the other side, I do not think that calling srand() in libldap is a good idea. The client application should do that. Or is there any other option? Jan

1 0

(ITS#7046) OpenLDAP logs nothing at info priority, excessive at debug priority
by nick.urbanik＠optusnet.com.au 19 Sep '11

19 Sep '11

Full_Name: Nick Urbanik Version: 2.3.43-12 and 2.4.23-15 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.10.68.69) To my great surprise, OpenLDAP logs nothing at info priority, but excessive amounts at debug priority, even when the loglevel is set to stats. Here are examples of the size of log files holding *nothing* but OpenLDAP stats logging in a production server: # ls -lSr | tail -n4 -rw------- 1 root root 7160148590 Jul 28 10:48 ldap -rw------- 1 root root 24102619198 Jul 26 04:02 ldap.3 -rw------- 1 root root 25034865261 Jul 27 04:02 ldap.2 -rw------- 1 root root 25504838803 Jul 28 04:02 ldap.1 $ bc -ql scale = 6 25504838803 / 2^30 23.753232 In other words, we were getting nearly 24 gigabytes of logging *each* *day*. I raised this in the openldap-technical mailing list: http://www.openldap.org/lists/openldap-technical/201107/msg00205.html but found that this is by design: http://www.openldap.org/lists/openldap-technical/201109/msg00223.html OpenLDAP should log at info priority at least the following: * when it is starting up * when it is shutting down cleanly * any errors, indicating issues that the sys admin should pay attention to * (perhaps): one line for each connection.

1 0

Re: (ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by c.klein＠tarent.de 19 Sep '11

19 Sep '11

Thanks for the information. Any chance this will ever be implemented? I for my part would rather use the objectIdentifiers than the canonical attribute names.

1 0

Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by Jason_Haar＠trimble.com 18 Sep '11

18 Sep '11

This is a multi-part message in MIME format. --------------020600000809090503050207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Riight - I see what you mean now. I mis-read the debugging messages as meaning it had reconnected without TLS. Retesting with a sniffer shows otherwise. So "-Z" works as I had hoped - excellent Thanks! Jason On 19/09/11 15:22, Kurt Zeilenga wrote: > > On Sep 18, 2011, at 5:41 PM, Jason_Haar(a)trimble.com wrote: > > > Full_Name: Jason Haar > > Version: 2.4.21 > > OS: Fedora > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (222.154.246.214) > > > > > > As you know, LDAP passwords are sent in cleartext unless TLS or SASL > are used. > > Depending on TLS cipher suites and SASL mechnanism choice, of course. > > And you shouldn't be using a cleartext mechanism unless you've first > authenticated the server. > > > > > However, "ldapsearch -Z" will fall-back onto cleartext if any form > of TLS error > > occurs, even the non-fatal "TLS: hostname does not match CN in peer > certificate" > > error. > > Actually, ldapsearch(1) does not fall back into cleartext in this > case. The OpenLDAP library, and most servers, wisely don't support > stop TLS. > > What ldapsearch(1) does is, if told to check certs (the default) and > they are bad, is to terminate the session and exit. > > > > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch > tries again not > > using TLS! > > No it doesn't. > > > > > This seems wasteful to me. It is still *more secure* to continue the > encrypted > > TLS session than to fallback onto cleartext. > > No, it's not. If you continued to use TLS, there is no server > authentication. Use of cleartext mechanism to an unauthenticated > server is quite insecure. > > Now it might seem that if one said use simple bind w/ password and -Z, > that it would be reasonable to assume the user didn't care about > server authentication (or data integrity/confidential). But -Z is > designed less for use with simple bind w/ password but with SASL > mechanisms. > > Now, if you really want to do that, just tell ldapsearch(1) not to do > cert checks. > > > > Web browsers are a good example of > > this: if you connect to a self-signed https site, you can choose to > continue - > > as untrusted https is still secured against other attackers. > > And some browsers are stupid enough to do basic authentication without > first authenticating the server. > > > > If a user wants to guarantee the trustworthiness of their ldapsearch > session, > > they can use "-ZZ" to achieve that - but I can't see any reason to > stop people > > using "-Z" if they want to? > > Nothing stops those who don't want cert checks from disabling them. > > > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS > round-robin > > entry for the domain name: as such the LDAP host *never* matches the > hostname > > DNS round-robin gives back - and I don't care - I just don't want > the network > > group sniffing my password ;-) > > Then you likely should be doing -ZZ (because you care about > eavesdropping) while disabling the cert checks (because you seem to > not care that you might be sending your password to a man-in-the-middle). > > -- Kurt > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 --------------020600000809090503050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Riight - I see what you mean now. I mis-read the debugging messages as meaning it had reconnected without TLS. Retesting with a sniffer shows otherwise. So "-Z" works as I had hoped - excellent Thanks! Jason On 19/09/11 15:22, Kurt Zeilenga wrote: <blockquote cite="mid:F5AC234D-558A-4BFE-A053-EDB0B082FC41@openldap.org" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="MS Exchange Server version 6.5.7654.12"> <title>Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match</title>  On Sep 18, 2011, at 5:41 PM, <a class="moz-txt-link-abbreviated" href="mailto:Jason_Haar@trimble.com">Jason_Haar(a)trimble.com</a> wrote: > Full_Name: Jason Haar > Version: 2.4.21 > OS: Fedora > URL: <a moz-do-not-send="true" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (222.154.246.214) > > > As you know, LDAP passwords are sent in cleartext unless TLS or SASL are used. Depending on TLS cipher suites and SASL mechnanism choice, of course. And you shouldn't be using a cleartext mechanism unless you've first authenticated the server. > > However, "ldapsearch -Z" will fall-back onto cleartext if any form of TLS error > occurs, even the non-fatal "TLS: hostname does not match CN in peer certificate" > error. Actually, ldapsearch(1) does not fall back into cleartext in this case.  The OpenLDAP library, and most servers, wisely don't support stop TLS. What ldapsearch(1) does is, if told to check certs (the default) and they are bad, is to terminate the session and exit. > > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch tries again not > using TLS! No it doesn't. > > This seems wasteful to me. It is still *more secure* to continue the encrypted > TLS session than to fallback onto cleartext. No, it's not.  If you continued to use TLS, there is no server authentication.  Use of cleartext mechanism to an unauthenticated server is quite insecure. Now it might seem that if one said use simple bind w/ password and -Z, that it would be reasonable to assume the user didn't care about server authentication (or data integrity/confidential).   But -Z is designed less for use with simple bind w/ password but with SASL mechanisms. Now, if you really want to do that, just tell ldapsearch(1) not to do cert checks. > Web browsers are a good example of > this: if you connect to a self-signed https site, you can choose to continue - > as untrusted https is still secured against other attackers. And some browsers are stupid enough to do basic authentication without first authenticating the server. > > If a user wants to guarantee the trustworthiness of their ldapsearch session, > they can use "-ZZ" to achieve that - but I can't see any reason to stop people > using "-Z" if they want to? Nothing stops those who don't want cert checks from disabling them. > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS round-robin > entry for the domain name: as such the LDAP host *never* matches the hostname > DNS round-robin gives back - and I don't care - I just don't want the network > group sniffing my password ;-) Then you likely should be doing -ZZ (because you care about eavesdropping) while disabling the cert checks (because you seem to not care that you might be sending your password to a man-in-the-middle). -- Kurt </blockquote> <pre class="moz-signature" cols="72">-- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 </pre> </body> </html> --------------020600000809090503050207--

1 0

Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by kurt＠OpenLDAP.org 18 Sep '11

18 Sep '11

On Sep 18, 2011, at 5:41 PM, Jason_Haar(a)trimble.com wrote: > Full_Name: Jason Haar > Version: 2.4.21 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (222.154.246.214) > > > As you know, LDAP passwords are sent in cleartext unless TLS or SASL are used. Depending on TLS cipher suites and SASL mechnanism choice, of course. And you shouldn't be using a cleartext mechanism unless you've first authenticated the server. > > However, "ldapsearch -Z" will fall-back onto cleartext if any form of TLS error > occurs, even the non-fatal "TLS: hostname does not match CN in peer certificate" > error. Actually, ldapsearch(1) does not fall back into cleartext in this case. The OpenLDAP library, and most servers, wisely don't support stop TLS. What ldapsearch(1) does is, if told to check certs (the default) and they are bad, is to terminate the session and exit. > > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch tries again not > using TLS! No it doesn't. > > This seems wasteful to me. It is still *more secure* to continue the encrypted > TLS session than to fallback onto cleartext. No, it's not. If you continued to use TLS, there is no server authentication. Use of cleartext mechanism to an unauthenticated server is quite insecure. Now it might seem that if one said use simple bind w/ password and -Z, that it would be reasonable to assume the user didn't care about server authentication (or data integrity/confidential). But -Z is designed less for use with simple bind w/ password but with SASL mechanisms. Now, if you really want to do that, just tell ldapsearch(1) not to do cert checks. > Web browsers are a good example of > this: if you connect to a self-signed https site, you can choose to continue - > as untrusted https is still secured against other attackers. And some browsers are stupid enough to do basic authentication without first authenticating the server. > > If a user wants to guarantee the trustworthiness of their ldapsearch session, > they can use "-ZZ" to achieve that - but I can't see any reason to stop people > using "-Z" if they want to? Nothing stops those who don't want cert checks from disabling them. > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS round-robin > entry for the domain name: as such the LDAP host *never* matches the hostname > DNS round-robin gives back - and I don't care - I just don't want the network > group sniffing my password ;-) Then you likely should be doing -ZZ (because you care about eavesdropping) while disabling the cert checks (because you seem to not care that you might be sending your password to a man-in-the-middle). -- Kurt

1 0

(ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by Jason_Haar＠trimble.com 18 Sep '11

18 Sep '11

Full_Name: Jason Haar Version: 2.4.21 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.154.246.214) As you know, LDAP passwords are sent in cleartext unless TLS or SASL are used. However, "ldapsearch -Z" will fall-back onto cleartext if any form of TLS error occurs, even the non-fatal "TLS: hostname does not match CN in peer certificate" error. i.e. TLS is attempted, the hostname doesn't match, so ldapsearch tries again not using TLS! This seems wasteful to me. It is still *more secure* to continue the encrypted TLS session than to fallback onto cleartext. Web browsers are a good example of this: if you connect to a self-signed https site, you can choose to continue - as untrusted https is still secured against other attackers. If a user wants to guarantee the trustworthiness of their ldapsearch session, they can use "-ZZ" to achieve that - but I can't see any reason to stop people using "-Z" if they want to? (I'm using ldapsearch to dump Active Directory LDAP data via the DNS round-robin entry for the domain name: as such the LDAP host *never* matches the hostname DNS round-robin gives back - and I don't care - I just don't want the network group sniffing my password ;-)

1 0

make error for signal.c
by Ropp, Gary 18 Sep '11

18 Sep '11

I have successfully run ./configure --disable-slapd and make depend. When I run make, I get the following errors: [dwadmin@erptestdb:DGWT]$make Making all in /var/openldap/openldap-2.4.23 Entering subdirectory include Entering subdirectory libraries Making all in /var/openldap/openldap-2.4.23/libraries Entering subdirectory liblutil rm -f version.c ../../build/mkversion -v "2.4.23" liblutil.a > version.c /usr/sfw/bin/gcc -O2 -ansi -Wno-main -DAVALON -DNO_CISAM -DORACLE -DDWLDAP -I../../include -I../../include -c signal.c signal.c: In function `lutil_sigaction': signal.c:25: error: storage size of 'action' isn't known signal.c:25: error: storage size of 'oaction' isn't known *** Error code 1 make: Fatal error: Command failed for target `signal.o' Current working directory /var/openldap/openldap-2.4.23/libraries/liblutil *** Error code 1 The following command caused the error: for i in liblutil liblber liblunicode libldap libldap_r librewrite ; do \ echo " Entering subdirectory $i"; \ ( cd $i; /usr/ccs/bin/make all ); \ if test $? != 0 ; then exit 1; fi ; \ echo " "; \ done make: Fatal error: Command failed for target `all-common' Current working directory /var/openldap/openldap-2.4.23/libraries *** Error code 1 The following command caused the error: for i in include libraries clients servers tests doc ; do \ echo " Entering subdirectory $i"; \ ( cd $i; /usr/ccs/bin/make all ); \ if test $? != 0 ; then exit 1; fi ; \ echo " "; \ done make: Fatal error: Command failed for target `all-common' Not sure if this problem compiling signal.c is a bug or not. The include file, signal.h appears to be in the correct place. Gary Ropp Senior Programmer College of the Siskiyous 530-938-5553

2 1

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