not getting cached ticket from PuTTY login

[Pieter Voet]

Hi all,

I have the same issue as was already reported here in 2016 : https://lists.fedorahosted.org/archives/list/[e-mail].o...
however there was no reply given.

Running sssd on RedHat linux 7 using 'ad' as the 'auth_provider' I succesfully get logged in using Putty from a Windows laptop.
However, running 'klist' returns :

klist: Credentials cache keyring 'persistent:808521:krb_ccache_x2hJGE1' not found

I found articles like 'https://ubuntu.com/server/docs/service-sssd-ad' where it said to install 'krb5-user' 
if you want your AD users to also get a kerberos ticket upon logging in. But that is valid for Ubuntu, and there's no
'krb5-user' package for Redhat.  Next I found the RH equivalent should be 'krb5-auth-dialog' , but that's not available 
for RedHat 7.

Can anybody help me on getting a kerberos ticket if logged on by sssd ?

Thanks !

[Alexey Tikhonov]

Hi,

On Fri, Mar 24, 2023 at 10:03 PM Pieter Voet  wrote:
> Hi all,
>
> I have the same issue as was already reported here in 2016 : https://lists.fedorahosted.org/archives/list/[e-mail].o...
> however there was no reply given.
>
> Running sssd on RedHat linux 7 using 'ad' as the 'auth_provider' I succesfully get logged in using Putty from a Windows laptop.

Is the issue specific to logging in using 'Putty'?
Or is a ticket missing when you login using other methods as well
(ssh, console...)?
> However, running 'klist' returns :
>
> klist: Credentials cache keyring 'persistent:808521:krb_ccache_x2hJGE1' not found
>
> I found articles like 'https://ubuntu.com/server/docs/service-sssd-ad' where it said to install 'krb5-user'
> if you want your AD users to also get a kerberos ticket upon logging in. But that is valid for Ubuntu, and there's no
> 'krb5-user' package for Redhat.  Next I found the RH equivalent should be 'krb5-auth-dialog' , but that's not available
> for RedHat 7.
>
> Can anybody help me on getting a kerberos ticket if logged on by sssd ?
>
> Thanks !
> _______________________________________________
> 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

[Pieter Voet]

Hi Alexey,  thanks for responding !

I tried 'ssh' to logon..  I need to specifiy my (AD) password then, but yes, after I'm logged on 'klist'  succesfully lists my TGT. Cool !

But the goal here is to login using SSO from Windows to Linux using Putty. My understanding is that SPNego is involved,
and hence Kerberos credentials, but I'm missing the overall picture on how sssd handles authentication in this case.

I'm reading a lot on 'sssd' , including the source-code from GIT.  I cannot figure out which component is supposed to give 
a SSO-ed user a Kerberos ticket..   ( sssd_ad ? sssd_ldap ?  sssd_pam ? )
Next, I tried to change the 'auth_provider' to 'krb5' , but that didn't give me a TGT either..

I appreciate any help..  Thanks in advance !

[Pieter Voet]

Well ,  Alexey triggered something in my head :-)

Since Putty behaviour was different than ssh, I started looking into the Putty configuration...
and there we go !  In Settings -> Connection -> SSH -> Auth -> GSSAPI  there was an option
called 'Allow GSSAPI credential delegation' ...

enabling this option got it to work !  Cool !  I now get a Kerberos TGT !

Thanks Alexey for the lead !

[Pieter Voet]

OK.. too stupid !   I forgot to clear the credentials using 'kdestroy -A'  before retrying with Putty..

so, the original problem is still there...  I don't get a Kerberos ticket if logging on to Linux from Windows using Putty.

[Spike White]

Pieter,

We use GSSAPI instead of  GSS-SPNEGO for ssh SSO, but it should work the
same.  This does not really involve sssd at all (for the authentication).
What happens is that your ssh daemon is Kerberos-aware.  So when it is
presented with a Kerberos ticket, the ssh daemon contacts the Kerberos
server (AD DC in our case) to verify the ticket.  If authenticated, it
allows login.  That is, it bypasses PAM for the 'authentication' phase.  It
still consults PAM stack for the 'account' and 'session' phases however,

Because the sshd service in this situation does not call PAM stack for the
authentication phase, it does not consult pam_sss during the authentication
phase.   For your account phase and session phase, it will consult pam_sss,
but that doesn't involve kerberos.

I am looking at my (Windows) putty to (Linux) ssh login.  Yes, it SSO's to
Linux just fine.  But once on the Linux server, I see I don't have a
Kerberos ticket.  I've never noticed that before,  as we essentially never
ssh SSO linux to linux,   Always run 'new session' off the existing putty
session to pop to a new Linux server.

Years ago, I know we used to have a Kerberos ticket when we SSH SSO'd in,
so then we could SSO Linux to Linux.  Don't know when that disappeared.

Spike

On Sun, Mar 26, 2023 at 3:41 PM Pieter Voet  wrote:
> OK.. too stupid !   I forgot to clear the credentials using 'kdestroy -A'
> before retrying with Putty..
>
> so, the original problem is still there...  I don't get a Kerberos ticket
> if logging on to Linux from Windows using Putty.
> _______________________________________________
> 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

[Pieter Voet]

Thanks for your elaboration on this Spike !  This'll help me understand  the functional picture ...

[Sam Morris]

On 26/03/2023 22:31, Spike White wrote:
> We use GSSAPI instead of  GSS-SPNEGO for ssh SSO, but it should work the 
> same.  This does not really involve sssd at all (for the 
> authentication).  What happens is that your ssh daemon is 
> Kerberos-aware.  So when it is presented with a Kerberos ticket, the ssh 
> daemon contacts the Kerberos server (AD DC in our case) to verify the 
> ticket.  If authenticated, it allows login.  That is, it bypasses PAM 
> for the 'authentication' phase.  It still consults PAM stack for the 
> 'account' and 'session' phases however,
>
> Because the sshd service in this situation does not call PAM stack for 
> the authentication phase, it does not consult pam_sss during the 
> authentication phase.   For your account phase and session phase, it 
> will consult pam_sss, but that doesn't involve kerberos.

Have you enabled Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI 
credential delegation?

[Pieter Voet]

Hi Sam,
> Have you enabled Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI

credential delegation?
yes I did.  That did not solve the issue, but since this is on a corporate AD domain, I do not have the permission to 
check if the Windows laptop has 'Trust this computer for delegation to any service (Kerberos only)'  permission...

I'm currently creating an Windows Server with AD sandbox to try recreate this ...

[Sam Morris]

On 27/03/2023 12:53, Pieter Voet wrote:
> Hi Sam,
> > Have you enabled Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI
>
> credential delegation?
> yes I did.  That did not solve the issue, but since this is on a corporate AD domain, I do not have the permission to
> check if the Windows laptop has 'Trust this computer for delegation to any service (Kerberos only)'  permission...

I don't think that the computer you're SSHing from will affect whether 
delegation is possible. I think the TGT has to have the 'forwardable' 
flag on it?

[Pieter Voet]

On the Windows laptop, I  opened up a CMD windows and entered 'klist'..
All tickets listed there have Ticket Flags 'forwardable'..

[Spike White]

Pieter,

I have Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI -> credential
delegation turned on in putty.

As well as on the target Linux server, it has [libdefaults] forwardable =
true.  The error I get when I ssh in is:

[admspike_white@austgcore17 ~]$ klist
klist: Credentials cache 'KCM:2025431' not found
[admspike_white@austgcore17 ~]$

where 2025431 is my UID.

Spike

On Mon, Mar 27, 2023 at 1:36 PM Pieter Voet  wrote:
> On the Windows laptop, I  opened up a CMD windows and entered 'klist'..
> All tickets listed there have Ticket Flags 'forwardable'..
> _______________________________________________
> 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

[James Ralston]

On Mon, Mar 27, 2023 at 4:02 PM Spike White  wrote:
> Pieter,
>
> I have Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI ->
> credential delegation turned on in putty.
>
> As well as on the target Linux server, it has [libdefaults]
> forwardable = true.  The error I get when I ssh in is:
>
> [admspike_white@austgcore17 ~]$ klist
> klist: Credentials cache 'KCM:2025431' not found
> [admspike_white@austgcore17 ~]$
>
> where 2025431 is my UID.

PuTTY uses the Windows Kerberos libraries, which means it obeys their
restrictions.  One of those restrictions is that credentials may only
be delegated to a host whose UserAccountControl attribute (on the
host’s AD user account object) has the TRUSTED_FOR_DELEGATION flag
set.  See:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/usera...

If the target host does not have the TRUSTED_FOR_DELEGATION flag set
on its UserAccountControl attribute, PuTTY silently refuses to
delegate credentials.

In contrast, MIT Kerberos (which OpenSSH typically links against) is
not AD-aware, so neither ssh nor sshd pay any attention to the target
host’s UserAccountControl attribute when deciding to forward (or
accept forwarded) credentials.

If you can query your AD domain, you can decipher the
UserAccountControl attribute of the target host user object.  E.g.:

Not set (WORKSTATION_TRUST_ACCOUNT only):

userAccountControl: 4096

Set (WORKSTATION_TRUST_ACCOUNT + TRUSTED_FOR_DELEGATION):

userAccountControl: 528384

[Pieter Voet]

Hi James,   thanks a lot for your interesting reply..

in order to investigate this issue, I've set up an Windows Server 2012 evaluation copy on my Linux laptop as an VM using QEMU.
With that, I also added two more VM's : a Windows 10 client and a Linux Fedora 37 server with sssd configured and both VMs joined to the Active Directory domain.

I now can login to the Windows 10 VM using my AD account and password. 
Next I use Putty ( with 'Allow GSSAPI Credential Delegation'  enabled ) to get to the Linux server, and I get logged in without specifying a password, because sshd is configured to allow GSSAPIAuthentication and detected a valid Kerberos ticket.
And then :  yesss !    'klist'  showed that I have a valid Kerberos ticket !

While reading your post, I looked at the Linux machine object using Adsiedit.msc...

this is the userAccountControl for that server :  0x11000 = ( WORKSTATION_TRUST_ACCOUNT | DONT_EXPIRE_PASSWORD)

umm..  the TRUSTED_FOR_DELEGATION flag is not set, but still , Putty login gives me a TGT.
This does not match your explanation..  Am I doing something not right ?

Thanks !

[Spike White]

Pieter,

I was playing around with this also.    I was setting
TRUSTED_FOR_DELEGATION on the machine account as well.  And it was
accomplishing nothing.

I'm guessing it's the user's account that needs to have
TRUSTED_FOR_DELEGATION.  Not the machine account.

So when you start putty, you start it under a particular account.  (I have
to do a 'RunAs' to start putty under the desired account).  I think putty
is looking at the userAccountControl attribute of this user account.  To
decide whether to delegate credentials.   (Also, the putty config setting
"allow delegate credentials" has to be set).

My user account has userAccountControl == NORMAL_ACCOUNT.

Spike

On Tue, Mar 28, 2023 at 6:34 AM Pieter Voet  wrote:
> Hi James,   thanks a lot for your interesting reply..
>
> in order to investigate this issue, I've set up an Windows Server 2012
> evaluation copy on my Linux laptop as an VM using QEMU.
> With that, I also added two more VM's : a Windows 10 client and a Linux
> Fedora 37 server with sssd configured and both VMs joined to the Active
> Directory domain.
>
> I now can login to the Windows 10 VM using my AD account and password.
> Next I use Putty ( with 'Allow GSSAPI Credential Delegation'  enabled ) to
> get to the Linux server, and I get logged in without specifying a password,
> because sshd is configured to allow GSSAPIAuthentication and detected a
> valid Kerberos ticket.
> And then :  yesss !    'klist'  showed that I have a valid Kerberos ticket
> !
>
> While reading your post, I looked at the Linux machine object using
> Adsiedit.msc...
>
> this is the userAccountControl for that server :  0x11000 = (
> WORKSTATION_TRUST_ACCOUNT | DONT_EXPIRE_PASSWORD)
>
> umm..  the TRUSTED_FOR_DELEGATION flag is not set, but still , Putty login
> gives me a TGT.
> This does not match your explanation..  Am I doing something not right ?
>
> Thanks !
> _______________________________________________
> 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

[Spike White]

Pieter,

Never mind.  I am wrong.  restarted sssd and waited for AD replication.
Setting TRUSTED_FOR_DELEGATION on the machine account is sufficient.

I now get a Kerberos cred when I SSH SSO (via Putty) onto Linux server.

Spike

On Tue, Mar 28, 2023 at 3:06 PM Spike White  wrote:
> Pieter,
>
> I was playing around with this also.    I was setting
> TRUSTED_FOR_DELEGATION on the machine account as well.  And it was
> accomplishing nothing.
>
> I'm guessing it's the user's account that needs to have
> TRUSTED_FOR_DELEGATION.  Not the machine account.
>
> So when you start putty, you start it under a particular account.  (I have
> to do a 'RunAs' to start putty under the desired account).  I think putty
> is looking at the userAccountControl attribute of this user account.  To
> decide whether to delegate credentials.   (Also, the putty config setting
> "allow delegate credentials" has to be set).
>
> My user account has userAccountControl == NORMAL_ACCOUNT.
>
> Spike
>
> On Tue, Mar 28, 2023 at 6:34 AM Pieter Voet  wrote:
> > Hi James,   thanks a lot for your interesting reply..
> >
> > in order to investigate this issue, I've set up an Windows Server 2012
> > evaluation copy on my Linux laptop as an VM using QEMU.
> > With that, I also added two more VM's : a Windows 10 client and a Linux
> > Fedora 37 server with sssd configured and both VMs joined to the Active
> > Directory domain.
> >
> > I now can login to the Windows 10 VM using my AD account and password.
> > Next I use Putty ( with 'Allow GSSAPI Credential Delegation'  enabled )
> > to get to the Linux server, and I get logged in without specifying a
> > password, because sshd is configured to allow GSSAPIAuthentication and
> > detected a valid Kerberos ticket.
> > And then :  yesss !    'klist'  showed that I have a valid Kerberos
> > ticket !
> >
> > While reading your post, I looked at the Linux machine object using
> > Adsiedit.msc...
> >
> > this is the userAccountControl for that server :  0x11000 = (
> > WORKSTATION_TRUST_ACCOUNT | DONT_EXPIRE_PASSWORD)
> >
> > umm..  the TRUSTED_FOR_DELEGATION flag is not set, but still , Putty
> > login gives me a TGT.
> > This does not match your explanation..  Am I doing something not right ?
> >
> > Thanks !
> > _______________________________________________
> > 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

[Pieter Voet]

Hi Spike,

thanks a lot for your findings ! I appreciate your effort.

I also played around with the TRUSTED_FOR_DELEGATION flag on the machine account, and yes
it looks like the behaviour is consistent.
( I had a case where I got a TGT without the TRUSTED_FOR_DELEGATION flag set on the machine account,
  but I'm not sure if sssd and sshd where restarted correctly.. )

So, that should be it...  I now have to get to the Active Directory department on my corporate environment
and ask them to set the flag for me, because it seems that only Administrator can set the flag ( if not customized ),
even if you ( a non-Administrator account owns the machine account...).

Thanks everybody for all the help provided !

Have a nice day !

[James Ralston]

On Wed, Mar 29, 2023 at 5:01 PM Pieter Voet  wrote:
> So, that should be it... I now have to get to the Active Directory
> department on my corporate environment and ask them to set the flag
> for me, because it seems that only Administrator can set the flag (
> if not customized ), even if you ( a non-Administrator account owns
> the machine account...).

My understanding (which could be incorrect, as I am not a Windows
admin) is that this is exactly the point.

The ability to join hosts to the domain is often delegated fairly
loosely.  For example, in our organization, various groups have the
ability to join hosts into specific OUs.  Therefore, just because a
random host is joined to the domain doesn’t necessarily mean that it
should be trusted to receive delegated credentials.

By creating a separate flag to indicate whether a host can be trusted
to receive delegated credentials, and then permitting domain admins to
specify who can set that flag on what OUs, this permits
differentiating hosts that are simply joined to the domain versus
hosts that are joined to the domain and operated by admins who can be
trusted not to exfiltrate credentials delegated to their hosts.

Of course, for our environment, this backfired horribly, as we use
NFSv4 home directories with sec=krb5p everywhere, which means that for
a remote login, you must either delegate a credential or use
keyboard-interactive authentication in order to acquire a new
credential.  When PuTTY was configured to use GSSAPI authentication,
users wouldn’t have access to their NFS home directory after logging
into a Linux host, because PuTTY would refuse to delegate the
credential necessary to access it.

Until we finally figured out that the target host needed to have the
TRUSTED_FOR_DELEGATION flag in order for PuTTY to delegate the damn
credential, our work-around was to tell Windows users to disable
GSSAPI authentication and just use password authentication (plus Duo
MFA) whenever they needed to ssh into a Linux host.  So, effectively,
in order to avoid giving a (potential, hypothetical) rogue admin a
delegated credential, we were forced to give that same rogue admin…
the actual user’s password.  Whee.