> 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
centos.domain.ad.com <
http://centos.domain.ad.com/>
as far as its hostname is concerned but the IDM master only knows about
centos.ipa.ad.com <
http://centos.ipa.ad.com/>, right? That’s how the
client is enrolled in IDM?)
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.
When IPA is handling DNS zones, we automatically add any domain added to
IPA via 'ipa dnszone-add' to the list of IPA realm's domains, so it just
works.
When trust is established, we tell AD that IPA 'owns' namespaces
associated with IPA realm. In most cases a primary domain is advertised.
If you need more, 'ipa realmdomains-mod' command can be used to add
more. However, you need to re-run 'ipa trust-add' to refresh this
information to AD side and AD DCs run explicit verification of the
topology conflicts at this step so it may report back some issues and
fail to update the topology. In this case you'd get errors back in the
error_log on IPA master that performed 'ipa trust-add' operation.
However, if you added new domains to IPA realm after trust was
established, AD DCs have no idea these domains belong to IPA realm and
cannot do any authentication routing to IPA. Running topology validation
is expensive and Microsoft documentation says it is only done when an
explicit call for validation is used. We decided to couple this step
with 'ipa trust-add' because for most people this is a rare step to
perform.
For example, if you have
for AD, we'd
advertise that '*.ipa.ad.com' DNS namespace belongs to IPA realm. If you
would add IPA clients to another domain, say, .domain.ad.com (and you
only have IPA clients there, no Windows machines), AD DCs will still
think .domain.ad.com belongs to AD, not IPA. To correct this thinking,
add
to IPA realm mapping:
ipa realmdomains-mod --add-domain=domain.ad.com
and re-establish trust with 'ipa trust-add ...'. Running 'ipa trust-add'
is enough -- it will automatically remove previous relationship and
create a new one without affecting anything else.
If what I speculated above is true, then just adding:
ipa_hostname =
centos.ipa.ad.com <
http://centos.ipa.ad.com/>
Into sssd.conf’s domain section might do the trick.
> Should I approach things differently ?
>
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>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org