On 04/20/2017 11:08 AM, Troels Hansen wrote:
I'm trying to force SSSD to only communicate encrypted, because of company rules. I think i'm missing something:
SSSD configured with: id_provider = ad
and DNS service resolution is enabled (default)
I have tried about every combination of:
ldap_id_use_start_tls = true ldap_service_port = 636 ldap_tls_reqcert = allow
in sssd.conf [domain] section. However, I can see SSSD LDAP connection over port 389.
# netstat -tanp | grep sssd_be tcp 0 0 172.16.5.202:53520 172.16.1.241:389 ESTABLISHED 18080/sssd_be
Have I just missed something? Do I need to pull the certificates from AD to make it work. I'm not really interested in verifying the certificates but only ensuring an encrypted channel.
Well, first of all be aware that if you are using the AD provider, your communication across port 389 *is* encrypted using GSSAPI (Kerberos). It uses the host keytab to encrypt that communication. Using SSL atop that would be a waste of resources (and unsupported by Microsoft, if I recall correctly).
If you have GSSAPI encryption available (you do) then SSSD ignores the `ldap_id_use_start_tls` argument because you don't need both encryption streams. `ldap_id_use_start_tls` tells the LDAP provider to use the STARTTLS command on port 389 to wrap communication in a secure layer.
If you REALLY, wanted to use port 636, you would need to use `ldap_uri = ldaps://server.host.name` (note the "ldaps" in the URI) which tells it to use SSL-based encryption and the default port for that which is 636. I don't actually know what happens when you try this with `ad_provider=ad`, though. It's unnecessary, wasteful and possibly disallowed by Microsoft.