From seshan.parameswaran at oracle.com  Wed Oct 11 18:46:39 2023
From: seshan.parameswaran at oracle.com (Seshan Parameswaran)
Date: Wed, 11 Oct 2023 22:46:39 +0000
Subject: [External] : Re: Windows Credential Guard with MSLSA
In-Reply-To: <202309071725.387HP41J022246@hedwig.cmf.nrl.navy.mil>
References: <tsl7d56yuv0.fsf@suchdamage.org>
 <BYAPR10MB3479E8D157F4A9100FA7FA7A9DB49@BYAPR10MB3479.namprd10.prod.outlook.com>
 <BYAPR10MB347979C66F6BB72377D641429DEFA@BYAPR10MB3479.namprd10.prod.outlook.com>
 <tsl1qfbv3a8.fsf@suchdamage.org>
 <BYAPR10MB3479DDC2FF102C56220FA65A9DEFA@BYAPR10MB3479.namprd10.prod.outlook.com>
 <tsly1hjt3wp.fsf@suchdamage.org>
 <BYAPR10MB3479F89B6F62CCEC96189C6F9DEFA@BYAPR10MB3479.namprd10.prod.outlook.com>
 <PN2P287MB0381D486A44533588766B89BF6EEA@PN2P287MB0381.INDP287.PROD.OUTLOOK.COM>
 <BYAPR10MB347992FE12CC47CCCB5B5B659DEEA@BYAPR10MB3479.namprd10.prod.outlook.com>
 <202309071330.387DUg61019698@hedwig.cmf.nrl.navy.mil>
 <ZPnVczujAKYOKyaL@redhat.com>
 <202309071725.387HP41J022246@hedwig.cmf.nrl.navy.mil>
Message-ID: <BYAPR10MB3479518436C84B6976625D0A9DCCA@BYAPR10MB3479.namprd10.prod.outlook.com>

Hi
I have a follow up question on the client doesn?t forward the TGT.  If I set the user account on the AD directory host to support delegation, the client would send a forwardable TGT to the server.  The server then can use that TGT to obtain its own TGT and follow the rest of the steps as detailed below.  Please let me know if that is a possibility.

Thanks

Seshan

From: krbdev <krbdev-bounces at mit.edu> on behalf of Ken Hornstein via krbdev <krbdev at mit.edu>
Date: Thursday, September 7, 2023 at 10:30 AM
To: Alexander Bokovoy <abokovoy at redhat.com>
Cc: krbdev at mit.edu <krbdev at mit.edu>
Subject: Re: [External] : Re: Windows Credential Guard with MSLSA
>A sample implementation of S4U operations using raw Kerberos 5 API can
>be found in kvno utility source code.

I did see that!  But it is a little unclear to me how exactly that
works in an application server.

Hm, it is entirely possible I am overthinking it a bit; it seems
like the "normal" case is you just use the regular service ticket as
the evidence ticket.  So I guess that would look like:

- The client is unchanged (well, they don't foward a TGT)
- The application server gets a TGT for itself using it's own service key
  (tons of ways doing that) and places that in a credential cache.
- The application server takes the decrypted ticket from krb5_rd_req()
  (or the equivalent) and calls krb5_get_credentials_for_proxy() to
  perform the S4U2Proxy request.  Sadly, krb5_get_credentials_for_proxy()
  is not in the public krb5.h header file.  Sigh.

--Ken
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://urldefense.com/v3/__https://mailman.mit.edu/mailman/listinfo/krbdev__;!!ACWV5N9M2RV99hQ!OvZ8qr5KJ7Ep8DEPqLkUP0d6l4CrLPfpnBV53PovnoboTFwdu2r270M1c6NTxpMqVgG4gEFvNjyAFH7nNu441w$<https://urldefense.com/v3/__https:/mailman.mit.edu/mailman/listinfo/krbdev__;!!ACWV5N9M2RV99hQ!OvZ8qr5KJ7Ep8DEPqLkUP0d6l4CrLPfpnBV53PovnoboTFwdu2r270M1c6NTxpMqVgG4gEFvNjyAFH7nNu441w$>