openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: Regression after ITS#8427 fix with back-ldap
by hyc＠symas.com 10 Jul '19

10 Jul '19

Ond=C5=99ej Kuzn=C3=ADk wrote: > On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc(a)symas.com wrote: >> ondra(a)mistotebe.net wrote: >>> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >>>> Hello, >>>> >>>> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set= up=20 >>>> TLS settings on each reconnection) introduce a regression when the p= roxy=20 >>>> connect to the**Backend ldap server via ldaps:// >>>> >>>> The relevent part of my config is: >>>> >>>> dn: olcDatabase=3D{2}ldap,cn=3Dconfig >>>> objectClass: olcDatabaseConfig >>>> objectClass: olcLDAPConfig >>>> olcDatabase: {2}ldap >>>> olcSuffix: dc=3Dlocal >>>> olcDbURI: ldaps://ldap.local >>>> olcDbChaseReferrals: TRUE >>>> olcDbRebindAsUser: TRUE >>>> olcDbIDAssertBind: bindmethod=3Dnone tls_cacert=3D/etc/pki/tls/certs= /ca.crt >>>> olcDbIDAssertAuthzFrom: "*" >>>> >>>> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >>>> >>>> On backend ldap server logs, I get the message "TLS negociation fail= ure" >>> >>> I've set up a test script here >>> https://github.com/mistotebe/openldap/tree/its8427-regression >>> >>> This runs without issues but if you replace olcDbStartTLS with an >>> analogous olcDbIDAssertBind in the configs, it seems the CA certifica= te >>> is not set for the connection. >> >> Then this is a new bug. Clearly the idassert-bind option takes tls_cac= ert >> as a parameter, so if it is provided it is expected to be used. >=20 > Sure, on idassert connections only, though. When does back-ldap use one= ? > I want to edit the linked script to do exercise that so we have a decen= t > test for this now. idassert is used when you want back-ldap to propagate the incoming client= 's identity to the remote server. It affects every operation that a client i= ssues. --=20 -- 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: Regression after ITS#8427 fix with back-ldap
by ondra＠mistotebe.net 10 Jul '19

10 Jul '19

On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >>> Hello, >>> >>> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up >>> TLS settings on each reconnection) introduce a regression when the proxy >>> connect to the**Backend ldap server via ldaps:// >>> >>> The relevent part of my config is: >>> >>> dn: olcDatabase={2}ldap,cn=config >>> objectClass: olcDatabaseConfig >>> objectClass: olcLDAPConfig >>> olcDatabase: {2}ldap >>> olcSuffix: dc=local >>> olcDbURI: ldaps://ldap.local >>> olcDbChaseReferrals: TRUE >>> olcDbRebindAsUser: TRUE >>> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt >>> olcDbIDAssertAuthzFrom: "*" >>> >>> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >>> >>> On backend ldap server logs, I get the message "TLS negociation failure" >> >> I've set up a test script here >> https://github.com/mistotebe/openldap/tree/its8427-regression >> >> This runs without issues but if you replace olcDbStartTLS with an >> analogous olcDbIDAssertBind in the configs, it seems the CA certificate >> is not set for the connection. > > Then this is a new bug. Clearly the idassert-bind option takes tls_cacert > as a parameter, so if it is provided it is expected to be used. Sure, on idassert connections only, though. When does back-ldap use one? I want to edit the linked script to do exercise that so we have a decent test for this now. >> I guess we've introduced a behaviour change with ITS#8427, not sure what >> the documentation implies should happen in these cases, whether the new >> behaviour is inconsistent with it or you've been relying on incorrect >> behaviour that has since been corrected. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: Regression after ITS#8427 fix with back-ldap
by hyc＠symas.com 10 Jul '19

10 Jul '19

ondra(a)mistotebe.net wrote: > On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >> Hello, >> >> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up >> TLS settings on each reconnection) introduce a regression when the proxy >> connect to the**Backend ldap server via ldaps:// >> >> The relevent part of my config is: >> >> dn: olcDatabase={2}ldap,cn=config >> objectClass: olcDatabaseConfig >> objectClass: olcLDAPConfig >> olcDatabase: {2}ldap >> olcSuffix: dc=local >> olcDbURI: ldaps://ldap.local >> olcDbChaseReferrals: TRUE >> olcDbRebindAsUser: TRUE >> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt >> olcDbIDAssertAuthzFrom: "*" >> >> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >> >> On backend ldap server logs, I get the message "TLS negociation failure" > > I've set up a test script here > https://github.com/mistotebe/openldap/tree/its8427-regression > > This runs without issues but if you replace olcDbStartTLS with an > analogous olcDbIDAssertBind in the configs, it seems the CA certificate > is not set for the connection. Then this is a new bug. Clearly the idassert-bind option takes tls_cacert as a parameter, so if it is provided it is expected to be used. > > I guess we've introduced a behaviour change with ITS#8427, not sure what > the documentation implies should happen in these cases, whether the new > behaviour is inconsistent with it or you've been relying on incorrect > behaviour that has since been corrected. > > Regards, > -- -- 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: Regression after ITS#8427 fix with back-ldap
by a.chelouah＠gmail.com 10 Jul '19

10 Jul '19

This is a multi-part message in MIME format. --------------AC617754E4A0ACE1B2AD0EAA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 09/07/2019 à 14:14, ondra(a)mistotebe.net a écrit : > On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >> Hello, >> >> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up >> TLS settings on each reconnection) introduce a regression when the proxy >> connect to the**Backend ldap server via ldaps:// >> >> The relevent part of my config is: >> >> dn: olcDatabase={2}ldap,cn=config >> objectClass: olcDatabaseConfig >> objectClass: olcLDAPConfig >> olcDatabase: {2}ldap >> olcSuffix: dc=local >> olcDbURI: ldaps://ldap.local >> olcDbChaseReferrals: TRUE >> olcDbRebindAsUser: TRUE >> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt >> olcDbIDAssertAuthzFrom: "*" >> >> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >> >> On backend ldap server logs, I get the message "TLS negociation failure" > I've set up a test script here > https://github.com/mistotebe/openldap/tree/its8427-regression > > This runs without issues but if you replace olcDbStartTLS with an > analogous olcDbIDAssertBind in the configs, it seems the CA certificate > is not set for the connection. > > I guess we've introduced a behaviour change with ITS#8427, not sure what > the documentation implies should happen in these cases, whether the new > behaviour is inconsistent with it or you've been relying on incorrect > behaviour that has since been corrected. > > Regards, > I confirm that using the configuration dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI:ldaps://ldap.local olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertAuthzFrom: "*" olcDbStartTLS: ldaps tls_cacert=/etc/pki/tls/certs/ca.crt /i.e/,removing olcDbIDAssertBind, test is running without issue. Regards. --------------AC617754E4A0ACE1B2AD0EAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Le 09/07/2019 à 14:14, <a class="moz-txt-link-abbreviated" href="mailto:ondra@mistotebe.net">ondra(a)mistotebe.net</a> a écrit : </div> <blockquote type="cite" cite="mid:E1hkp0a-0005zG-VU@gauss.openldap.net"> <pre class="moz-quote-pre" wrap="">On Thu, Jun 27, 2019 at 08:08:19PM +0000, <a class="moz-txt-link-abbreviated" href="mailto:a.chelouah@gmail.com">a.chelouah(a)gmail.com</a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Hello, Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up TLS settings on each reconnection) introduce a regression when the proxy connect to the**Backend ldap server via <a class="moz-txt-link-freetext" href="ldaps://">ldaps://</a> The relevent part of my config is: dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: <a class="moz-txt-link-freetext" href="ldaps://ldap.local">ldaps://ldap.local</a> olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt olcDbIDAssertAuthzFrom: "*" (I also tried by setting LDAPTLS_CACERT env var when starting slapd) On backend ldap server logs, I get the message "TLS negociation failure" </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I've set up a test script here <a class="moz-txt-link-freetext" href="https://github.com/mistotebe/openldap/tree/its8427-regression">https://github.com/mistotebe/openldap/tree/its8427-regression</a> This runs without issues but if you replace olcDbStartTLS with an analogous olcDbIDAssertBind in the configs, it seems the CA certificate is not set for the connection. I guess we've introduced a behaviour change with ITS#8427, not sure what the documentation implies should happen in these cases, whether the new behaviour is inconsistent with it or you've been relying on incorrect behaviour that has since been corrected. Regards, </pre> </blockquote> I confirm that using the configuration <pre class="moz-quote-pre" wrap="">dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: <a class="moz-txt-link-freetext">ldaps://ldap.local</a> olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertAuthzFrom: "*" olcDbStartTLS: ldaps tls_cacert=/etc/pki/tls/certs/ca.crt </pre> i.e,removing olcDbIDAssertBind, test is running without issue. <pre class="moz-quote-pre" wrap=""> </pre> Regards. <pre class="moz-quote-pre" wrap=""> </pre> </body> </html> --------------AC617754E4A0ACE1B2AD0EAA--

1 0

Re: Regression after ITS#8427 fix with back-ldap
by ondra＠mistotebe.net 09 Jul '19

09 Jul '19

On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: > Hello, > > Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up > TLS settings on each reconnection) introduce a regression when the proxy > connect to the**Backend ldap server via ldaps:// > > The relevent part of my config is: > > dn: olcDatabase={2}ldap,cn=config > objectClass: olcDatabaseConfig > objectClass: olcLDAPConfig > olcDatabase: {2}ldap > olcSuffix: dc=local > olcDbURI: ldaps://ldap.local > olcDbChaseReferrals: TRUE > olcDbRebindAsUser: TRUE > olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt > olcDbIDAssertAuthzFrom: "*" > > (I also tried by setting LDAPTLS_CACERT env var when starting slapd) > > On backend ldap server logs, I get the message "TLS negociation failure" I've set up a test script here https://github.com/mistotebe/openldap/tree/its8427-regression This runs without issues but if you replace olcDbStartTLS with an analogous olcDbIDAssertBind in the configs, it seems the CA certificate is not set for the connection. I guess we've introduced a behaviour change with ITS#8427, not sure what the documentation implies should happen in these cases, whether the new behaviour is inconsistent with it or you've been relying on incorrect behaviour that has since been corrected. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9051) slapo-accesslog fails to log compare, search
by quanah＠symas.com 08 Jul '19

08 Jul '19

--On Monday, July 08, 2019 11:33 PM +0000 quanah(a)openldap.org wrote: Note: compare operations are confirmed also to not log. :~# ldapcompare -Y EXTERNAL -H ldapi:/// cn=admin,dc=rb,dc=symas,dc=net cn:admin TRUE ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=accesslog -LLL dn: cn=accesslog objectClass: auditContainer cn: accesslog dn: reqStart=20190708222217.000000Z,cn=accesslog objectClass: auditBind reqStart: 20190708222217.000000Z reqEnd: 20190708222217.000001Z reqType: bind reqSession: 1014 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE dn: reqStart=20190709001033.000000Z,cn=accesslog objectClass: auditBind reqStart: 20190709001033.000000Z reqEnd: 20190709001033.000001Z reqType: bind reqSession: 1019 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9051) slapo-accesslog fails to log compare, search
by quanah＠openldap.org 08 Jul '19

08 Jul '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) In testing out various logging scenarios with the accesslog overlay, it has been found that it fails to log certain operations in the underlying accesslog DB. Specifically, it fails to log "reads" or "compare" + "search". It does however log "writes" or "bind". Example configuration: dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap/accesslog olcAddContentAcl: FALSE olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: reqStart olcDbIndex: reqEnd olcDbIndex: reqResult olcDbIndex: reqDN olcDbMaxReaders: 0 olcDbMaxSize: 5120000 olcDbMode: 0600 olcDbNoSync: FALSE olcDbRtxnSize: 10000 olcDbSearchStack: 16 olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: TRUE olcReadOnly: FALSE olcRootDN: cn=config olcSuffix: cn=accesslog olcSyncUseSubentry: FALSE olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth manage by * break dn: olcOverlay={0}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig objectClass: olcOverlayConfig olcAccessLogDB: cn=accesslog olcOverlay: {0}accesslog olcAccessLogOps: reads olcAccessLogOps: writes olcAccessLogPurge: 1+00:00 1+00:00 olcAccessLogSuccess: TRUE Performing a search in this scenario results in nothing logged. Changing it to "reads" only (no writes), nothing logged Changing it to "bind, search, compare", the bind is logged, but nothing else: root@anvil3:~/accesslog-testing# ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=accesslog -LLL -Q dn: cn=accesslog objectClass: auditContainer cn: accesslog dn: reqStart=20190708222217.000000Z,cn=accesslog objectClass: auditBind reqStart: 20190708222217.000000Z reqEnd: 20190708222217.000001Z reqType: bind reqSession: 1014 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE Search is clearly logged at STATS level logging: Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 ACCEPT from IP=[::1]:51644 (IP=[::]:389) Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND dn="cn=admin,dc=rb,dc=symas,dc=net" method=128 Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND dn="cn=admin,dc=rb,dc=symas,dc=net" mech=SIMPLE ssf=0 Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 RESULT tag=97 err=0 text= Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SRCH base="dc=rb,dc=symas,dc=net" scope=2 deref=0 filter="(objectClass=*)" Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text= Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=2 UNBIND Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 closed

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 08 Jul '19

08 Jul '19

On Thu, Jun 27, 2019 at 10:34:19PM -0700, Quanah Gibson-Mount wrote: > --On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenkamp(a)ionos.com > wrote: > > > On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: > > Had a customer who was hitting this issue try out these patches -- It > greatly decreases the search time (from unknown/infinite to 1 minute). > Unfortunately slapd then segv's. Working on getting a test database to > reproduce the issue with for a good backtrace. oh, that's too bad. I'd be happy to participate in the bug hunt. May I ask: which version did your customer use? I have modified the patch to work with the recent changes on master, but I did not dig in very deep to understand these changes. So I must admit that these modifications to the patch are completely untested (except the tests in the tests subdir). Things might work better with the 2.4.46/47 patch, if that is an option for your customer. Wrt getting a test-tree, maybe the python script I have in the github repo for the patch can provide one. (https://github.com/hbo/openldap-mdb-deref-problem/blob/master/scripts/write…) I'm of course very interested to keep this patch alive, so if you have details on the segv, please let me know. Henrik > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> -- Dr. rer. nat. Henrik Bohnenkamp Senior Sysadmin IT Operations Monitoring & Infrastructure 1&1 IONOS SE | Brauerstraße 48 | 76135 Karlsruhe | Germany Phone: +49 721 91374 - 4159 E-mail: henrik.bohnenkamp(a)ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.

1 0

ITS#9047 published: SECURITY: Coverity report on LMDB
by openldap-its＠OpenLDAP.org 08 Jul '19

08 Jul '19

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

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 08 Jul '19

08 Jul '19

--On Thursday, June 27, 2019 8:56 PM +0000 quanah(a)symas.com wrote: > --On Thursday, June 27, 2019 8:35 PM +0000 hyc(a)symas.com wrote: > >> No, because order is irrelevant for these. > > Cool, thanks! I'll continue on with deeper testing then. :) Given the current implementation of OpenLDAP, this feature is impossible to use w/o recompiling OpenLDAP when a change to the IDL size is made. This is because LDAP_PVT_THREAD_STACK_SIZE must be adjusted as well and that requires a recompile. The default size for LDAP_PVT_THREAD_STACK_SIZE is: ( 1 * 1024 * 1024 * sizeof(void *) ) which works for an IDL size of 16 (2^16) which is 65536. If you change the IDL size, say to 22, then the new IDL size is: 4,194,304. We then use this difference to find the offset we need to adjust LDAP_PVT_THREAD_STACK_SIZE by: 4194304/65536 = 64 So it needs to be 64 time larger: ( 64 * 1024 * 1024 * sizeof(void *) ) Generally, this feature is simply unusuable (currently) as a tunable given the requirement for recompiling OpenLDAP to use it. --QUanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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