On 9 Aug 2017, at 16:26, Alexandre Pitre alexandre.pitre@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?)
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@redhat.com mailto:jhrozek@redhat.com> wrote:
On 7 Aug 2017, at 20:02, Alexandre Pitre via FreeIPA-users <freeipa-users@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@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@redhat.com mailto:jhrozek@redhat.com> wrote:
On 7 Aug 2017, at 18:11, Alexandre Pitre <alexandre.pitre@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@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@redhat.com mailto:jhrozek@redhat.com> wrote:
On 4 Aug 2017, at 23:08, Alexandre Pitre via FreeIPA-users <freeipa-users@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@ad.com mailto:aduser@ad.com Instead of getting a simple "Password:" prompt I get aduser@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@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@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/htm... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports
-- Alexandre Pitre alexandre.pitre@gmail.com mailto:alexandre.pitre@gmail.com _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org mailto:freeipa-users-leave@lists.fedorahosted.org
-- Alexandre Pitre alexandre.pitre@gmail.com mailto:alexandre.pitre@gmail.com
-- Alexandre Pitre alexandre.pitre@gmail.com mailto:alexandre.pitre@gmail.com _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org mailto:freeipa-users-leave@lists.fedorahosted.org
-- Alexandre Pitre alexandre.pitre@gmail.com mailto:alexandre.pitre@gmail.com