Support for Credential Guard about win32-openssh HOT 7 OPEN

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

from win32-openssh.

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?

from win32-openssh.

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).

from win32-openssh.

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

from win32-openssh.

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?

from win32-openssh.

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.)

from win32-openssh.

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.

from win32-openssh.