Full_Name: Maciej Puzio Version: 2.4.44 and git head OS: Ubuntu 16.04 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.112.109.41) Incorrect handling of TLS options causes syncrepl to use different values for first connection attempt and subsequent retries. In some circumstances this may result in syncrepl unable to recover from a temporary network outage. Note: This bug has very similar symptoms and occurs in similar circumstances as ITS# 8385 (that has already been fixed). However, my investigation indicates that this is a separate issue. Steps to reproduce the problem: 1. Configure two LDAP servers in dual master replication setup using slapd.conf config file as described below. 2. Provide the servers with TLS certificates that are correct but do not include an address used in syncrepl provider setting. (Note: SECURE256 requires 4096-bit RSA key) 3. Set tls_reqcert to allow in both slapd.conf and ldap.conf. 4. Start slapd on both servers. 5. Stop and restart slapd on server A. 6. Server B will write errors to syslog: slapd: do_syncrep2: rid=001 (-1) Can't contact LDAP server slapd: do_syncrepl: rid=001 rc -1 retrying (9 reieies left) Expected result: After predefined time server B will retry replication, and we will see messages: slapd: do_syncrep1: rid=001 starting refresh slapd: do_syncrep1: rid=001 finished refresh Observed result: Server B produces theollolowing messages in a loop: slapd: do_syncrepl: rid=001 rc -1 retrying (8 retries left) slapd: slap_client_connect: URI=ldaps://10.0.0.1 DN="cn=root,dc=test" ldap_sasl_bind_s failed (-1) The relevant parts of slapd.conf: (for server A at 10.0.0.1) loglevel 1 serverID 001 moduleload syncprov TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSCACertificateFile /etc/ldap/ssl/ca.pem TLSCertificateFile /etc/ldap/ssl/srvA.pem ATATLSCertificateKeyFile /etc/ldap/ssl/srvA.key syncrepl rid=001 provider=ldaps://10.0.0.2 type=refreshAndPersist retry="30 10 300 +" searchbase="dc=test" attrs="*,+" bindmethod=simple binddn="cn=root,dc=test" credentials="plaintext-password" tls_reqcert=allow keepalive="240:5:10" mirrormode TRUE overlay syncprov syncprov-checkpoint 10 1440 OpenLDAP was build with this configuration: ./configure --prefix=/opt/openldap --enable-debug --enable-dynamic --enable-syslog --enable-local --enable-slapd --enable-crypt --enable-modules --enable-backends --enable-ndb=no --enable-shell=no --enable-perl=no --enable-sql=no --enable-wt=no --enable-overlays --with-tls=gnutls CPPFLAGS="-Wno-format-extra-args" Note that GnuTLS was used, following Debian and Ubuntu practice. I did not test this issue with other TLS libraries, and I do not know if this issue is GnuTLS-related or not. Debug findings: The above symptoms are caused by the following lines located at the end of ldap_int_tls_start in file libraries/libldap/tls2.c: if (ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_NEVER && ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_ALLOW) { ld->ld_errno = ldap_pvt_tls_check_hostname( ld, ssl, host ); if (ld->ld_errno != LDAP_SUCCESS) { return ld->ld_errno; } } The value of ld->ld_options.ldo_tls_require_cert is correct during first syncrepl connection attempt, but incorrect during retries. During my tests I noticed that it tended to equal 2 (demand), even when tls_reqcert was set to allow or never. On other occasions I noticed this variable to assume the value of TLS_REQCERT from ldap.conf, giving a peculiar result of first syncrepl connection using setting from slapd.conf, and subsequent ones from ldap.conf. It is possible that the value is uninitialized. Further debugging showed that this situation results from slap_client_connect (servers/slapd/config.c) not calling bindconf_tls_set on retries. The relevant code is: if ( sb->sb_tls_do_init ) { rc = bindconf_tls_set( sb, ld ); } else if ( sb->sb_tls_ctx ) { rc = ldap_set_option% l ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); } Due to my limited familiarity with OpenLDAP design, I did not debug the issue further and did not find the root cause of this problem. Discusonon about relationship of this bug to ITS# 8385: On surface these bugs appear similar to each other like twins, both causing failures of syncrepl retries due to incorrect value of tls_reqcert. In fact, I found this bug while testing Ubuntu slapd and libldap packages with patch for #8385 backported. There are however some subtle differences: 1. A TLS certificate incorrect in a different way is needed to reproduce #8385: in my tests it listed a correct host, but had a key too weak for specified cipher strength. 2. Bug #8385 has much lower reproducibility (as expected for unallocated memory issue). 3. Symptoms of #8385 are a result of code in tls_g.c (tlsg_session_accept does wrong tests), while this bug results from host tests in tls2.c (ldap_int_tls_start). Both are triggered by an incorrect value of tls_reqcert. 4. I suspect a different cause leading to wrong tls_reqcert value in both bugs. Please let me know if you need further information. Thank you very much. Maciej Puzio
Proposed patch: diff -ru servers/slapd.orig/config.c servers/slapd/config.c --- servers/slapd.orig/config.c 2016-05-16 16:49:08.000000000 -0500 +++ servers/slapd/config.c 2016-05-19 20:28:54.002163670 -0500 @@ -1864,7 +1864,7 @@ int bindconf_tls_set( slap_bindconf *bc, LDAP *ld ) { - int i, rc, newctx = 0, res = 0; + int i, rc, res = 0; char *ptr = (char *)bc, **word; bc->sb_tls_do_init = 0; @@ -1878,8 +1878,7 @@ "bindconf_tls_set: failed to set %s to %s\n", bindtlsopts[i].key, *word, 0 ); res = -1; - } else - newctx = 1; + } } } if ( bc->sb_tls_reqcert ) { @@ -1890,8 +1889,7 @@ "bindconf_tls_set: failed to set tls_reqcert to %s\n", bc->sb_tls_reqcert, 0, 0 ); res = -1; - } else - newctx = 1; + } } if ( bc->sb_tls_protocol_min ) { rc = ldap_pvt_tls_config( ld, LDAP_OPT_X_TLS_PROTOCOL_MIN, @@ -1901,8 +1899,7 @@ "bindconf_tls_set: failed to set tls_protocol_min to %s\n", bc->sb_tls_protocol_min, 0, 0 ); res = -1; - } else - newctx = 1; + } } #ifdef HAVE_OPENSSL_CRL if ( bc->sb_tls_crlcheck ) { @@ -1913,17 +1910,15 @@ "bindconf_tls_set: failed to set tls_crlcheck to %s\n", bc->sb_tls_crlcheck, 0, 0 ); res = -1; - } else - newctx = 1; + } } #endif - if ( newctx ) { + if ( bc->sb_tls_ctx ) { + rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, bc->sb_tls_ctx ); + if ( rc ) + res = rc; + } else { int opt = 0; - - if ( bc->sb_tls_ctx ) { - ldap_pvt_tls_ctx_free( bc->sb_tls_ctx ); - bc->sb_tls_ctx = NULL; - } rc = ldap_set_option( ld, LDAP_OPT_X_TLS_NEWCTX, &opt ); if ( rc ) res = rc; @@ -2000,14 +1995,7 @@ slap_client_keepalive(ld, &sb->sb_keepalive); #ifdef HAVE_TLS - if ( sb->sb_tls_do_init ) { - rc = bindconf_tls_set( sb, ld ); - - } else if ( sb->sb_tls_ctx ) { - rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, - sb->sb_tls_ctx ); - } - + rc = bindconf_tls_set( sb, ld ); if ( rc ) { Debug( LDAP_DEBUG_ANY, "slap_client_connect: " diff -ru servers/slapd.orig/back-ldap/bind.c servers/slapd/back-ldap/bind.c --- servers/slapd.orig/back-ldap/bind.c 2016-05-16 16:49:07.000000000 -0500 +++ servers/slapd/back-ldap/bind.c 2016-05-19 19:41:35.654431746 -0500 @@ -735,11 +735,7 @@ sb = &li->li_tls; } - if ( sb->sb_tls_do_init ) { - bindconf_tls_set( sb, ld ); - } else if ( sb->sb_tls_ctx ) { - ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); - } + bindconf_tls_set( sb, ld ); /* if required by the bindconf configuration, force TLS */ if ( ( sb == &li->li_acl || sb == &li->li_idassert.si_bc ) && diff -ru servers/slapd.orig/back-meta/conn.c servers/slapd/back-meta/conn.c --- servers/slapd.orig/back-meta/conn.c 2016-05-16 16:49:07.000000000 -0500 +++ servers/slapd/back-meta/conn.c 2016-05-19 19:42:33.365580781 -0500 @@ -433,11 +433,7 @@ sb = &mt->mt_tls; } - if ( sb->sb_tls_do_init ) { - bindconf_tls_set( sb, msc->msc_ld ); - } else if ( sb->sb_tls_ctx ) { - ldap_set_option( msc->msc_ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); - } + bindconf_tls_set( sb, msc->msc_ld ); if ( !is_ldaps ) { if ( sb == &mt->mt_idassert.si_bc && sb->sb_tls_ctx ) { diff -ru servers/slapd.orig/back-asyncmeta/conn.c servers/slapd/back-asyncmeta/conn.c --- servers/slapd.orig/back-asyncmeta/conn.c 2016-05-16 16:49:07.000000000 -0500 +++ servers/slapd/back-asyncmeta/conn.c 2016-05-19 19:43:24.164354246 -0500 @@ -277,11 +277,7 @@ sb = &mt->mt_tls; } - if ( sb->sb_tls_do_init ) { - bindconf_tls_set( sb, msc->msc_ld ); - } else if ( sb->sb_tls_ctx ) { - ldap_set_option( msc->msc_ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); - } + bindconf_tls_set( sb, msc->msc_ld ); if ( !is_ldaps ) { if ( sb == &mt->mt_idassert.si_bc && sb->sb_tls_ctx ) { -------- END OF PATCH
The root cause of the problem: On syncrepl retry, code in slap_client_connect (servers/slapd/config.c) initialized ld (LDAP) object with default values, rather than values saved in sb (slap_bindconf). This was because sb->sb_tls_do_init was true and bindconf_tls_set(sb, ld) was not called. This issue is not related to any specific TLS library. All syncrepl retries are executed with wrong TLS settings in ld->ld_options, including ldo_tls_require_cert, ldo_tls_keyfile, ldo_tls_certfile, ldo_tls_cacertfile, and other (ldo_tls_require_cert has default value 2 (demand), while string fields have nulls). However, the bug is usually masked, because sb->sb_tls_ctx contains TLS context correctly initialized during initial connection attempt, and this context is assigned to ld as LDAP_OPT_X_TLS_CTX, and then used by the TLS library, while incorrect values in ld->ld_options are ignored in most places. But the host-checking code in ldap_int_tls_start (libraries/libldap/tls2.c) uses ld->ld_options and triggers the bug. Explanation of the patch: The patch modifies function bindconf_tls_set that copies values from slap_bindconf to LDAP object. Code that calls bindconf_tls_set is also modified. 1. If slap_bindconf object has TLS context, assign it to LDAP object. 2. if slap_bindconf does not have a TLS context, create new context and assign it it to both slap_bindconf and LDAP objects. 3. Removed context replacement functionality and related conditions (newctx). The intent of this functionality was unclear, but did not appear to be compatible with how binconf_tls_set was used. 4. The result of the above code changes is that TLS context is always present and correctly assigned, while previously it sometimes was, and sometimes wasn't. 5. Simplified calls of bindconf_tls_set in the following files: servers/slapd/config.c servers/slapd/back-ldap/bind.c servers/slapd/back-meta/conn.c servers/slapd/back-asyncmeta/conn.c Things to do: I tested the modified slap_client_connect (servers/slapd/config.c), but the modifications to files in back-{ldap,meta,asyncmeta} were done without proper code and functionality analysis, and without any testing. I am hoping for a review from someone knowledgeable. Thank you
mkp37215@gmail.com wrote: > The root cause of the problem: Thanks for the analysis, will look into it soon. > On syncrepl retry, code in slap_client_connect > (servers/slapd/config.c) initialized ld (LDAP) object with default > values, rather than values saved in sb (slap_bindconf). This was > because sb->sb_tls_do_init was true and bindconf_tls_set(sb, ld) was > not called. > This issue is not related to any specific TLS library. All syncrepl > retries are executed with wrong TLS settings in ld->ld_options, > including ldo_tls_require_cert, ldo_tls_keyfile, ldo_tls_certfile, > ldo_tls_cacertfile, and other (ldo_tls_require_cert has default value > 2 (demand), while string fields have nulls). However, the bug is > usually masked, because sb->sb_tls_ctx contains TLS context correctly > initialized during initial connection attempt, and this context is > assigned to ld as LDAP_OPT_X_TLS_CTX, and then used by the TLS > library, while incorrect values in ld->ld_options are ignored in most > places. But the host-checking code in ldap_int_tls_start > (libraries/libldap/tls2.c) uses ld->ld_options and triggers the bug. That description makes sense, OK. > Explanation of the patch: > The patch modifies function bindconf_tls_set that copies values from > slap_bindconf to LDAP object. Code that calls bindconf_tls_set is also > modified. > 1. If slap_bindconf object has TLS context, assign it to LDAP object. > 2. if slap_bindconf does not have a TLS context, create new context > and assign it it to both slap_bindconf and LDAP objects. > 3. Removed context replacement functionality and related conditions > (newctx). The intent of this functionality was unclear, but did not > appear to be compatible with how binconf_tls_set was used. > 4. The result of the above code changes is that TLS context is always > present and correctly assigned, while previously it sometimes was, and > sometimes wasn't. > 5. Simplified calls of bindconf_tls_set in the following files: > servers/slapd/config.c > servers/slapd/back-ldap/bind.c > servers/slapd/back-meta/conn.c > servers/slapd/back-asyncmeta/conn.c > > Things to do: > I tested the modified slap_client_connect (servers/slapd/config.c), > but the modifications to files in back-{ldap,meta,asyncmeta} were done > without proper code and functionality analysis, and without any > testing. I am hoping for a review from someone knowledgeable. > > Thank you > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard, thanks for the reply. I just noticed a small error in what I wrote, the corrected fragment should be: "This was because sb->sb_tls_do_init was FALSE and bindconf_tls_set(sb, ld) was not called." I also would like to add that my patch changes the semantics of bindconf_tls_set, in regard of how TLS context is set, and that this is deliberate. I think that previous semantics was unclear and bug-prone, and that the new one is not only more straightforward, but also matches better the way bindconf_tls_set is used. As a result both bindconf_tls_set code and the code around its invocations is simplified. However, I was focused on its usage in slap_client_connect (because this is what was causing me problems), and I did not put much attention into other three places where bindconf_tls_set is called. All of those code fragments were basically identical, so I modified them the same way, but I think someone should review these modifications to see if they make sense. I originally intended to limit the impact of my patch to slap_client_connect, and to keep the changes inside config.c file. However, this resulted in making bad code worse, even less clear and manageable.
Since more than four months have passed since last message here, I would like to ask if any progress has been made in this matter? Has anyone looked into my patch? Thank you
changed notes moved from Incoming to Software Bugs
changed notes
--On Wednesday, October 05, 2016 7:25 PM +0000 mkp37215@gmail.com wrote: > Since more than four months have passed since last message here, I > would like to ask if any progress has been made in this matter? Has > anyone looked into my patch? Hi, I'm working on incorporating submissions in the ITS system. This report is missing an IPR which is required for it to be included in the project. Please see <http://www.openldap.org/devel/contributing.html> and update this ITS with your IPR when possible. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
I, Maciej Puzio, hereby place the above modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.
changed notes changed state Open to Release
On Fri, Dec 01, 2017 at 07:15:08PM +0000, mkp37215@gmail.com wrote: > I, Maciej Puzio, hereby place the above modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. Hi Maciej, thank you for your work, patches have been pushed to master and will also be part of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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" Regards
--On Thursday, June 27, 2019 9:08 PM +0000 a.chelouah@gmail.com wrote: > This is a multi-part message in MIME format. > --------------93F3FA89632EC27DC6224304 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 7bit > > 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:// Thanks for the follow up! It may be useful in the future to participate in the testing calls that are noted on the openldap-devel list as well. Does the issue persist if you set: olcDbStartTLS: ldaps as documented in the slapd-ldap(5) man page? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
--On Thursday, June 27, 2019 11:51 PM +0200 Abdelkader Chelouah <a.chelouah@gmail.com> wrote: > > I tried with with > > > olcDbStartTLS: ldaps > > > with no success. > > > Logs on the proxy > > > 2019-06-27T20:46:07.602925+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 ACCEPT from IP=[::1]:46462 (IP=[::1]:10020) > 2019-06-27T20:46:07.603476+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 BIND dn="uid=alice,ou=people,dc=local" method=128 > 2019-06-27T20:46:07.609212+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 ldap_back_retry: retrying URI="ldaps://arrakis.local:10011" DN="" > 2019-06-27T20:46:07.613435+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 RESULT tag=97 err=52 text=Proxy operation retry failed > 2019-06-27T20:46:07.613968+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=1 UNBIND > 2019-06-27T20:46:07.614264+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 closed > > Logs on the backend ldap server > > > 2019-06-27T20:46:07.609971+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 ACCEPT from IP=172.18.0.2:47156 (IP=172.18.0.2:10011) > 2019-06-27T20:46:07.613718+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 closed (TLS negotiation failure) Thanks! Please include the openldap-its list in your replies so that they properly get associated with the relevant ITS. I'll raise this up as a priority for the 2.4.48 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Hello, Unfortunately this patch introduces a regression and breaks existing configurations where the protocol in use is ldaps:///. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Quanah, I can think of three reasons why the patch is causing problems: 1. The patch is three years old and was not validated against the current OpenLDAP version, to which it has been applied. Without additional testing, I am not even sure if the issue that the patch fixes still exists. 2. The patch was not tested in the proxy configuration. 3. The patch changes the way tls_reqcert parameter is handled. It is therefore possible that a setup with an incorrect TLS certificate would stop working. However, that is a general remark and the cause of Abdelkader Chelouah's problems may be entirely different. Unfortunately, I do not feel that I would be able to help with any further work on this patch. Due to the passage of time since this bug was reported, I would need to redo all the work from scratch (my test environment is long gone, and the limited understanding of OpenLDAP internals that I once had, has since faded from my memory). I do not believe that I can afford such an effort, particularly when I worry that the result could be shelved for years again. I would be grateful if others, who are more knowledgeable with OpenLDAP internals, look into this issue. Thank you very much Maciej Puzio
On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah@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
Le 09/07/2019 à 14:14, ondra@mistotebe.net a écrit : > On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah@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.
ondra@mistotebe.net wrote: > On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah@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/
On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc@symas.com wrote: > ondra@mistotebe.net wrote: >> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah@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
Ondřej Kuzník wrote: > On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc@symas.com wrote: >> ondra@mistotebe.net wrote: >>> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah@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. 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 issues. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Wed, Jul 10, 2019 at 07:02:48PM +0100, Howard Chu wrote: > Ondřej Kuzník wrote: >> On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc@symas.com wrote: >>> ondra@mistotebe.net wrote: >>>> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah@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. > > 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 issues. Had to have a look at the code, so this is what seems to happen and I think the code does what it should regardless of the ITS#8427 patch, see updated test at the same place: https://github.com/mistotebe/openldap/tree/its8427-regression There are three completely separate types of connections as reflected in the configuration: - acl connections ("private" in terms of the code), used for internal operations and anything issued by the rootdn - idassert connections, used when the client identity should be asserted over the other side (bindmethod setting applies or proxyauth is in effect through other means), also currently used for acl connections if acl is unconfigured - normal connections (configured with the tls keyword) All of this should default to the slapd's internal client TLS settings, not sure how exactly that works yet and whether it reflects later changes to the slapd's client settings. So if anything should be shared between all connections, the preferred way should be using global TLS* options if I understand correctly. If different settings need to apply to different ldap backends, they need to be copied over to each option (acl, idassert and tls) that's in effect. There was a slight issue with how late configuration of olcStartTLS might not take effect, that is also handled in the above branch (and master soon after both full make test and make its finish). -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Applied to master Needs revisiting
changed notes changed state Release to Open
We need to fix all the things that broke when this was applied to RE24 before we can release 2.5
Current code in master with this fix has also broken back-ldap when TLS was not requested - it is issuing a Start TLS request anyway, because bindconf_tls_set always initializes the sb_tls_ctx and when back-ldap ldap_back_prepare_conn sees a non-NULL sb_tls_ctx it tries to use it. The connection request then fails because the start_tls request fails. I'm currently seeing these errors in the slapd.1.log from test048.
Commits: • f883a575 by Howard Chu at 2020-08-28T18:44:35+01:00 ITS#8427 don't set tls_ctx if TLS wasn't requested Also, set any remaining TLS options that weren't carried along in the TLS ctx.
*** Issue 7330 has been marked as a duplicate of this issue. ***