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,

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 pietervoet@nl.ibm.com 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 -- 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

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?

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,

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 pietervoet@nl.ibm.com 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 -- 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

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 !

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 spikewhitetx@gmail.com 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 pietervoet@nl.ibm.com 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 -- 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

On Wed, Mar 29, 2023 at 5:01 PM Pieter Voet pietervoet@nl.ibm.com 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.