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.
On Thu, Apr 20, 2017 at 05:08:02PM +0200, 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.
sssd-ad already uses gssapi to encrypt the communication. You don't need to add any more manual configuration.
Thanks both Jakub and Stephen
That explains it..... It didn't seem really clear from the man pages and looking at the SSSD log's didn't seem to reveal it either, so I guess its just one of those things that you need to know.
----- On Apr 20, 2017, at 5:18 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Apr 20, 2017 at 05:08:02PM +0200, 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.
sssd-ad already uses gssapi to encrypt the communication. You don't need to add any more manual configuration. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Fri, Apr 21, 2017 at 07:58:53AM +0200, Troels Hansen wrote:
Thanks both Jakub and Stephen
That explains it..... It didn't seem really clear from the man pages
But that's wrong, ideally there should be no things you 'need to know'.
Let's fix the man page with: https://pagure.io/SSSD/sssd/issue/3377
Thanks for pointing out this documentation issue.
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.
sssd-users@lists.fedorahosted.org