-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
If those referenced A records are also a load balancer pointing to
other machines behind it, then yes.
ldap1-1.example.com and
ldap1-2.example.com would need their cert to have a subject alt name
with the FQDN
ldap.example.com since that's the name they would
addressed by.
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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlJEKA4ACgkQeiVVYja6o6N1eACff7WWl3ZsD3TwKsc2BKjEo6b9
ViQAoJDzj5Dfi42SPx08LUwfljHyT8/D
=6UnE
-----END PGP SIGNATURE-----