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 <jhro...@redhat.com > <mailto:jhro...@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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
