Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 10:54 PM +0200 Ondřej Kuzník 
 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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 11:16 PM +0100 Howard Chu  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: 



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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu  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/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu  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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu  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/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu  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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ryan Tandy]

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.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu  wrote:
> 
>>> --On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu 
>>> 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:
> 
> 
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ondřej Kuzník]

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

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu  wrote:


--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu 
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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

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.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu  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/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sun, Jul 21, 2019 at 1:50 PM Michael Ströder 
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

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

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.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

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.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu  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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Saturday, July 20, 2019 8:43 PM +0100 Howard Chu  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/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Saturday, July 20, 2019 8:43 PM +0100 Howard Chu  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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sat, Jul 20, 2019 at 9:31 PM 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
> > 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...
>

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

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 
>>  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/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sat, Jul 20, 2019 at 4:46 PM Michael Ströder 
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

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ryan Tandy]

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 
 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...

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas 
 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:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sat, 20 Jul 2019 at 16:46, Michael Ströder  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.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sat, 20 Jul 2019 at 14:42, Ondřej Kuzník  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}
> > 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.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sat, 20 Jul 2019 at 13:00, Michael Ströder  wrote:

> On 7/20/19 10:51 AM, Nikos Voutsinas wrote:
> > On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder  > > 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.
>

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder 
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.
>
>

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

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.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

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.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ondřej Kuzník]

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}
> 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

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/20/19 10:51 AM, Nikos Voutsinas wrote:
> On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder  > 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.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

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.



smime.p7s
Description: S/MIME Cryptographic Signature