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
<https://www.mankier.com/1/ipa-client-install#--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 <aboko...@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....@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_Director
> y_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-le...@lists.fedo
>>> rahosted.org
>>>
>>>
>>
>>
>> --
>> Alexandre Pitre
>> alexandre.pi...@gmail.com
>>
>
> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>> rahosted.org
>>
>
>
> --
> / Alexander Bokovoy
>



-- 
Alexandre Pitre
alexandre.pi...@gmail.com
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to