Although, the explanation from Alexander Bokovoy made perfect sense, I'm still facing the issue after I re-established the AD trust successfully:
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1502764720 (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/centos.domain.ad.com (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/[email protected] not found in Kerberos database)] (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler] (0x1000): Waiting for child [5197]. (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler] (0x0100): child [5197] finished successfully. (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_cli_connect_recv] (0x0040): Unable to establish connection [1432158225]: Authentication Failed (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2048 (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'ipaserver02.ipa.ad.com' as 'not working' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'ipaserver02.ipa.ad.com' as 'not working' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f4811278710], connected[1], ops[(nil)], ldap[0x7f481121f780], destructor_lock[0], release_memory[0] (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_id_op_connect_done] (0x4000): attempting failover retry on op #1 (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status] (0x1000): Port status of port 0 for server '(no name)' is 'neutral' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'domain.ad.com' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.domain.ad.com' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [request_watch_destructor] (0x0400): Deleting request watch (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolv_discover_srv_done] (0x0040): SRV query failed [4]: Domain name not found (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolve_srv_done] (0x0040): Unable to resolve SRV [1432158235]: SRV record not found (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned [1432158235]: SRV record not found (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [be_resolve_server_process] (0x1000): Trying with the next one! (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_server_status] (0x1000): Status of server 'ipaserver01.ipa.ad.com' is 'name resolved' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipaserver01.ipa.ad.com' is 'not working' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_server_status] (0x1000): Status of server 'ipaserver02.ipa.ad.com' is 'name resolved' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipaserver02.ipa.ad.com' is 'not working' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status] (0x1000): Port status of port 0 for server '(no name)' is 'not working' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [be_mark_offline] (0x2000): Going offline! These logs are from a system newly joined to FreeIPA. I know for a fact it's related to the use of a different domain then my IPA realm. I tested with some systems with both dns and ipa realm set to ipa.ad.com and the authentication works just fine. On Mon, Aug 14, 2017 at 4:22 AM, Jakub Hrozek via FreeIPA-users < [email protected]> wrote: > > > On 12 Aug 2017, at 20:14, Alexander Bokovoy via FreeIPA-users < > [email protected]> wrote: > > > > To close this thread, I helped Alexandre on the IRC. The basic issue is > > that one needs to plan domain space carefully when using trust to AD. > > Active Directory is more than just DNS zones, LDAP, Kerberos and > > friends. Active Directory domain controllers have internal assumptions > > on what belongs to AD namespace and what is not. > > Thank you for driving this towards the end. I knew I was missing something > and I’m glad I could learn something new as well. > _______________________________________________ > FreeIPA-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Alexandre Pitre [email protected]
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
