Support for Credential Guard

[3XX0]

trafficstars

Summary of the new feature / enhancement

Would it be possible to support SSPI unconstrained delegation with Credential Guard enabled?

Our users currently need to turn off Credential Guard in order to delegate their ticket which is far from ideal. When Credential Guard is enabled ssh won't perform delegation (sspi delegation was requested but not fulfilled), see https://github.com/PowerShell/Win32-OpenSSH/issues/1606 https://github.com/PowerShell/Win32-OpenSSH/issues/1295

This limitation is documented here: https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues#kerberos-considerations

I'm not very familiar with Credential Guard, but technically the initial TGT could stay in the vault. SSH only has to produce and send the forwarded TGT.

Proposed technical implementation details (optional)

No response

[jborean93]

AFAIK the limitation is with credential guard itself and is not something that ssh can override.

[matsmcp]

AFAIK the limitation is with credential guard itself and is not something that ssh can override.

I'm not skilled enough but why do SSH need the TGT? shouldn't it be enough to request a ordinary key?

[jborean93]

To request the key it needs to know the user's secret (it's password). An SSH private key is not related at all to the user's password so there's nothing to do. Kerberos delegation can get around this problem but it's specific to the Kerberos protocol and dependent on the ticket the user provides during authentication so SSH key auth can't really re-use it (without really opening up some holes like delegation with protocol transition).

[matsmcp]

To request the key it needs to know the user's secret (it's password). An SSH private key is not related at all to the user's password so there's nothing to do. Kerberos delegation can get around this problem but it's specific to the Kerberos protocol and dependent on the ticket the user provides during authentication so SSH key auth can't really re-use it (without really opening up some holes like delegation with protocol transition).

Thanks. I made a typo and meant ticket and not key, sorry about that

[mgkuhn]

Isn't the whole point of Credential Guard to prevent anyone from moving (stealing, passing) tickets elsewhere? And isn't the whole point of unconstrained delegation to move (forward, delegate) one's ticket elsewhere? So aren't these two simply exactly opposing functional requirements, and if Kerberos ticket forwarding does not work with Credential Guard enabled, then doesn't that simply mean that Credential Guard works exactly as designed and does its job correctly?

[mgkuhn]

It might be useful to extend Credential Guard to provide more fine-grained control over what kinds of credentials it covers or does not cover. For example, a “Windows credential” stored in Credential Manager (e.g. with cmdkey or the GUI) currently contains not just the user's short-term Kerberos ticket (which typically expires after a working day), and which you might want to keep easily accessible for unconstrained delegation, but also the user's long-term keytab (the hash of their password, possibly valid for many years), which you might want to protect well via Credential Guard, or not kept stored at all. At the moment, I understand you can either protect both or neither, which can be a bit inconvenient.

Alternative: What I really miss in Windows is an equivalent of the kinit command in MIT Kerberos. That uses the user's password only very briefly, just to get a ticket, and then destroys the password and its hash again immediately (e.g., a kinit password can't be recovered from a discarded disk drive). There sadly seems to be no equivalent command in Windows to obtain a Kerberos ticket without storing the (hash of the) password in Credential Manager. If kinit were available, there would be much less need for using anything like Credential Guard.

(But all of that is really outside this OpenSSH port.)

[3XX0]

Yes, again I'm not familiar with how Credential Guard works in details, but having fine-grained control would certainly help. Being able to do unconstrained delegation without having to turn it off would be nice.

Now, having said that, Credential Guard should be able to do TGS requests without taking the TGT out of the sandbox which is the whole point. With SSPI, technically you're trying to delegate a forwarded TGT (which could be constrained to some addresses and checked against OK-AS-DELEGATE) not the initial one. Security-wise it might not look so different, but depending on how SSPI and CG interact this might be implementable.