Curiosity question about sssd with a Kerberos/LDAP or AD back-end

[Spike White]

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 [e-mail]
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.

Spike

[Alexey Tikhonov]

Hi,

On Wed, Feb 26, 2025 at 5:07 PM Spike White via sssd-users
 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.

[Spike White]

Alexey,

if you look in /etc/ssh/sshd_config, there's numerous directives concerning
GSSAPI auth.

# GSSAPI options

GSSAPIAuthentication yes

GSSAPICleanupCredentials yes

#GSSAPIStrictAcceptorCheck yes

#GSSAPIKeyExchange no

#GSSAPIEnablek5users no

So sshd knows natively about GSSAPI auth. Don't think it's using any PAM
stack for GSSAPI (auth phase).

Surely using PAM stack for account and session phases however.

Spike

On Wed, Feb 26, 2025 at 10:30 AM Alexey Tikhonov 
wrote:
> Hi,
>
> On Wed, Feb 26, 2025 at 5:07 PM Spike White via sssd-users
>  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.

[Alexander Bokovoy]

On Срд, 26 лют 2025, Spike White via sssd-users wrote:
> Alexey,
>
> if you look in /etc/ssh/sshd_config, there's numerous directives concerning
> GSSAPI auth.
>
> # GSSAPI options
>
> GSSAPIAuthentication yes
>
> GSSAPICleanupCredentials yes
>
> #GSSAPIStrictAcceptorCheck yes
>
> #GSSAPIKeyExchange no
>
> #GSSAPIEnablek5users no
>
> So sshd knows natively about GSSAPI auth. Don't think it's using any PAM
> stack for GSSAPI (auth phase).

When GSSAPI authentication is used against a service, the service
doesn't get access to the user's TGT unless it is explicitly delegated
by a client. The latter is not done by default. So when SSH server
authenticates the client with GSSAPI, by default it does not need to
have access to any credentials cache because it has nothing to save
there. This explains why it doesn't need to access KCM:.
> Surely using PAM stack for account and session phases however.
>
> Spike
>
> On Wed, Feb 26, 2025 at 10:30 AM Alexey Tikhonov 
> wrote:
> > Hi,
> >
> > On Wed, Feb 26, 2025 at 5:07 PM Spike White via sssd-users
> >  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.

[Sumit Bose]

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 [e-mail]
> 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 -- [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, report it: https://pagure.io/fedora-infrastructure/new_issue