11:25 p.m.
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
1:27 a.m.
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.
1:51 a.m.
On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder <michael(a)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.
3 a.m.
On 7/20/19 10:51 AM, Nikos Voutsinas wrote:
On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder
<michael(a)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.
4:31 a.m.
On Sat, 20 Jul 2019 at 13:00, Michael Ströder <michael(a)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(a)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.
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.
6:41 a.m.
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.
6:46 a.m.
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.
6:51 a.m.
On Sat, 20 Jul 2019 at 16:46, Michael Ströder <michael(a)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.
11:35 a.m.
On Sat, Jul 20, 2019 at 4:46 PM Michael Ströder <michael(a)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
4:41 a.m.
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,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
4:55 a.m.
On Sat, 20 Jul 2019 at 14:42, Ondřej Kuzník <ondra(a)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.
9:40 a.m.
--On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas
<nvoutsin(a)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>
11:31 a.m.
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(a)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...
11:43 a.m.
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(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:35 p.m.
--On Saturday, July 20, 2019 8:43 PM +0100 Howard Chu <hyc(a)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>
5:51 p.m.
Quanah Gibson-Mount wrote:
--On Saturday, July 20, 2019 8:43 PM +0100 Howard Chu
<hyc(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:32 p.m.
--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu <hyc(a)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>
3:46 a.m.
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.
6:37 a.m.
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu
<hyc(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:02 a.m.
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.
10:18 a.m.
--On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
> --On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu
<hyc(a)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>
12:54 p.m.
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,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
8:07 p.m.
--On Sunday, July 21, 2019 10:54 PM +0200 Ondřej Kuzník
<ondra(a)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>
1:02 p.m.
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu
<hyc(a)symas.com> wrote:
>> --On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu <hyc(a)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>
--
-- 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:35 p.m.
--On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu <hyc(a)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>
1:54 p.m.
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu
<hyc(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:04 p.m.
--On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu <hyc(a)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>
2:16 p.m.
Quanah Gibson-Mount wrote:
--On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu
<hyc(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:45 p.m.
--On Sunday, July 21, 2019 11:16 PM +0100 Howard Chu <hyc(a)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>
1:12 p.m.
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.
11:45 a.m.
On Sat, Jul 20, 2019 at 9:31 PM Ryan Tandy <ryan(a)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(a)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...
3:50 a.m.
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.
4:32 a.m.
On Sun, Jul 21, 2019 at 1:50 PM Michael Ströder <michael(a)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
1523
days inactive
1525
days old
32 comments
6 participants
participants (6)
-
Howard Chu -
Michael Ströder -
Nikos Voutsinas -
Ondřej Kuzník -
Quanah Gibson-Mount -
Ryan Tandy