On 9 Aug 2017, at 16:26, Alexandre Pitre
<alexandre.pitre(a)gmail.com> wrote:
If your hosts are in the IPA subdomain, then I would have expected
centos.ipa.ad.com
<
http://centos.ipa.ad.com/>
The centos client has a hostname set to
centos.domain.ad.com
<
http://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
<
http://centos.domain.ad.com/>.
To explain further more, It'll probably be easier to use
ipa.ad.com
<
http://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/
<
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
Could you please paste once again the client’s sssd-users.conf?
I think the issue is that the hostname is used during the LDAP GSSAPI bind and it doesn’t
match the client’s name on the IDM side (so, the client thinks it’s
;, right? That’s
how the client is enrolled in IDM?)
If what I speculated above is true, then just adding:
ipa_hostname =
I think it’s only a matter of configuration (and it took me three reads of the e-mails
until I spotted how the domains are configured..)
What is the relation between
domain.ad.com <
http://domain.ad.com/> and
ad.com
<
http://ad.com/> and
ipa.ad.com <
http://ipa.ad.com/>?
ad.com <
http://ad.com/> is my Active Directory domain.
domain.ad.com <
http://domain.ad.com/> is a sub domain that was delegated from the
AD DNS to the freeipa servers
ipa.ad.com <
http://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 <jhrozek(a)redhat.com
<mailto:jhrozek@redhat.com>> wrote:
> On 7 Aug 2017, at 20:02, Alexandre Pitre via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>
> The client is in the IPA domain. Although it's sub-domain of
ad.com
<
http://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 <
http://domain.ad.com/>]]]
[sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user:
host/centos.domain.ad.com <
http://centos.domain.ad.com/>
—>
centos.domain.ad.com <
http://centos.domain.ad.com/>
If your hosts are in the IPA subdomain, then I would have expected
centos.ipa.ad.com
<
http://centos.ipa.ad.com/>
What is the relation between
domain.ad.com <
http://domain.ad.com/> and
ad.com
<
http://ad.com/> and
ipa.ad.com <
http://ipa.ad.com/>?
(Mon Aug 7 14:49:53 2017) [
sssd[be[domain.ad.com <
http://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 <
http://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.COM(a)IPA.AD.COM
<mailto:krbtgt/AD.COM@IPA.AD.COM> not found in Kerberos database)]
> ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates --mkhomedir
--domain=domain.ad.com <
http://domain.ad.com/> --realm=IPA.AD.COM
<
http://ipa.ad.com/> --server=ipaserver01.ipa.ad.com
<
http://ipaserver01.ipa.ad.com/> --server=ipaserver02.ipa.ad.com
<
http://ipaserver02.ipa.ad.com/> --no-ntp --debug
>
>
>
> On Mon, Aug 7, 2017 at 1:00 PM, Jakub Hrozek <jhrozek(a)redhat.com
<mailto:jhrozek@redhat.com>> wrote:
>
>> On 7 Aug 2017, at 18:11, Alexandre Pitre <alexandre.pitre(a)gmail.com
<mailto:alexandre.pitre@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 <
http://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
<
http://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
<
http://domain.ad.com/>]]] [be_mark_offline] (0x2000): Going offline!
>> (Mon Aug 7 15:19:47 2017) [
sssd[be[domain.ad.com
<
http://domain.ad.com/>]]] [be_mark_offline] (0x2000): Enable
check_if_online_ptask.
>> (Mon Aug 7 15:19:47 2017) [
sssd[be[domain.ad.com
<
http://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
<
http://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
<
http://domain.ad.com/>]]] [be_run_offline_cb] (0x0080): Going offline. Running
callbacks.
>> (Mon Aug 7 15:19:47 2017) [
sssd[be[domain.ad.com
<
http://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
<
http://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
<
http://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
<
http://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
<
http://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
<
http://domain.ad.com/>]]] [sdap_id_release_conn_data] (0x4000): releasing unused
connection
>> (Mon Aug 7 15:19:47 2017) [
sssd[be[domain.ad.com
<
http://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
<
http://sssd_domain.ad.com/> https://1drv.ms/f/s!AlZwwyQE2ZZ5p2ZmHLzmeKN7mBJ3
<
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 <
http://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 <
http://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 <
http://domain.ad.com/>]]]
[write_pipe_handler] (0x0400): All data has been sent!
> (Mon Aug 7 14:49:53 2017) [
sssd[be[domain.ad.com <
http://domain.ad.com/>]]]
[read_pipe_handler] (0x0400): EOF received, client finished
> (Mon Aug 7 14:49:53 2017) [
sssd[be[domain.ad.com <
http://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 <
http://domain.ad.com/>]]]
[sdap_cli_auth_step] (0x0100): expire timeout is 900
> (Mon Aug 7 14:49:53 2017) [
sssd[be[domain.ad.com <
http://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 <
http://domain.ad.com/>]]]
[sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user:
host/centos.domain.ad.com <
http://centos.domain.ad.com/>
> (Mon Aug 7 14:49:53 2017) [
sssd[be[domain.ad.com <
http://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 <
http://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.COM(a)IPA.AD.COM
<mailto:krbtgt/AD.COM@IPA.AD.COM> not found in Kerberos database)]
>
> Is your client hostname in the AD domain (
centos.domain.ad.com
<
http://centos.domain.ad.com/>) or in the IPA domain (
ipa.ad.com
<
http://ipa.ad.com/>) ?
>
>> Thanks,
>> Alex
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Aug 6, 2017 at 11:07 AM, Jakub Hrozek <jhrozek(a)redhat.com
<mailto:jhrozek@redhat.com>> wrote:
>>
>>> On 4 Aug 2017, at 23:08, Alexandre Pitre via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org
<mailto: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 aduser(a)ad.com <mailto:aduser@ad.com>
>>> Instead of getting a simple "Password:" prompt I get aduser(a)ad.com
<mailto:aduser@ad.com>@centos.domain.ad.com
<
http://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.COM(a)IPA.AD.COM <mailto:AD.COM@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 <jhrozek(a)redhat.com
<mailto:jhrozek@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
<
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_Enterprise_Linux/7/...
<
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
>>>
>>>
>>>
>>> --
>>> Alexandre Pitre
>>> alexandre.pitre(a)gmail.com <mailto:alexandre.pitre@gmail.com>
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>
>>
>>
>>
>> --
>> Alexandre Pitre
>> alexandre.pitre(a)gmail.com <mailto:alexandre.pitre@gmail.com>
>
>
>
>
> --
> Alexandre Pitre
> alexandre.pitre(a)gmail.com <mailto:alexandre.pitre@gmail.com>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>
--
Alexandre Pitre
alexandre.pitre(a)gmail.com <mailto:alexandre.pitre@gmail.com>