Am Wed, Feb 26, 2025 at 10:06:47AM -0600 schrieb Spike White via sssd-users:
All,
We notice that when sssd-kcm service is messed up and not running, password auth fails. Interestingly, Kerberos (GSSAPI auth still succeeds. Why?
So I know why password auth fails. In /etc/krb5.conf.d/kcm_default_cache, it has:
[libdefaults]
default_ccache_name = KCM:So in password auth, it is failing on the step of writing the Kerberos credential cache into the credentials store (KCM). I speculate that it’s specifically pam_sss.so in the auth phase that’s failing to do this.
You can see this failure on the command line:
[admspike_white@austgcore23 ~]$ kinit admspike_white@EXAMPLE.COM kinit: Connection refused while getting default ccache
I understand why password auth fails. My question is – why does Kerberos (GSSAPI) auth succeed?
My guess is that sshd handles GSSAPI auth internally and never calls the PAM stack in the “auth” phase. Only for the “account” and “session” phase. Thus pam_sss.so never gets invoked for the auth phase.
Hi,
yes, GSSAPI authentication is completely handled by the service, sshd in this case, no SSSD component gets in touch with this. And yes, sshd is calling the PAM stack for access control and session setup.
bye, Sumit
Spike
-- _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue