All credit goes to James Forshaw for doing all the researches
When you trying to relaying Kerberos, one hurdle is that the TARGET of Authentication is pre-defined with TGS-REQ, which is a SPN or UPN.
Security Support Provider Interface
(SSPI) A common interface between transport-level applications, such as Microsoft Remote Procedure Call (RPC), and security providers, such as Windows Distributed Security. SSPI allows a transport application to call one of several security providers to obtain an authenticated connection. These calls do not require extensive knowledge of the security protocol's details.
reference :
https://learn.microsoft.com/en-us/windows/win32/secauthn/authentication-functions
https://learn.microsoft.com/en-us/windows/win32/api/sspi/nf-sspi-initializesecuritycontextw
https://shenaniganslabs.io/2019/11/12/Ghost-Potato.html
https://learn.microsoft.com/en-us/windows/win32/secauthn/sspi-kerberos-interoperability-with-gssapi
// InitializeSecurityContext Function
KSECDDDECLSPEC SECURITY_STATUS SEC_ENTRY InitializeSecurityContextW(
[in, optional] PCredHandle phCredential,
[in, optional] PCtxtHandle phContext,
[in, optional] PSECURITY_STRING pTargetName,
[in] unsigned long fContextReq,
[in] unsigned long Reserved1,
[in] unsigned long TargetDataRep,
[in, optional] PSecBufferDesc pInput,
[in] unsigned long Reserved2,
[in, out, optional] PCtxtHandle phNewContext,
[in, out, optional] PSecBufferDesc pOutput,
[out] unsigned long *pfContextAttr,
[out, optional] PTimeStamp ptsExpiry
);
InitializeSecurityContext (General) returns a token that the client must pass to the remote peer, which the peer in turn submits to the local security implementation through the AcceptSecurityContext (General) call. The token generated should be considered opaque by all callers.
To set up authentication in the SSPI client