[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Regression after ITS#8427 fix with back-ldap
On Wed, Jul 10, 2019 at 07:02:48PM +0100, Howard Chu wrote:
> OndÅ?ej KuznÃk wrote:
>> On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc@symas.com wrote:
>>> ondra@mistotebe.net wrote:
>>>> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah@gmail.com wrote:
>>>>> Hello,
>>>>>
>>>>> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up
>>>>> TLS settings on each reconnection) introduce a regression when the proxy
>>>>> connect to the**Backend ldap server via ldaps://
>>>>>
>>>>> The relevent part of my config is:
>>>>>
>>>>> dn: olcDatabase={2}ldap,cn=config
>>>>> objectClass: olcDatabaseConfig
>>>>> objectClass: olcLDAPConfig
>>>>> olcDatabase: {2}ldap
>>>>> olcSuffix: dc=local
>>>>> olcDbURI: ldaps://ldap.local
>>>>> olcDbChaseReferrals: TRUE
>>>>> olcDbRebindAsUser: TRUE
>>>>> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt
>>>>> olcDbIDAssertAuthzFrom: "*"
>>>>>
>>>>> (I also tried by setting LDAPTLS_CACERT env var when starting slapd)
>>>>>
>>>>> On backend ldap server logs, I get the message "TLS negociation failure"
>>>>
>>>> I've set up a test script here
>>>> https://github.com/mistotebe/openldap/tree/its8427-regression
>>>>
>>>> This runs without issues but if you replace olcDbStartTLS with an
>>>> analogous olcDbIDAssertBind in the configs, it seems the CA certificate
>>>> is not set for the connection.
>>>
>>> Then this is a new bug. Clearly the idassert-bind option takes tls_cacert
>>> as a parameter, so if it is provided it is expected to be used.
>>
>> Sure, on idassert connections only, though. When does back-ldap use one?
>> I want to edit the linked script to do exercise that so we have a decent
>> test for this now.
>
> idassert is used when you want back-ldap to propagate the incoming client's
> identity to the remote server. It affects every operation that a client issues.
Had to have a look at the code, so this is what seems to happen and I
think the code does what it should regardless of the ITS#8427 patch, see
updated test at the same place:
https://github.com/mistotebe/openldap/tree/its8427-regression
There are three completely separate types of connections as reflected in
the configuration:
- acl connections ("private" in terms of the code), used for internal
operations and anything issued by the rootdn
- idassert connections, used when the client identity should be asserted
over the other side (bindmethod setting applies or proxyauth is in
effect through other means), also currently used for acl connections
if acl is unconfigured
- normal connections (configured with the tls keyword)
All of this should default to the slapd's internal client TLS settings,
not sure how exactly that works yet and whether it reflects later
changes to the slapd's client settings.
So if anything should be shared between all connections, the preferred
way should be using global TLS* options if I understand correctly. If
different settings need to apply to different ldap backends, they need
to be copied over to each option (acl, idassert and tls) that's in
effect.
There was a slight issue with how late configuration of olcStartTLS
might not take effect, that is also handled in the above branch (and
master soon after both full make test and make its finish).
--
OndÅ?ej KuznÃk
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP