On ma, 14 elo 2017, Alexandre Pitre via FreeIPA-users wrote:
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/AD.COM@TENANT.AD.COM not found in Kerberos database)]
Why do you use domain.ad.com as IPA domain here? Your IPA domain should be 'ipa.ad.com' when you enroll clients regardless which DNS domains they belong to. It is the realm they will be attached, so your sssd.conf on the machines in domain.ad.com should have
[domain/ipa.ad.com] ipa_domain = ipa.ad.com
And the client enrollment should use IPA domain too:
ipa-client-install --domain ipa.ad.com
Read http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain for more.
Because your configuration now is wrong, krb5 library thinks your client is part of DOMAIN.AD.COM realm (TENANT.AD.COM in the log above, I guess you did not scrub it well) and not IPA.AD.COM instead. This is why it fails to find a cross-realm TGT to traverse up from DOMAIN.AD.COM to AD.COM realm hierarchically. Obviously, it should not be doing that.
(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 < freeipa-users@lists.fedorahosted.org> wrote:
On 12 Aug 2017, at 20:14, Alexander Bokovoy via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> 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 -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
-- Alexandre Pitre alexandre.pitre@gmail.com
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org