[20453] in Kerberos_V5_Development
Re: [External] : Re: Windows Credential Guard with MSLSA
daemon@ATHENA.MIT.EDU (Ken Hornstein via krbdev)
Thu Sep 7 13:26:36 2023
Message-ID: <202309071725.387HP41J022246@hedwig.cmf.nrl.navy.mil>
To: Alexander Bokovoy <abokovoy@redhat.com>
cc: krbdev@mit.edu
In-Reply-To: <ZPnVczujAKYOKyaL@redhat.com>
MIME-Version: 1.0
Date: Thu, 07 Sep 2023 13:25:04 -0400
From: Ken Hornstein via krbdev <krbdev@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
