[SSSD-users] sssd.conf, authconfig and ldap_uri

Michael Ströder michael at stroeder.com
Sun Oct 6 16:53:34 UTC 2013


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2398 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20131006/d58970ae/attachment.p7s>


More information about the sssd-users mailing list