Hi Alexander,

You're correct, turns out I wasn't using the correct domain for the --domain parameter. I thought I was. Here's the command I used.

ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates --mkhomedir --domain=ipa.ad.com --realm=IPA.AD.COM --no-ntp --debug

All of my client hostname are set as "hostname.domain.ad.com", I didn't  know that in itself that was enough of a requirement to join them to FreeIPA. Of course, given that the domain is also present in freeipa and the AD trust has been established AFTER the domain was added to freeipa.  

I haven't tested yet without the realm parameter. It is possible that I don't need --domain nor --realm parameters ? Does that require the creation of _ldap._tcp. srv records in domain.ad.com dns zone?

Taken from the man page:

When the client machine hostname is not in a subdomain of an IPA server, its domain can be passed with --domain option. In that case, both SSSD and Kerberos components have the domain set in the configuration files and will use it to autodiscover IPA servers.

That line miss directed me, not sure if that's my interpretation. Documentation could benefit from being clearer and having examples. 

Setting krb5_auth_timeout to 120 seconds is also required in my environment as we're dealing with AD DC spreaded all over the globe. To make kerberos negotiation faster, I assume I could specify my AD.COM realm in /etc/krb5.conf with my local site AD DC ?

Big thanks to you and Jakub, my employer and I are very glad that this issue is finally resolved =)


On Tue, Aug 15, 2017 at 3:45 AM, Alexander Bokovoy <abokovoy@redhat.com> wrote:
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


--
/ Alexander Bokovoy



--
Alexandre Pitre
alexandre.pitre@gmail.com