[External] : Re: Windows Credential Guard with MSLSA

Alexander Bokovoy abokovoy at redhat.com
Thu Sep 7 09:51:47 EDT 2023

On Чцв, 07 вер 2023, Ken Hornstein via krbdev wrote:
>>Windows Credential Guard cannot be used on Linux.  However the service
>>that Windows Credential Guard is protecting, a database service
>>running on Linux in this case, whether there is a way to retrieve the
>>credentials protected by Windows Credential Guard without using GSSAPI
>So I was mildly curious and I did some more digging.  Here's what I
>believe to be true, with the caveat I am not that experienced in the
>details and I might be wrong (and I would appreciate any corrections
>where I get things wrong):
>- The MIT Kerberos 5 libraries do have native support for doing S4U2proxy
>  which I believe is the protocol you want to use.

A sample implementation of S4U operations using raw Kerberos 5 API can
be found in kvno utility source code.

>- The specific details here is you need to send an "evidence ticket"
>  from the client to the server (which in test example I see is just
>  the complete ASN.1-encoded Kerberos service ticket for the database
>  server), the application server (the database service running on the
>  Linux system), the database service would call krb5_decode_ticket()
>  and krb5_server_decrypt_ticket_keytab() to get the the decrypted
>  ticket contents, and then call krb5_get_credentials_for_proxy() to
>  make the actual S4U2Proxy request (the database server will also have
>  to have a TGT for itself).
>- I'm actually a little unclear how you'd do the "send a raw ticket
>  from the client to the server" inside of the GSSAPI.  I suspect it
>  is possible but the MIT documentation just talks about the application
>  server API pieces.
>- As I mentioned previously, this would require client-server protocol
>  rework AND significant changes on the database server side.  If we
>  are talking about Oracle (just a guess based on your email address)
>  I was under the impression that Oracle includes a very old copy of MIT
>  Kerberos internally; if that is still the case then this would also
>  require the Kerberos implementation inside of Oracle to be updated
>  to something much newer.

With the changes to S4U protocol to tighten up processing due to
security issues in Active Directory, there are certain requirements
towards Kerberos services performing S4U. In short, when operating in AD
environment, you need to support PAC options buffers and certain
behavior. It is supported by recent MIT Kerberos and Heimdal Kerberos
versions so upgrade is due.

/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

More information about the krbdev mailing list