If your hosts are in the IPA subdomain, then I would have expected
centos.ipa.ad.com

The centos client has a hostname set to centos.domain.ad.com I'm using FQDN
hostname based on the required DNS domain, not the IPA kerberos realm.
Hence why centos.domain.ad.com.

To explain further more, It'll probably be easier to use ipa.ad.com for all
for my clients and not deal with a different DNS domain than the IPA realm.
However, we have this business requirement to use a a different domain than
the IPA realm. My understanding is that supposed to be supported by using
the --domain switch of ipa-client-install:
http://www.unix.com/man-page/centos/1/ipa-client-install/ which basically
just add static entires in /etc/sssd/sssd.conf and /etc/krb5.conf

Should I approach things differently ?


What is the relation between domain.ad.com and ad.com and ipa.ad.com?

ad.com is my Active Directory domain.
domain.ad.com is a sub domain that was delegated from the AD DNS to the
freeipa servers
ipa.ad.com is also a sub domain that was delegated from the AD DNS to the
freeipa servers and is the freeipa native kerberos realm.



On Wed, Aug 9, 2017 at 9:55 AM, Jakub Hrozek <jhro...@redhat.com> wrote:

>
> On 7 Aug 2017, at 20:02, Alexandre Pitre via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> The client is in the IPA domain. Although it's sub-domain of ad.com, I
> did delegate it and configure the IPA servers as name servers.  It uses a
> different domain suffix than ipa realm which was specified by
> ipa-client-install:
>
>
> OK, but in the logs, I see:
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0100): Executing sasl bind mech: GSSAPI, user: host/
> centos.domain.ad.com
>
> —> centos.domain.ad.com
>
> If your hosts are in the IPA subdomain, then I would have expected
> centos.ipa.ad.com
>
> What is the relation between domain.ad.com and ad.com and ipa.ad.com?
>
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0020): ldap_sasl_bind failed (-2)[Local error]
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
> Error: Unspecified GSS failure.  Minor c
> ode may provide more information (Server krbtgt/ad....@ipa.ad.com not
> found in Kerberos database)]
>
> ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates
> --mkhomedir --domain=domain.ad.com --realm=IPA.AD.COM <http://ipa.ad.com/>
>  --server=ipaserver01.ipa.ad.com --server=ipaserver02.ipa.ad.com --no-ntp
> --debug
>
>
>
> On Mon, Aug 7, 2017 at 1:00 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>>
>> On 7 Aug 2017, at 18:11, Alexandre Pitre <alexandre.pi...@gmail.com>
>> wrote:
>>
>> Clearing the sssd cache make the AD login works for a short while, it's
>> probably not necessary nor "production" ready. Looking at /var/log/sssd/
>> sssd_domain.ad.com.
>>
>>
>> Sure, but that’s not what I meant. What I meant is that just “systemctl
>> restart sssd” clears the online/offline state.
>>
>> Removing the sssd cache is not needed and can actually be quite
>> dangerous. I wish people just stopped doing that, because in case
>> credentials are cached, removing the cache also removes the credentials,
>> leaving users with no way to authenticate.
>>
>> I do see offline messages:
>>
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
>> [Input/output error])
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
>> (0x2000): Going offline!
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
>> (0x2000): Enable check_if_online_ptask.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_enable]
>> (0x0400): Task [Check if online (periodic)]: enabling task
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
>> (0x0400): Task [Check if online (periodic)]: scheduling task 65 seconds
>> from now [1502119252]
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_run_offline_cb]
>> (0x0080): Going offline. Running callbacks.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [sdap_id_op_connect_done] (0x4000): notify offline to op #1
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [ipa_subdomains_refresh_connect_done] (0x0020): Unable to connect to
>> LDAP [11]: Resource temporarily unavailable
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [ipa_subdomains_refresh_connect_done] (0x0080): No IPA server is
>> available, cannot get the subdomain list while offline
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_done]
>> (0x0040): Task [Subdomains Refresh]: failed with [1432158212]: SSSD is
>> offline
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
>> (0x0400): Task [Subdomains Refresh]: scheduling task 14400 seconds from now
>> [1502133587]
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [sdap_id_release_conn_data] (0x4000): releasing unused connection
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [be_ptask_online_cb] (0x0400): Back end is online
>>
>> I uploaded  the full log file /var/log/sssd/sssd_domain.ad.com
>> https://1drv.ms/f/s!AlZwwyQE2ZZ5p2ZmHLzmeKN7mBJ3
>>
>> Both my IPA servers looks healthy.AD trust agent/controller server role
>> are installed on both.
>>
>> ipa trustdomain-find ad.com does return all of my AD domains on both IPA
>> servers.
>>
>>
>> This is the failure in the logs:
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]]
>> [sdap_process_result] (0x2000): Trace: end of ldap_result list
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]]
>> [write_pipe_handler] (0x0400): All data has been sent!
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [read_pipe_handler]
>> (0x0400): EOF received, client finished
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_get_tgt_recv]
>> (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_IPA.AD.COM
>> <http://ccache_ipa.ad.com/>], expired on [1502203793]
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]]
>> [sdap_cli_auth_step] (0x0100): expire timeout is 900
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]]
>> [sdap_cli_auth_step] (0x1000): the connection will expire at 1502118293
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
>> (0x0100): Executing sasl bind mech: GSSAPI, user: host/
>> centos.domain.ad.com
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
>> (0x0020): ldap_sasl_bind failed (-2)[Local error]
>> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
>> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
>> Error: Unspecified GSS failure.  Minor c
>> ode may provide more information (Server krbtgt/ad....@ipa.ad.com not
>> found in Kerberos database)]
>>
>> Is your client hostname in the AD domain (centos.domain.ad.com) or in
>> the IPA domain (ipa.ad.com) ?
>>
>> Thanks,
>> Alex
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Aug 6, 2017 at 11:07 AM, Jakub Hrozek <jhro...@redhat.com> wrote:
>>
>>>
>>> On 4 Aug 2017, at 23:08, Alexandre Pitre via FreeIPA-users <
>>> freeipa-users@lists.fedorahosted.org> wrote:
>>>
>>> Turns out, I'm still getting the same problem. It works right away after
>>> I force clean the sssd cache: systemctl stop sssd ; rm -f /var/lib/sss/db/*
>>> /var/log/sssd/* ; systemctl start sssd
>>>
>>> After some time, trying to log back on the same system I see the login
>>> prompt is much quicker when I type adu...@ad.com
>>> Instead of getting a simple "Password:" prompt  I get adu...@ad.com@
>>> centos.domain.ad.com's password.
>>>
>>> If I login as root and stop/start and clean the sssd cache, it start
>>> working again.
>>>
>>>
>>> Are you sure cleaning the cache is needed? Because I think your issue is
>>> different. The fact that you get a faster login prompt and the “Server not
>>> found…” message both point to the sssd going offline.
>>>
>>> You could run ‘sssctl domain-status’ to show if the domain is online or
>>> offline (requires the ‘ifp’ service to be enabled until RHEL-7.4/upstream
>>> 1.15.x) or look into the logs for messages like “Going offline”.
>>>
>>> /var/log/messages is filled with:
>>>
>>> centos sssd_be: GSSAPI Error: Unspecified GSS failure.  Minor code may
>>> provide more information (Server krbtgt/ad....@ipa.ad.com not found in
>>> Kerberos database)
>>>
>>>
>>> This is the trust principal. Are you sure all your replicas are either
>>> trust agents or you ran “ipa-adtrust-install” on them?
>>>
>>>
>>>
>>> Any thoughts ?
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>> On Tue, Aug 1, 2017 at 2:58 AM, Jakub Hrozek <jhro...@redhat.com> wrote:
>>>
>>>> On Mon, Jul 31, 2017 at 05:47:11PM -0400, Alexandre Pitre wrote:
>>>> > Bull-eye Jakub, that did the trick. I should have posted for help on
>>>> the
>>>> > mailing list sooner. Thanks you so much, you are saving my ass.
>>>> >
>>>> > It makes sense to increase the krb5_auth_timeout as my AD domain
>>>> > controllers servers are worldwide. Currently they exist in 3 regions:
>>>> North
>>>> > America, Europe and Asia.
>>>> >
>>>> > The weird thing is it seems that when a linux host try to authenticate
>>>> > against my AD, it just randomly select an AD DC from the _kerberos
>>>> SRV
>>>> > records. Normally, on the windows side, if "sites and services" are
>>>> setup
>>>> > correctly with subnet defined and binded to sites, a windows client
>>>> > shouldn't try to authenticate against an AD DC that isn't local to his
>>>> > site. This mechanism doesn't  seem to apply to my linux hosts. Is it
>>>> > because it's only available for windows hosts ? Is there another way
>>>> to
>>>> > force linux clients to authenticate against AD DC local to their site
>>>> ?
>>>>
>>>> We haven't implemented the site selection for the clients yet, only for
>>>> servers, see:
>>>>     https://bugzilla.redhat.com/show_bug.cgi?id=1416528
>>>>
>>>> >
>>>> > For now, I set the krb5_auth_timeout to 120 seconds. I had to
>>>> completely
>>>> > stop sssd and start it again. A colleague mentioned that sssd has a
>>>> known
>>>> > issue with restart apparently.
>>>>
>>>> I'm not aware of any such issue..
>>>>
>>>> >
>>>> > Also, I'm curious about ports requirements. Going from linux hosts to
>>>> AD, I
>>>> > only authorize 88 TCP/UDP. I believe that's all I need.
>>>>
>>>> Yes, from the clients, that should be enough. The servers need more
>>>> ports open:
>>>>     https://access.redhat.com/documentation/en-US/Red_Hat_Ente
>>>> rprise_Linux/7/html/Linux_Domain_Identity_Authentication_and
>>>> _Policy_Guide/installing-ipa.html#prereq-ports
>>>>
>>>
>>>
>>>
>>> --
>>> Alexandre Pitre
>>> alexandre.pi...@gmail.com
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-leave@lists.f
>>> edorahosted.org
>>>
>>>
>>>
>>
>>
>> --
>> Alexandre Pitre
>> alexandre.pi...@gmail.com
>>
>>
>>
>
>
> --
> 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
>
>
>


-- 
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