Hi all,
In the view of the new openldap release, I ran some tests by using the current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree and based on my findings It seems that this build breaks the back_ldap backend when it is used with a remote ldaps:/// server.
In particular, the following snippet of proxy bind configuration, which works on the same system, with the same remote ldaps:/// server / certificate and the 2.4.47 release, fails with the engineering release of 2.4.48. The testing environment was a Debian (Stable/Buster) and Openldap was compiled with the Debian's gnu TLS libs. Based on my previous experience I would have bet that this is a GNU TLS issue, however this seems to be a different case considering that the error happens only with the switch from the 2.4.47 to 2.4.48. Could this be another side effect of the related to ITS#8427 fixes?
dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {2}back_ldap olcModuleLoad: rwm
dn: olcOverlay={0}rwm,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm olcRwmRewrite: rwm-rewriteEngine "on" olcRwmRewrite: rwm-rewriteContext "bindDN" olcRwmRewrite: rwm-rewriteRule "^academicID=([^,]+),ou=People,dc=acme" "academicID=$1,cn=authn" ":@I"
dn: olcDatabase={3}ldap,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {3}ldap olcAccess: to * by * manage olcSuffix: cn=authn olcRootDN: cn=admin,cn=authn olcRootPW: {SSHA}<REMOVED> olcDbURI: ldaps://remote-authn.acme.foo:636
dn: olcOverlay={0}rwm,olcDatabase={3}ldap,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm olcRwmRewrite: rwm-rewriteEngine "on" olcRwmRewrite: rwm-rewriteContext "bindDN" olcRwmRewrite: rwm-rewriteRule "^academicID=([^,]+),cn=authn" "academicID=$1,ou=People,dc=acme" ":@I"
The debug output shows the following:
5d32a159 <<< dnPrettyNormal: <academicID=E2Q4KXGLNSPLB25T8TLLT5,ou=People,dc=acme>, <academicID=e2q4kxglnsplb25t8tllt5,ou=people,dc=acme> ldap_create ldap_url_parse_ext(ldaps://remote-authn.acme.foo:636) 5d32a159 =>ldap_back_getconn: conn=1000 op=0: lc=0x7f10ac12abc0 inserted refcnt=1 rc=0 ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP remote-authn.acme.foo:636 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying <IP of remote-authn.acme.foo>:636 ldap_pvt_connect: fd: 16 tm: -1 async: 0 attempting to connect: connect success tls_write: want=337, written=337 0000: 16 03 01 01 4c 01 00 01 48 03 03 57 00 4d a5 80 ....L...H..W.M.. 0010: d4 4b 71 8e 08 62 4f 7a b6 a9 4f 20 cd e3 04 9b .Kq..bOz..O .... 0020: 04 91 54 e8 78 9d 20 44 cd bd b3 00 00 3a 13 02 ..T.x. D.....:.. 0030: 13 03 13 01 13 04 c0 2c cc a9 c0 ad c0 0a c0 2b .......,.......+
.... ....
TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). 5d32a169 send_ldap_result: conn=1000 op=0 p=3 5d32a169 send_ldap_result: err=52 matched="" text="Proxy operation retry failed" 5d32a169 send_ldap_response: msgid=1 tag=97 err=52
Best Regards, Nikos
On 7/20/19 8:25 AM, Nikos Voutsinas wrote:
In the view of the new openldap release, I ran some tests by using the current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree
Which snapshot? Really the latest 407ce9d prepared for release and with latest mdb merge?
and based on my findings It seems that this build breaks the back_ldap backend when it is used with a remote ldaps:/// server.
I have a similar config working just fine with git snapshot 407ce9d. But I'm running this on openSUSE Tumbleweed with OpenLDAP linked against OpenSSL.
The testing environment was a Debian (Stable/Buster) and Openldap was compiled with the Debian's gnu TLS libs.
Could you try to link with OpenSSL and test that to preclude that it's an issue with GnuTLS?
TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code).
Could you try with gnutls-cli to check whether TLS just works?
Ciao, Michael.
On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder michael@stroeder.com wrote:
On 7/20/19 8:25 AM, Nikos Voutsinas wrote:
In the view of the new openldap release, I ran some tests by using the current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree
Which snapshot? Really the latest 407ce9d prepared for release and with latest mdb merge?
Yeap the one tagged for 2.4.48
and based on my findings It seems that this build breaks the back_ldap backend when it is used with a remote ldaps:/// server.
I have a similar config working just fine with git snapshot 407ce9d. But I'm running this on openSUSE Tumbleweed with OpenLDAP linked against OpenSSL.
Interesting ....
The testing environment was a Debian (Stable/Buster) and Openldap was compiled with the Debian's gnu TLS libs.
Could you try to link with OpenSSL and test that to preclude that it's an issue with GnuTLS?
Whenever it was a gnutls library issue, even the plain ldapsearch -H ldaps:// had problems. Now this is not the case, cmd line utils from the same build at the same remote ldaps:/// work.
TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code).
Could you try with gnutls-cli to check whether TLS just works?
gnutls-cli completes the handshake with out problem. It sees one perfect chain, and can successfully verify the remote server's cetrs (otherwise openldap client utils wouldn't have worked too).
Ciao, Michael.
On 7/20/19 10:51 AM, Nikos Voutsinas wrote:
On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote: On 7/20/19 8:25 AM, Nikos Voutsinas wrote: > In the view of the new openldap release, I ran some tests by using the > current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree Which snapshot? Really the latest 407ce9d prepared for release and with latest mdb merge? Yeap the one tagged for 2.4.48
Ok.
> The testing environment was a Debian (Stable/Buster) and > Openldap was compiled with the Debian's gnu TLS libs. Could you try to link with OpenSSL and test that to preclude that it's an issue with GnuTLS?Whenever it was a gnutls library issue, even the plain ldapsearch -H ldaps:// had problems. Now this is not the case, cmd line utils from the same build at the same remote ldaps:/// work.
There are changes in libldap and slapd-ldap related to TLS which might not work correctly with GnuTLS.
So could you try to first link with OpenSSL? If that works it would mean that the GnuTLS support needs some more work.
BTW: During the last days Quanah and me investigated an issue with a (now reverted) patch for libldap only occuring with dhcpd using libldap. ldapsearch and many other LDAP clients were working just fine.
Ciao, Michael.
On Sat, 20 Jul 2019 at 13:00, Michael Ströder michael@stroeder.com wrote:
On 7/20/19 10:51 AM, Nikos Voutsinas wrote:
On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote: On 7/20/19 8:25 AM, Nikos Voutsinas wrote: > In the view of the new openldap release, I ran some tests by using
the
> current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree Which snapshot? Really the latest 407ce9d prepared for release andwith
latest mdb merge?Yeap the one tagged for 2.4.48
Ok.
> The testing environment was a Debian (Stable/Buster) and > Openldap was compiled with the Debian's gnu TLS libs. Could you try to link with OpenSSL and test that to preclude thatit's
an issue with GnuTLS?Whenever it was a gnutls library issue, even the plain ldapsearch -H ldaps:// had problems. Now this is not the case, cmd line utils from the same build at the same remote ldaps:/// work.
There are changes in libldap and slapd-ldap related to TLS which might not work correctly with GnuTLS.
So could you try to first link with OpenSSL? If that works it would mean that the GnuTLS support needs some more work.
Ok that can be done, although I am pretty sure that it will work with OpenSSL since you have already tested a similar setup on openSUSE.
The idea here is to first confirm with others the problem and then early identify the change set that triggers this before the announcement of the release
What worries me is that the exact config options and gnutls libs with the 2.4.47 source works as expected, thus we can not blame GNUTLS for that, despite any arguments one may have against GNUTLS.
BTW: During the last days Quanah and me investigated an issue with a (now reverted) patch for libldap only occuring with dhcpd using libldap. ldapsearch and many other LDAP clients were working just fine.
Ciao, Michael.
On 7/20/19 1:31 PM, Nikos Voutsinas wrote:
Ok that can be done, although I am pretty sure that it will work with OpenSSL since you have already tested a similar setup on openSUSE.
The idea here is to first confirm with others the problem and then early identify the change set that triggers this before the announcement of the release
What worries me is that the exact config options and gnutls libs with the 2.4.47 source works as expected, thus we can not blame GNUTLS for that, despite any arguments one may have against GNUTLS.
Let's not speculate about whatever might be the cause or not.
Just start testing. Take care not to mess up builds and test results (like I did sometimes during the last days).
Ciao, Michael.
On 7/20/19 3:41 PM, Michael Ströder wrote:
On 7/20/19 1:31 PM, Nikos Voutsinas wrote:
Ok that can be done, although I am pretty sure that it will work with OpenSSL since you have already tested a similar setup on openSUSE.
The idea here is to first confirm with others the problem and then early identify the change set that triggers this before the announcement of the release
What worries me is that the exact config options and gnutls libs with the 2.4.47 source works as expected, thus we can not blame GNUTLS for that, despite any arguments one may have against GNUTLS.
Let's not speculate about whatever might be the cause or not.
Just start testing. Take care not to mess up builds and test results (like I did sometimes during the last days).
BTW: Are your 2.4.47 and 2.4.48 builds are done exactly the same way?
Ciao, Michael.
On Sat, 20 Jul 2019 at 16:46, Michael Ströder michael@stroeder.com wrote:
On 7/20/19 3:41 PM, Michael Ströder wrote:
On 7/20/19 1:31 PM, Nikos Voutsinas wrote:
Ok that can be done, although I am pretty sure that it will work with OpenSSL since you have already tested a similar setup on openSUSE.
The idea here is to first confirm with others the problem and then early identify the change set that triggers this before the announcement of the release
What worries me is that the exact config options and gnutls libs with the 2.4.47 source works as expected, thus we can not blame GNUTLS for that, despite any arguments one may have against GNUTLS.
Let's not speculate about whatever might be the cause or not.
Just start testing. Take care not to mess up builds and test results (like I did sometimes during the last days).
BTW: Are your 2.4.47 and 2.4.48 builds are done exactly the same way?
The Debian based yes.
On Sat, Jul 20, 2019 at 4:46 PM Michael Ströder michael@stroeder.com wrote:
On 7/20/19 3:41 PM, Michael Ströder wrote:
On 7/20/19 1:31 PM, Nikos Voutsinas wrote:
Ok that can be done, although I am pretty sure that it will work with OpenSSL since you have already tested a similar setup on openSUSE.
The idea here is to first confirm with others the problem and then early identify the change set that triggers this before the announcement of the release
What worries me is that the exact config options and gnutls libs with the 2.4.47 source works as expected, thus we can not blame GNUTLS for that, despite any arguments one may have against GNUTLS.
Let's not speculate about whatever might be the cause or not.
Just start testing. Take care not to mess up builds and test results (like I did sometimes during the last days).
BTW: Are your 2.4.47 and 2.4.48 builds are done exactly the same way?
OPENLDAP_REL_ENG_2_4_48 with OpenSSL-1.1.1c (on Debian / Buster) works OPENLDAP_REL_ENG_2_4_48 with GNUTLS-3.6.7 (on Debian / Buster) doesn't work(*) OPENLDAP_REL_END_2_4_48 also works on Solaris with openssl
OPENLDAP 2.4.47 Debian's official package with GNUTLS-3.6.7 also works
(*) I also tried to pass the trusted CAs via olcTLSCACertificateFile in cn=config after Ondřej's comment, with the same result.
In any case the heads up on the devel list was mostly to identify a possible issue at the openldap side before the release. If it turns out to be a Debian specific issue, then I assume that the Debian's Openldap Maintainers will take of it.
Nikos
On Sat, Jul 20, 2019 at 09:25:17AM +0300, Nikos Voutsinas wrote:
Hi all,
In the view of the new openldap release, I ran some tests by using the current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree and based on my findings It seems that this build breaks the back_ldap backend when it is used with a remote ldaps:/// server.
In particular, the following snippet of proxy bind configuration, which works on the same system, with the same remote ldaps:/// server / certificate and the 2.4.47 release, fails with the engineering release of 2.4.48. The testing environment was a Debian (Stable/Buster) and Openldap was compiled with the Debian's gnu TLS libs. Based on my previous experience I would have bet that this is a GNU TLS issue, however this seems to be a different case considering that the error happens only with the switch from the 2.4.47 to 2.4.48. Could this be another side effect of the related to ITS#8427 fixes?
dn: olcDatabase={3}ldap,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {3}ldap olcAccess: to * by * manage olcSuffix: cn=authn olcRootDN: cn=admin,cn=authn olcRootPW: {SSHA}<REMOVED> olcDbURI: ldaps://remote-authn.acme.foo:636
The debug output shows the following:
TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code).
Hi Nikos, where/how do you set the CA certificates that slapd should trust?
Thanks,
On Sat, 20 Jul 2019 at 14:42, Ondřej Kuzník ondra@mistotebe.net wrote:
On Sat, Jul 20, 2019 at 09:25:17AM +0300, Nikos Voutsinas wrote:
Hi all,
In the view of the new openldap release, I ran some tests by using the current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree and based on my findings It seems that this build breaks the back_ldap backend when it is used with a remote ldaps:/// server.
In particular, the following snippet of proxy bind configuration, which works on the same system, with the same remote ldaps:/// server / certificate and the 2.4.47 release, fails with the engineering release of 2.4.48. The testing environment was a Debian (Stable/Buster) and Openldap was compiled with the Debian's gnu TLS libs. Based on my previous experience I would have bet that this is a GNU TLS issue, however this seems to be a different case considering that the error happens only with the switch from the 2.4.47 to 2.4.48. Could this be another side effect
of
the related to ITS#8427 fixes?
dn: olcDatabase={3}ldap,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {3}ldap olcAccess: to * by * manage olcSuffix: cn=authn olcRootDN: cn=admin,cn=authn olcRootPW: {SSHA}<REMOVED> olcDbURI: ldaps://remote-authn.acme.foo:636
The debug output shows the following:
TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code).
Hi Nikos, where/how do you set the CA certificates that slapd should trust?
Hi Ondřej,
I am using the ldap.conf TLS params to provide the path to CAs. That’s the default way for Debian. It works with 2.4.47, it also works for the 2.4.48 openldap client utils) as I mentioned earlier.
btw I just checked a similar setup on Solaris with OpenSSL (it was easier for me) and yeap ..... it works also there.
--On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas nvoutsin@gmail.com wrote:
I am using the ldap.conf TLS params to provide the path to CAs. That's the default way for Debian. It works with 2.4.47, it also works for the 2.4.48 openldap client utils) as I mentioned earlier.
ldap.conf is only for client utilities. This is clearly described in the ldap.conf(5) man page. This sounds more to me like we've closed a bug with the GnuTLS implementation. From ldap.conf(5):
The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Sat, Jul 20, 2019 at 09:40:53AM -0700, Quanah Gibson-Mount wrote:
--On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas nvoutsin@gmail.com wrote:
I am using the ldap.conf TLS params to provide the path to CAs. That's the default way for Debian. It works with 2.4.47, it also works for the 2.4.48 openldap client utils) as I mentioned earlier.
ldap.conf is only for client utilities. This is clearly described in the ldap.conf(5) man page. This sounds more to me like we've closed a bug with the GnuTLS implementation.
This does appear to be what's happened. I confirm that in 2.4.47, back_ldap does pick up the TLS_CACERT setting from ldap.conf, while in 2.4.48 it does not.
For the record, this is not specific to GnuTLS. I observe the same difference with OpenSSL.
6f623df (ITS#8427) is the commit that changed it, as expected. As I understand it, the new behaviour is what's intended, although configs might need updates per Ondrej's last message on the ITS (duplicating the TLS settings for different connection types).
Even if it's considered a bugfix, it might be worth calling out in the release notes? Just for the sake of reducing support noise if people are unintentionally depending on the old behaviour...
Is there a global place in slapd where one can configure things like CA cert and have it defaulted into all TLS clients? I'm not aware of one, yet it seems like an obvious thing to provide...
Ryan Tandy wrote:
On Sat, Jul 20, 2019 at 09:40:53AM -0700, Quanah Gibson-Mount wrote:
--On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas nvoutsin@gmail.com wrote:
I am using the ldap.conf TLS params to provide the path to CAs. That's the default way for Debian. It works with 2.4.47, it also works for the 2.4.48 openldap client utils) as I mentioned earlier.
ldap.conf is only for client utilities. This is clearly described in the ldap.conf(5) man page. This sounds more to me like we've closed a bug with the GnuTLS implementation.
This does appear to be what's happened. I confirm that in 2.4.47, back_ldap does pick up the TLS_CACERT setting from ldap.conf, while in 2.4.48 it does not.
For the record, this is not specific to GnuTLS. I observe the same difference with OpenSSL.
6f623df (ITS#8427) is the commit that changed it, as expected. As I understand it, the new behaviour is what's intended, although configs might need updates per Ondrej's last message on the ITS (duplicating the TLS settings for different connection types).
Even if it's considered a bugfix, it might be worth calling out in the release notes? Just for the sake of reducing support noise if people are unintentionally depending on the old behaviour...
Is there a global place in slapd where one can configure things like CA cert and have it defaulted into all TLS clients? I'm not aware of one, yet it seems like an obvious thing to provide...
As documented in slapd-ldap(5)
The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand".
If that no longer works, then we have yet another regression.
--On Saturday, July 20, 2019 8:43 PM +0100 Howard Chu hyc@symas.com wrote:
As documented in slapd-ldap(5)
The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand".If that no longer works, then we have yet another regression.
I guess the underlying question is, if they aren't in slapd.conf, where do slapd clients (syncrepl, back-ldap, etc) get them from? For example, syncrepl is clearly designed to get at least one setting from ldap.conf:
The network-timeout parameter sets how long the consumer will wait to establish a network connection to the provider. Once a connection is established, the timeout parameter determines how long the consumer will wait for the initial Bind request to complete. The defaults for these parameters come from ldap.conf(5).
So is it supposed to be that the configuration levels are:
slapd client (syncrepl, back-ldap specific parameters) override slapd configuration (slapd.conf(5), slapd-config(5) parameters)
Or is it supposed to be:
slapd client (syncrepl, back-ldap specific parameters) override slapd configuration (slapd.conf(5), slapd-config(5) parameters) override ldap.conf(5)
If it's the former, then syncrepl should not pull anything from ldap.conf. If it's the latter, then we have a clear regression.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Saturday, July 20, 2019 8:43 PM +0100 Howard Chu hyc@symas.com wrote:
As documented in slapd-ldap(5)
The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand".
If that no longer works, then we have yet another regression.
I guess the underlying question is, if they aren't in slapd.conf, where do slapd clients (syncrepl, back-ldap, etc) get them from? For example, syncrepl is clearly designed to get at least one setting from ldap.conf:
The network-timeout parameter sets how long the consumer will wait to establish a network connection to the provider. Once a connection is established, the timeout parameter determines how long the consumer will wait for the initial Bind request to complete. The defaults for these parameters come from ldap.conf(5).
So is it supposed to be that the configuration levels are:
slapd client (syncrepl, back-ldap specific parameters) override slapd configuration (slapd.conf(5), slapd-config(5) parameters)
Or is it supposed to be:
slapd client (syncrepl, back-ldap specific parameters) override slapd configuration (slapd.conf(5), slapd-config(5) parameters) override ldap.conf(5)
If it's the former, then syncrepl should not pull anything from ldap.conf. If it's the latter, then we have a clear regression.
The behavior is supposed to be exactly as specified in the manpages.
There is no reason to expect back-ldap and syncrepl to be exactly alike; they perform different functions.
--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu hyc@symas.com wrote:
The behavior is supposed to be exactly as specified in the manpages.
There is no reason to expect back-ldap and syncrepl to be exactly alike; they perform different functions.
You missed the point. It wasn't about syncrepl vs back-ldap, it was about whether or not *anything* used in slapd should ever pull in data from ldap.conf. The *only* thing I can find that pulls in anything from ldap.conf (per the man pages) is syncrepl. Which seems rather odd, particularly since it's only for one specific value. Especially given that ldap.conf(5) specifies it is only for ldap clients.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 7/21/19 4:32 AM, Quanah Gibson-Mount wrote:
You missed the point. It wasn't about syncrepl vs back-ldap, it was about whether or not *anything* used in slapd should ever pull in data from ldap.conf.
From my understanding up to now ldap.conf was used in back-ldap and people make use of it. Aside from whether this was a doc or implementation bug you should seriously consider whether it's worth the trouble to change back-ldap's behaviour within 2.4.x release series.
Personally I'm in the camp of explicitly specifying (possibly different) trust anchors for every aspect. Especially since we all should use a decent config management today it's really easy. So I'd like to propose a change for 2.5.x that nothing within slapd uses ldap.conf (LDAPNOINIT=1 for all of slapd's internal stuff).
Also I don't want to use system-wide trust stores by default without explicitly being configured. But that's another issue.
Ciao, Michael.
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu hyc@symas.com wrote:
The behavior is supposed to be exactly as specified in the manpages.
There is no reason to expect back-ldap and syncrepl to be exactly alike; they perform different functions.
You missed the point. It wasn't about syncrepl vs back-ldap, it was about whether or not *anything* used in slapd should ever pull in data from ldap.conf. The *only* thing I can find that pulls in anything from ldap.conf (per the man pages) is syncrepl. Which seems rather odd, particularly since it's only for one specific value. Especially given that ldap.conf(5) specifies it is only for ldap clients.
A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP client.
On 7/21/19 3:37 PM, Howard Chu wrote:
A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP client.
Yes, of course.
But both behaved differently regarding usage of ldap.conf before 6f623df (ITS#8427).
Quanah's question is: Is it generally required that all slapd-internal LDAP clients must behave the same?
This would also answer: Revert patch 6f623df for ITS#8427 because it's considered a regression?
Ciao, Michael.
--On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu hyc@symas.com wrote:
--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu hyc@symas.com wrote:
The behavior is supposed to be exactly as specified in the manpages.
A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP client.
Now you are providing conflicting answers. The man page for back-ldap makes zero reference to ldap.conf(5). It only mentions slapd.conf(5). The syncrepl section of slapd.conf(5)/slapd-config(5) only mention the network-timeout value being pulled in from ldap.conf(5). So which is it? Do they follow the man page behaviors (which would mean no ldap.conf(5) for slapd-ldap, and only network-timeout for syncrepl), or do they violate the man page description?
Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and possibly other paremters) if they are not found in slapd.conf(5).
Additionaly, what should we do about ITS#8427? It was clearly fixing a valid bug. Do we revert it? Do we fix the behavior so it fixes the bug reported, but does not introduce a regression?
And we need to know the answer to that and have a fix in rather quickly.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote:
Now you are providing conflicting answers. The man page for back-ldap makes zero reference to ldap.conf(5). It only mentions slapd.conf(5). The syncrepl section of slapd.conf(5)/slapd-config(5) only mention the network-timeout value being pulled in from ldap.conf(5). So which is it? Do they follow the man page behaviors (which would mean no ldap.conf(5) for slapd-ldap, and only network-timeout for syncrepl), or do they violate the man page description?
(replying to the gist of the entire thread)
I'm happy with back-ldap, etc. honouring global ldap.conf. Deployments that need to avoid that can and should define LDAPNOINIT. Also AFAIK libldap initialisation happens before any configuration is even parsed so might be a bit harder to avoid it.
Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and possibly other paremters) if they are not found in slapd.conf(5).
We should document what happens somewhere, definitely. Maybe TLS section of slapd.conf manpage? I'll defer to you where that should happen and hopefully either of also you wants to write it (and the LDAPNOINIT advice) while I work on fixing this :) I'll just tweak things later so the docs fit exactly what happens when it comes to setting up slapd_tls_ld and what the relevant clients (syncrepl and back-ldap) do too.
Additionaly, what should we do about ITS#8427? It was clearly fixing a valid bug. Do we revert it? Do we fix the behavior so it fixes the bug reported, but does not introduce a regression?
And we need to know the answer to that and have a fix in rather quickly.
I'll see tomorrow about reproducing the regression with ldap.conf. If I'm successful, extending the test case and a fix should not take long.
Thanks,
--On Sunday, July 21, 2019 10:54 PM +0200 Ondřej Kuzník ondra@mistotebe.net wrote:
On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote:
Now you are providing conflicting answers. The man page for back-ldap makes zero reference to ldap.conf(5). It only mentions slapd.conf(5). The syncrepl section of slapd.conf(5)/slapd-config(5) only mention the network-timeout value being pulled in from ldap.conf(5). So which is it? Do they follow the man page behaviors (which would mean no ldap.conf(5) for slapd-ldap, and only network-timeout for syncrepl), or do they violate the man page description?
(replying to the gist of the entire thread)
I'm happy with back-ldap, etc. honouring global ldap.conf. Deployments that need to avoid that can and should define LDAPNOINIT. Also AFAIK libldap initialisation happens before any configuration is even parsed so might be a bit harder to avoid it.
Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and possibly other paremters) if they are not found in slapd.conf(5).
We should document what happens somewhere, definitely. Maybe TLS section of slapd.conf manpage? I'll defer to you where that should happen and hopefully either of also you wants to write it (and the LDAPNOINIT advice) while I work on fixing this :) I'll just tweak things later so the docs fit exactly what happens when it comes to setting up slapd_tls_ld and what the relevant clients (syncrepl and back-ldap) do too.
After further discussion with Howard, ITS#8427 is going to get reverted from RE24 for now, and we'll look at getting it fixed fully for 2.4.49. It appears it has introduced a regression with both GnuTLS and OpenSSL. Long term, we need to decide exactly how we want this all to work in RE25 as well. I'm with Michael in that I think slapd should never accept any CAs unless explicitly configured to do so, and right now it appears that without this patch, it can do exactly that with both OpenSSL and GnuTLS, regardless of whether or not an ldap.conf file is in place.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu hyc@symas.com wrote:
--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu hyc@symas.com wrote:
The behavior is supposed to be exactly as specified in the manpages.
A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP client.
Now you are providing conflicting answers. The man page for back-ldap makes zero reference to ldap.conf(5). It only mentions slapd.conf(5). The syncrepl section of slapd.conf(5)/slapd-config(5) only mention the network-timeout value being pulled in from ldap.conf(5). So which is it? Do they follow the man page behaviors (which would mean no ldap.conf(5) for slapd-ldap, and only network-timeout for syncrepl), or do they violate the man page description?
As I already said: there is no reason for the syncrepl consumer and back-ldap to behave identically. The manpages are correct in each case.
Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and possibly other paremters) if they are not found in slapd.conf(5).
Additionaly, what should we do about ITS#8427? It was clearly fixing a valid bug. Do we revert it? Do we fix the behavior so it fixes the bug reported, but does not introduce a regression?
It sounds like the behavior with OpenSSL is currently correct, and currently broken on GnuTLS.
And we need to know the answer to that and have a fix in rather quickly.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu hyc@symas.com wrote:
As I already said: there is no reason for the syncrepl consumer and back-ldap to behave identically. The manpages are correct in each case.
I've never said they should behave identically, and I do not fathom why you are so focussed on something I never stated.
*You* stated:
"The behavior is supposed to be exactly as specified in the manpages."
The *man page* for back-ldap makes ZERO reference to ldap.conf. It makes ZERO reference to back-ldap being considered an "ldap client". If your statement that they should behave as specified in the man pages is true, then its behavior is incorrect, because PER THE MAN PAGE the TLS settings are either EXPLICIT in the back-ldap configuration OR they are taking from slapd's TLS settings. NOWHERE does it say that if there are no settings in back-ldap OR slapd that it will THEN take the settings from ldap.conf.
The *exact same* applies to syncrepl and its TLS settings.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu hyc@symas.com wrote:
As I already said: there is no reason for the syncrepl consumer and back-ldap to behave identically. The manpages are correct in each case.
I've never said they should behave identically, and I do not fathom why you are so focussed on something I never stated.
*You* stated:
"The behavior is supposed to be exactly as specified in the manpages."
The *man page* for back-ldap makes ZERO reference to ldap.conf. It makes ZERO reference to back-ldap being considered an "ldap client". If your statement that they should behave as specified in the man pages is true, then its behavior is incorrect, because PER THE MAN PAGE the TLS settings are either EXPLICIT in the back-ldap configuration OR they are taking from slapd's TLS settings. NOWHERE does it say that if there are no settings in back-ldap OR slapd that it will THEN take the settings from ldap.conf.
The *exact same* applies to syncrepl and its TLS settings.
You claimed it was inconsistent because syncrepl refers to ldap.conf for network timeout settings while back-ldap makes no reference to ldap.conf.
Clearly there is no requirement for syncrepl and back-ldap to behave identically here.
For the TLS settings, as already noted, libldap always reads ldap.conf unless you set the NOINIT env var. All of the slapd TLS settings are set in a TLS context that is retrieved from an LDAP* handle created specifically for this purpose. Naturally this handle inherits whatever defaults libldap picks up. Even so, you are expected to completely configure TLS settings in slapd's configuration, and not rely on any other defaults.
Feel free to add a note to slapd.conf(5) / slapd-config(5) about TLS defaults.
--On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu hyc@symas.com wrote:
You claimed it was inconsistent because syncrepl refers to ldap.conf for network timeout settings while back-ldap makes no reference to ldap.conf.
No, if you read my email, I was purely noting that again that the man pages make no reference to ldap.conf(5) *outside* of syncrepl's explicit statement about network-timeout. Going back to your statement that the behavior should conform to the man pages for back-ldap and syncrepl.
Feel free to add a note to slapd.conf(5) / slapd-config(5) about TLS defaults.
I think that's worth doing.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu hyc@symas.com wrote:
Feel free to add a note to slapd.conf(5) / slapd-config(5) about TLS defaults.
I take this back. Pretty sure we've had this debate before, haven't found it in the list archive.
We explicitly create a fresh TLS context in slapd, to eliminate any ldap.conf initialization defaults.
I think that's worth doing.
--On Sunday, July 21, 2019 11:16 PM +0100 Howard Chu hyc@symas.com wrote:
I take this back. Pretty sure we've had this debate before, haven't found it in the list archive.
We explicitly create a fresh TLS context in slapd, to eliminate any ldap.conf initialization defaults.
Ok, so it's GnuTLS that had broken behavior and it was fixed by ITS#8427.
You also noted in IRC that you found the related ITS: https://www.openldap.org/its/index.cgi/?findid=3109
So GnuTLS actually introduced a regression in behavior.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote:
Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and possibly other paremters) if they are not found in slapd.conf(5).
For syncrepl at least I understood it was intentional that ldap.conf is ignored (since 1cc1f9b). No idea about back-ldap; personally I always assumed they were supposed to behave the same.
On Sat, Jul 20, 2019 at 9:31 PM Ryan Tandy ryan@nardis.ca wrote:
On Sat, Jul 20, 2019 at 09:40:53AM -0700, Quanah Gibson-Mount wrote:
--On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas nvoutsin@gmail.com wrote:
I am using the ldap.conf TLS params to provide the path to CAs. That's the default way for Debian. It works with 2.4.47, it also works for the 2.4.48 openldap client utils) as I mentioned earlier.
ldap.conf is only for client utilities. This is clearly described in the ldap.conf(5) man page. This sounds more to me like we've closed a bug with the GnuTLS implementation.
This does appear to be what's happened. I confirm that in 2.4.47, back_ldap does pick up the TLS_CACERT setting from ldap.conf, while in 2.4.48 it does not.
For the record, this is not specific to GnuTLS. I observe the same difference with OpenSSL.
Weird... My build of OPENLDAP_REL_ENG_2_4_48 on Debian/Buster against openssl was working, without using the olcTLSCACertificateFile.
6f623df (ITS#8427) is the commit that changed it, as expected. As I understand it, the new behaviour is what's intended, although configs might need updates per Ondrej's last message on the ITS (duplicating the TLS settings for different connection types).
Even if it's considered a bugfix, it might be worth calling out in the release notes? Just for the sake of reducing support noise if people are unintentionally depending on the old behaviour...
Is there a global place in slapd where one can configure things like CA cert and have it defaulted into all TLS clients? I'm not aware of one, yet it seems like an obvious thing to provide...
On 7/20/19 8:45 PM, Nikos Voutsinas wrote:
Weird... My build of OPENLDAP_REL_ENG_2_4_48 on Debian/Buster against openssl was working, without using the olcTLSCACertificateFile.
Why that happens is a good question.
You probably have to dig a bit deeper and examine whether the OpenSSL lib initializes a default trust store generated by update-ca-certificates (from Debian package ca-certificates) and whether your CA cert is present there.
Ciao, Michael.
On Sun, Jul 21, 2019 at 1:50 PM Michael Ströder michael@stroeder.com wrote:
On 7/20/19 8:45 PM, Nikos Voutsinas wrote:
Weird... My build of OPENLDAP_REL_ENG_2_4_48 on Debian/Buster against openssl was working, without using the olcTLSCACertificateFile.
Why that happens is a good question.
You probably have to dig a bit deeper and examine whether the OpenSSL lib initializes a default trust store generated by update-ca-certificates (from Debian package ca-certificates) and whether your CA cert is present there.
Yes, this is what I suspect too, but that's out of the scope of this list. It also appears not to be a GNUTLS or OpenSSL issue, thus the above results are not relevant any more with the specific issue.
On the other hand it is nice that we were able to pinpoint the cause of problem before the announcement of the release, and start a discussion on the subject.
Nikos
Nikos
-
Howard Chu -
Michael Ströder -
Nikos Voutsinas -
Ondřej Kuzník -
Quanah Gibson-Mount -
Ryan Tandy