Stephen Gallagher wrote:
On 09/25/2013 02:22 PM, Michael Ströder wrote:
> Stephen Gallagher wrote:
>> On 09/25/2013 09:06 AM, Olivier wrote:
>>> if I may an additionnal question : would the sssd fallback
>>> mecanism work with the DNS discovery ?
>>
>>> Aka, if I'd configure this in the DNS :
>>
>>>
_ldap._tcp.example.com <
http://tcp.example.com>. IN SRV 10 0
>>> 389
ldap1.example.com <
http://ldap1.example.com>.
>>>
_ldap._tcp.example.com <
http://tcp.example.com>. IN SRV 20 0
>>> 389
ldap2.example.com <
http://ldap2.example.com>.
>>
>>> will sssd fallback properly to ldap2 if ldap1 does not respond
>>> ?
>>
>> Yes, and in fact this is the recommended mechanism for setting up
>> SSSD in your environment, since you need only to update the DNS
>> records and all of your clients will have access to a new set of
>> LDAP servers (i.e. if you provision additional ones and/or retire
>> others).
> Hmm, I really wonder why SRV RRs are recommended over having a
> single service CNAME RR and maybe several A/AAAA RRs?
> Especially I'm concerned whether the TLS hostname check is
> properley done in case of TLS connections (StartTLS ext.op or
> LDAPS). Because a hostname check has to be performed against
> *a-priori* knowledge of the client to fight against MITM attacks
> with DNS spoofing.
> So if you're local configuration just knows "example.com" the
> server cert MUST have a subject alt name with that domain name. I
> doubt that LDAP clients really check this.
Would you mind rephrasing this question? I'm not really sure I
understand. The expectation with the LDAP server is that it would have
an x.509 server certificate issued for its fully-qualified domain
name. In the example above, that would be
ldap1.example.com and
ldap2.example.com.
I'd like to be more precise here:
No matter what the FQDN of the server at OS level is the client expects the
hostname it used for making the connection.
Example:
Client configuration contains
ldap.example.com.
The FQDN of the LDAP server is
srv1.example.com.
In DNS
ldap.example.com is a CNAME pointing to
ldapsrv1.example.com which in
turn has a A RR for the IP address of the service interface of
srv1.example.com where the LDAP server is listening.
=> the client simply has to check whether
ldap.example.com is in the server
cert. This protects against DNS spoofing attacks (provided cert validation
etc. is done right).
And yes, SSSD *does* check this carefully. Under the hood, we do the
following (to explain in possible unnecessary detail; I'm going to
gloss over the failover and assume that all servers are working).
1) Look up the SRV record.
This could be spoofed.
2) Look up the A/AAAA record for the FQDN referenced in the SRV
record
3) Open a socket to the first returned IP address
4) Hand off the file descriptor of this socket to the openldap client
libraries, specifying the URI to the libraries as
LDAP[s]://ldap1.example.com
5) The ldap client library will open the connection and request the
server certificate.
6) The ldap client library will validate the certificate first that
either the subject or subject alt name matches the URI we gave it and
then will verify that the server certificate is appropriately signed
by a trusted authority.
The client should check two things:
1. The usual hostname check comparing a hostname derived from one of the SRV
RRs to protect against the spoofing of the CNAME/A lookup (CN or subjectAltName).
2. A service URL check, e.g. ldap:///dc=example,dc=com to protect against the
spoofing of the SRV lookup (only subjectAltName).
Unfortunately the LDAP part of RFC 6125 does not say something about this:
http://tools.ietf.org/html/rfc6125#appendix-B.3
Also the SRV-ID in RFC 6125 is not really suitable for SRV RRs in case of LDAP:
http://tools.ietf.org/html/rfc6125#section-6.5
Ciao, Michael.