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

Stephen Gallagher sgallagh at redhat.com
Thu Sep 26 12:26:55 UTC 2013


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


More information about the sssd-users mailing list