Hi, On Wed, Feb 26, 2025 at 5:07 PM Spike White via sssd-users <[email protected]> wrote: > > 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.
'krb5_child' (invoked by 'sssd_be' by request from 'sssd_pam' by request from 'pam_sss.so') fails to store TGT. > 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. I don't know if sshd uses 'pam_sss_gss.so', but that way or another, I guess there is no need to acquire and store TGT on user behalf. -- _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
