Re: SSSD and Kerberos-related problems during joining a RHEL8.4-host to AD

[Spike White]

Yeah,

When 'kinit -k' is failing, you have really fundamental Kerberos failures
going on.  It's not even involving sssd at that point.  Usually,
1. your entries in /etc/krb5.keytab file are stale or wrong, or
2. it can't find or access your AD DCs or
3. other DNS problems.

You can run 'kinit -k' in debug mode (export KRB5_TRACE=/tmp/krb5.out) and
view that debug file to see more specifics about the specific failure.

For instance, we have two Linux VMs in a cloud provider now where the AD
integration is misbehaving.  kinit -k is failing.  From the debug log of
'kinit -k', we can tell it's the DNS discovers of the AD DCs that's
failing.  Turns out, it's a stealth MTU problem.

I believe until recently, sssd didn't support storing its kerberos creds in
the KCM, so your particular error condition is not one I've run across yet.

Glad to hear your problem is resolved.

Spike

On Fri, Nov 19, 2021 at 5:55 AM Aron Kelemen Szabo <
[e-mail]> wrote:
> Hi again!
>
> I think I have found the problem! 😊
>
> kinit -k returned the following error:
>
> kinit: Connection refused while getting default ccache
>
> …while kvno -S host TEST0003 returned the following error:
>
> kvno: Connection refused while opening ccache
>
> A bit of googling on these error messages revealed that the culprit might
> be the KCM-service not running... When googling a bit on the error messages
> thrown by kinit and kvno and issuing the following commands revealed that
> this was indeed the case.
>
> systemctl status sssd-kcm.socket
>
> systemctl status sssd-kcm.service
>
> I came across this error report which among other things recommends
> upgrading the packages:
> https://bugzilla.redhat.com/show_bug.cgi?id=1716981
>
> So I run a “yum update” and re-joined the host to the realm, and now the
> AD-logons seem to be working fine! Now I “only” need to find out the very
> happening that rendered KCM to fail. :-)
>
> Thanks for all your input again!
>
> Best regards,
>
> Áron
>
> *From:* Spike White 
> *Sent:* den 18 november 2021 18:46
> *To:* End-user discussions about the System Security Services Daemon <
> [e-mail]>
> *Subject:* [SSSD-users] Re: SSSD and Kerberos-related problems during
> joining a RHEL8.4-host to AD
>
> Aron,
>
> Several things.    Some backgroun -- in our company, we have thousands of
> OL8.x and hundreds of RHEL 8.x Linux servers directly AD integrated to our
> corp AD domain.
>
> I compared our sssd.conf with yours.  I think you want to add the 'ifp'
> service for *L8.  It's the infopipe service.  Used by support utilities
> such as sssctl domain-list, etc.
>
> I thought you had to have a sssd.conf stanza for each service you enable.
> For instance, we have this:
>
> [nss]
> debug_level = 0x0100
> #debug_level = 9
> filter_groups = root
> filter_users = root
>
> [pam]
> pam_verbosity = 3
> #debug_level = 9
> offline_credentials_expiration = 3
>
> [ifp]
>
> Because we have
>
> [sssd]
>
> ...
>
> services = nss,pam,ifp
>
> From your ldap_child.log, it looks like your SASL bind and then the LDAP
> query is working.  Which is surprising to me.  We set up
>
> ldap_sasl_authid = host/<fqdn>@<ad domain>
>
> in our sssd.conf file.  But I'm guessing if that's not explicitly set, it
> uses HOSTNAME$@REALM.  At least that's what it appears from your
> ldap_child.log. It appears to use:  TEST0003$@ourlab.se
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fourlab.se%2F&data=04%7C01%7Caron.kelemen%40stralfors.se%7Cee4423c7606c4b41204308d9aabb6635%7C91f09566a8504faebbe129ad3804a2f6%7C1%7C1%7C637728544138573813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aOUkFrUQ067nE%2BpYXJ5S2o%2BnFBsq81bT%2FohpsjkPX50%3D&reserved=0
>
> Several things to try to narrow down where the failure is occuring.
> try 'kinit -k'  on the command line.   That uses the first entry in
>
> /etc/krb5.keytab file to attempt to authenticate as this machine account.
> It's not a perfect test, since it's acquiring a TGT ticket instead of a
> service ticket.
>
> If that succeeds, try kvno -S host TEST0003
>
> That should report the KVNO of your machine account credentials, as
>
> stored in AD.  This is a better test, as you're acquiring a service ticket
> here.  (Like sssd does).
> Try 'adcli testjoin -D ourlab.se
>
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fourlab.se%2F&data=04%7C01%7Caron.kelemen%40stralfors.se%7Cee4423c7606c4b41204308d9aabb6635%7C91f09566a8504faebbe129ad3804a2f6%7C1%7C1%7C637728544138583805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qG%2BMWmyeGr6Z4%2Fw7dIY4F77u21DJvpOW4oTsSy5C0ds%3D&reserved=0
> -v'.  This tests the sssd connectivity, similar to how sssd does it.
>
> if all that works, your problem is not with LDAP or your SASL binding.  So
> then,
> try 'getent passwd [e-mail]'.  That should return the
>
> entry for this user.  If this fails, possibly your /etc/nsswitch.conf file
> isn't set up right or maybe your attribute mapping in AD isn't agreeing
> with your sssd.conf setting.  (We use the MS-supported RFC2307bis AD schema
> extension)..
> If that's good, then probably the problem is something in your PAM
>
> stack.  Specifically, the auth phase.   In our /etc/pam.d/sshd file, we
> have:
>
> #%PAM-1.0
> auth       substack     password-auth
> auth       include      postlogin
>
> ...
>
> and in password-auth, we have:
>
> auth        required                                     pam_env.so
> # OL7/8 version. Per I/T's stated policy for service & process accounts,
> lock-out time = 30 mins
> auth        required                                     pam_faillock.so
> preauth silent deny=5 unlock_time=1800
> auth        sufficient                                   pam_sss.so
> forward_pass
> auth        sufficient                                   pam_unix.so
> nullok try_first_pass
> auth        requisite                                    pam_succeed_if.so
> uid >= 1000 quiet_success
> auth        required                                     pam_faillock.so
> authfail deny=5 unlock_time=1800
> auth        required                                     pam_deny.so
>
> Spike
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure