Hi guys!
Is there anyway I can force my SSSD clients running 1.9.5 (Ubuntu 12.04) and 1.9.2 (CentOS 6) to bind to LDAPs (port 636) instead of LDAP (port 389) when my providers are all set to "ad"?
Consequently, I'll need to specify a certificate to be used to verify the server's authenticity.
I'm using service discovery and have SRV records in place on my domain controllers.
Here's my config: [sssd] config_file_version = 2 debug_level = 0 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = DOMAIN
[pam] debug_level = 0
[nss] debug_level = 0 filter_users = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm filter_groups = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm reconnection_retries = 3
[domain/DOMAIN] debug_level = 0 ad_domain = DOMAIN.local id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad enumerate = true cache_credentials = true fallback_homedir = /home/%u dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true
Thanks!
-Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/24/2013 03:50 PM, Chris Hartman wrote:
Hi guys!
Is there anyway I can force my SSSD clients running 1.9.5 (Ubuntu 12.04) and 1.9.2 (CentOS 6) to bind to LDAPs (port 636) instead of LDAP (port 389) when my providers are all set to "ad"?
Why would you want to do this? The GSSAPI communication provided by the Kerberos keytab is already encrypting all communication you send on port 389.
Stephen,
Ah. I did not realize that. I thought some directory information might be coming over in plaintext as with normal LDAP binds. Since this is not the case, I'm happy!
Thanks!
-Chris
On Wed, Jul 24, 2013 at 4:39 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/24/2013 03:50 PM, Chris Hartman wrote:
Hi guys!
Is there anyway I can force my SSSD clients running 1.9.5 (Ubuntu 12.04) and 1.9.2 (CentOS 6) to bind to LDAPs (port 636) instead of LDAP (port 389) when my providers are all set to "ad"?
Why would you want to do this? The GSSAPI communication provided by the Kerberos keytab is already encrypting all communication you send on port 389. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHwO3AACgkQeiVVYja6o6OwTQCeLNHFZIqOUz15ho4YrsYa0q7G Zx0AnjSY3GJsY4Qtyyvr7fsNnkp3OlEk =VLIv -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Ah. It appears I now have a reason to perform SASL binds over LDAPS. My Active Directory guys are complaining; they say the AD server is throwing errors that some clients are performing unsigned SASL binds. When signing is required on the server, bind attempts from SSSD clients fail.
So, I ask again, is there a way I can force my SSSD clients to use LDAPS?
Thanks.
-Chris
On Wed, Jul 24, 2013 at 5:07 PM, Chris Hartman qrstuv@gmail.com wrote:
Stephen,
Ah. I did not realize that. I thought some directory information might be coming over in plaintext as with normal LDAP binds. Since this is not the case, I'm happy!
Thanks!
-Chris
On Wed, Jul 24, 2013 at 4:39 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/24/2013 03:50 PM, Chris Hartman wrote:
Hi guys!
Is there anyway I can force my SSSD clients running 1.9.5 (Ubuntu 12.04) and 1.9.2 (CentOS 6) to bind to LDAPs (port 636) instead of LDAP (port 389) when my providers are all set to "ad"?
Why would you want to do this? The GSSAPI communication provided by the Kerberos keytab is already encrypting all communication you send on port 389. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHwO3AACgkQeiVVYja6o6OwTQCeLNHFZIqOUz15ho4YrsYa0q7G Zx0AnjSY3GJsY4Qtyyvr7fsNnkp3OlEk =VLIv -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 07/30/2013 11:53 AM, Chris Hartman wrote:
Ah. It appears I now have a reason to perform SASL binds over LDAPS. My
Active Directory guys are complaining; they say the AD server is throwing errors that some clients are performing unsigned SASL binds. When signing is required on the server, bind attempts from SSSD clients fail.
So, I ask again, is there a way I can force my SSSD clients to use LDAPS?
I looked in the trac to see what we have there relevant to your case. I found https://fedorahosted.org/sssd/ticket/1030 https://fedorahosted.org/sssd/ticket/1277
I also found this https://fedorahosted.org/sssd/ticket/780 and https://fedorahosted.org/sssd/ticket/561
But it is to use the actual PKI authentication for the client connection not to just armor the tunnel.
So it looks like we do not have a RFE to cover what you are looking for. I wonder if you can override the default configuration and use certificates anyways on top of GSSAPI. I think so but we actually want to remove this capability. See https://fedorahosted.org/sssd/ticket/489
So may be we should not do it and allow for double tunneling for cases like this? But it is extremely inefficient. Can AD guys allow SASL GSSAPI binds? I think that would be the simplest as it has same security attributes as bind over the LDAPS.
Thanks.
-Chris
On Wed, Jul 24, 2013 at 5:07 PM, Chris Hartman <qrstuv@gmail.com
mailto:qrstuv@gmail.com> wrote:
Stephen,
Ah. I did not realize that. I thought some directory information might
be coming over in plaintext as with normal LDAP binds. Since this is not the case, I'm happy!
Thanks!
-Chris
On Wed, Jul 24, 2013 at 4:39 PM, Stephen Gallagher <sgallagh@redhat.com
mailto:sgallagh@redhat.com> wrote:
On 07/24/2013 03:50 PM, Chris Hartman wrote:
Hi guys!
Is there anyway I can force my SSSD clients running 1.9.5 (Ubuntu 12.04) and 1.9.2 (CentOS 6) to bind to LDAPs (port 636) instead of LDAP (port 389) when my providers are all set to "ad"?
Why would you want to do this? The GSSAPI communication provided by the Kerberos keytab is already encrypting all communication you send on port 389. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
mailto:sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Jul 30, 2013 at 11:53:34AM -0400, Chris Hartman wrote:
Ah. It appears I now have a reason to perform SASL binds over LDAPS. My Active Directory guys are complaining; they say the AD server is throwing errors that some clients are performing unsigned SASL binds. When signing is required on the server, bind attempts from SSSD clients fail.
So, I ask again, is there a way I can force my SSSD clients to use LDAPS?
Can you paste the error you saw on the client? (Or even the server side event log?)
Sure can.
Warning message on the server alerting of unsigned bind:
Service 534667 Tue Jul 30 01:02:26 2013 2887 Microsoft-Windows-ActiveDirectory_DomainService S-1-5-7 N/A Warning milkdud.DOMAIN.local 16 During the previous 24 hour period, some clients attempted to perform LDAP binds that were either: (1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or (2) A LDAP simple bind that was performed on a cleartext (non-SSL/TLS-encrypted) connection
This directory server is not currently configured to reject such binds. The security of this directory server can be significantly enhanced by configuring the server to reject such binds. For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.
Summary information on the number of these binds received within the past 24 hours is below.
You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the "LDAP Interface Events" event logging category to level 2 or higher.
Number of simple binds performed without SSL/TLS: 0 Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: 691
Log of an actual unsigned bind by an SSSD client:
Service 25145 Tue Jul 30 11:56:31 2013 2889 Microsoft-Windows-ActiveDirectory_DomainService S-1-5-7 N/A Information milkdud.DOMAIN.local 16 The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a cleartext (non-SSL/TLS-encrypted) LDAP connection.
Client IP address: 10.X.X.47:40288 Identity the client attempted to authenticate as: DOMAIN\KITKAT$
Debug output from SSSD on client that failed to authenticate:
root@kitkat:~# sssd -i -d 4
(Tue Jul 30 13:39:11 2013) [sssd] [start_service] (0x0100): Queueing
service pam for startup (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'AD' as 'resolved' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'milkdud.DOMAIN.local' in files (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'milkdud.DOMAIN.local' as 'resolving name' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'milkdud.DOMAIN.local' in files (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'milkdud.DOMAIN.local' in DNS (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'milkdud.DOMAIN.local' as 'name resolved' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://milkdud.DOMAIN.local' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [DEFAULT][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_user_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [USER][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_group_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [GROUP][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_netgroup_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [NETGROUP][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_sudo_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_service_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [SERVICE][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_autofs_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [AUTOFS][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [3] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:11 2013) [[sssd[ldap_child[13102]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [KITKAT$@DOMAIN.LOCAL] (Tue Jul 30 13:39:11 2013) [[sssd[ldap_child[13102]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Tue Jul 30 13:39:12 2013) [sssd[pam]] [monitor_common_send_id] (0x0100): Sending ID: (pam,1) (Tue Jul 30 13:39:12 2013) [sssd[pam]] [sss_names_init] (0x0100): Using re [(((?P<domain>[^\]+)\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\]+)$))]. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x9ac0160] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [monitor_common_send_id] (0x0100): (Tue Jul 30 13:39:12 2013) [sssd[pam]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,PAM) Sending ID: (nss,1) (Tue Jul 30 13:39:12 2013) [sssd[pam]] [responder_set_fd_limit] (0x0100): (Tue Jul 30 13:39:12 2013) [sssd[nss]] [sss_names_init] (0x0100): Using re [(((?P<domain>[^\]+)\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\]+)$))]. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x9ac5600] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,NSS) Maximum file descriptors set to [4096] (Tue Jul 30 13:39:12 2013) [sssd] [client_registration] (0x0100): Received ID registration: (pam,1) (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Cancel DP ID timeout [0x9ac0160] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Added Frontend client [PAM] (Tue Jul 30 13:39:12 2013) [sssd[pam]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Tue Jul 30 13:39:12 2013) [sssd[pam]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [child_sig_handler] (0x0100): child [13102] finished successfully. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: KITKAT$ (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (8)[Strong(er) authentication required] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0080): Extended failure message: [00002028: LdapErr: DSID-0C0901FC, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v1772] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'milkdud.DOMAIN.local' as 'not working' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'fudge.DOMAIN.local' in files (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'fudge.DOMAIN.local' as 'resolving name' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'fudge.DOMAIN.local' in files (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'fudge.DOMAIN.local' in DNS (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'fudge.DOMAIN.local' as 'name resolved' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://fudge.DOMAIN.local' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [3] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:12 2013) [[sssd[ldap_child[13103]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [KITKAT$@DOMAIN.LOCAL] (Tue Jul 30 13:39:12 2013) [[sssd[ldap_child[13103]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [responder_set_fd_limit] (0x0100): Maximum file descriptors set to [4096] (Tue Jul 30 13:39:12 2013) [sssd] [client_registration] (0x0100): Received ID registration: (nss,1) (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Cancel DP ID timeout [0x9ac5600] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Added Frontend client [NSS] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Tue Jul 30 13:39:12 2013) [sssd[nss]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [child_sig_handler] (0x0100): child [13103] finished successfully. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: KITKAT$ (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (8)[Strong(er) authentication required] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0080): Extended failure message: [00002028: LdapErr: DSID-0C0901FC, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v1772] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'fudge.DOMAIN.local' as 'not working' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error])
-Chris
On Tue, Jul 30, 2013 at 1:16 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, Jul 30, 2013 at 11:53:34AM -0400, Chris Hartman wrote:
Ah. It appears I now have a reason to perform SASL binds over LDAPS. My Active Directory guys are complaining; they say the AD server is throwing errors that some clients are performing unsigned SASL binds. When signing is required on the server, bind attempts from SSSD clients fail.
So, I ask again, is there a way I can force my SSSD clients to use LDAPS?
Can you paste the error you saw on the client? (Or even the server side event log?) _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 07/30/2013 01:44 PM, Chris Hartman wrote:
Sure can.
Warning message on the server alerting of unsigned bind:
Service 534667 Tue Jul 30 01:02:26 2013 2887 Microsoft-Windows-ActiveDirectory_DomainService S-1-5-7 N/A Warning milkdud.DOMAIN.local 16 During the previous 24 hour period, some clients attempted to perform LDAP binds that were either: (1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or (2) A LDAP simple bind that was performed on a cleartext (non-SSL/TLS-encrypted) connection This directory server is not currently configured to reject such binds. The security of this directory server can be significantly enhanced by configuring the server to reject such binds. For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923. Summary information on the number of these binds received within the past 24 hours is below. You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the "LDAP Interface Events" event logging category to level 2 or higher. Number of simple binds performed without SSL/TLS: 0
So you actually see that there have been no cleartext binds.
Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: 691
And as you see all the binds were using a negotiated method. I wonder if the policy can be tuned to allow only Kerberos negotiated binds. IMO this would be optimal.
Log of an actual unsigned bind by an SSSD client:
Service 25145 Tue Jul 30 11:56:31 2013 2889 Microsoft-Windows-ActiveDirectory_DomainService S-1-5-7 N/A Information milkdud.DOMAIN.local 16 The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a cleartext (non-SSL/TLS-encrypted) LDAP connection. Client IP address: 10.X.X.47:40288 Identity the client attempted to authenticate as: DOMAIN\KITKAT$
Debug output from SSSD on client that failed to authenticate:
root@kitkat:~# sssd -i -d 4 (Tue Jul 30 13:39:11 2013) [sssd] [start_service] (0x0100): Queueing service pam for startup (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'AD' as 'resolved' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'milkdud.DOMAIN.local' in files (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'milkdud.DOMAIN.local' as 'resolving name' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'milkdud.DOMAIN.local' in files (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'milkdud.DOMAIN.local' in DNS (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'milkdud.DOMAIN.local' as 'name resolved' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://milkdud.DOMAIN.local' (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [DEFAULT][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_user_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [USER][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_group_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [GROUP][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_netgroup_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [NETGROUP][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_sudo_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_service_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [SERVICE][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_autofs_search_base] to [DC=DOMAIN,DC=local]. (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [common_parse_search_base] (0x0100): Search base added: [AUTOFS][DC=DOMAIN,DC=local][SUBTREE][] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [3] (Tue Jul 30 13:39:11 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:11 2013) [[sssd[ldap_child[13102]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [KITKAT$@DOMAIN.LOCAL] (Tue Jul 30 13:39:11 2013) [[sssd[ldap_child[13102]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Tue Jul 30 13:39:12 2013) [sssd[pam]] [monitor_common_send_id] (0x0100): Sending ID: (pam,1) (Tue Jul 30 13:39:12 2013) [sssd[pam]] [sss_names_init] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x9ac0160] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [monitor_common_send_id] (0x0100): (Tue Jul 30 13:39:12 2013) [sssd[pam]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,PAM) Sending ID: (nss,1) (Tue Jul 30 13:39:12 2013) [sssd[pam]] [responder_set_fd_limit] (0x0100): (Tue Jul 30 13:39:12 2013) [sssd[nss]] [sss_names_init] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x9ac5600] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,NSS) Maximum file descriptors set to [4096] (Tue Jul 30 13:39:12 2013) [sssd] [client_registration] (0x0100): Received ID registration: (pam,1) (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Cancel DP ID timeout [0x9ac0160] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Added Frontend client [PAM] (Tue Jul 30 13:39:12 2013) [sssd[pam]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Tue Jul 30 13:39:12 2013) [sssd[pam]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [child_sig_handler] (0x0100): child [13102] finished successfully. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: KITKAT$ (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (8)[Strong(er) authentication required] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0080): Extended failure message: [00002028: LdapErr: DSID-0C0901FC, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v1772] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'milkdud.DOMAIN.local' as 'not working' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'fudge.DOMAIN.local' in files (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'fudge.DOMAIN.local' as 'resolving name' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'fudge.DOMAIN.local' in files (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'fudge.DOMAIN.local' in DNS (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [set_server_common_status] (0x0100): Marking server 'fudge.DOMAIN.local' as 'name resolved' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://fudge.DOMAIN.local' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [3] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:12 2013) [[sssd[ldap_child[13103]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [KITKAT$@DOMAIN.LOCAL] (Tue Jul 30 13:39:12 2013) [[sssd[ldap_child[13103]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [responder_set_fd_limit] (0x0100): Maximum file descriptors set to [4096] (Tue Jul 30 13:39:12 2013) [sssd] [client_registration] (0x0100): Received ID registration: (nss,1) (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Cancel DP ID timeout [0x9ac5600] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [client_registration] (0x0100): Added Frontend client [NSS] (Tue Jul 30 13:39:12 2013) [sssd[nss]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Tue Jul 30 13:39:12 2013) [sssd[nss]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [child_sig_handler] (0x0100): child [13103] finished successfully. (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: KITKAT$ (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (8)[Strong(er) authentication required] (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sasl_bind_send] (0x0080): Extended failure message: [00002028: LdapErr: DSID-0C0901FC, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v1772]
SSF setting?
(Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'fudge.DOMAIN.local' as 'not working' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD' (Tue Jul 30 13:39:12 2013) [sssd[be[DOMAIN]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error])
-Chris
On Tue, Jul 30, 2013 at 1:16 PM, Jakub Hrozek <jhrozek@redhat.com mailto:jhrozek@redhat.com> wrote:
On Tue, Jul 30, 2013 at 11:53:34AM -0400, Chris Hartman wrote: > Ah. It appears I now have a reason to perform SASL binds over LDAPS. My > Active Directory guys are complaining; they say the AD server is throwing > errors that some clients are performing unsigned SASL binds. When signing > is required on the server, bind attempts from SSSD clients fail. > > So, I ask again, is there a way I can force my SSSD clients to use LDAPS? Can you paste the error you saw on the client? (Or even the server side event log?) _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Jul 30, 2013 at 3:07 PM, Dmitri Pal dpal@redhat.com wrote:
And as you see all the binds were using a negotiated method. I wonder if the policy can be tuned to allow only Kerberos negotiated binds. IMO this would be optimal.
There is no Group Policy that can enforce a specific type of bind that I'm aware. While secure binds are always supported, there is only a toggle between "require secure binds" and "allow secure binds." I don't think there is any other tuning available.
I think there is something to be said for still requiring SSL despite the fact that binds are encrypted with the keytab as it helps mitigate man-in-the-middle attacks.
-Chris
On 07/30/2013 03:55 PM, Chris Hartman wrote:
On Tue, Jul 30, 2013 at 3:07 PM, Dmitri Pal <dpal@redhat.com mailto:dpal@redhat.com> wrote:
And as you see all the binds were using a negotiated method. I wonder if the policy can be tuned to allow only Kerberos negotiated binds. IMO this would be optimal.
There is no Group Policy that can enforce a specific type of bind that I'm aware. While secure binds are always supported, there is only a toggle between "require secure binds" and "allow secure binds." I don't think there is any other tuning available.
I think there is something to be said for still requiring SSL despite the fact that binds are encrypted with the keytab as it helps mitigate man-in-the-middle attacks.
-Chris
AFAIU Kerberos negotiation if implemented properly (which I think is the case here) mitigates MIM attacks making SSL really not needed. MSFT is just paranoid about it. The SSL might be needed when you do a password change but not the bind but I suspect for simplicity MSFT decided to implement all or nothing approach. Very unfortunate, I should say... Not for the first time.
sssd-users@lists.fedorahosted.org