support kerberos constrained delegation using SSPI for multiprocess - sspi

Question

I need to support Kerberos constrained delegation for our C++ HTTP server product on Windows using SSPI.
For a single process server, the follow workflow can be used and I have a working prototype.
1) Call AcquireCredentialsHandle
2) Call AcceptSecurityContext
3) Call ImpersonateSecurityContext
4) Do delegation
5) Call RevertSecurityContext
However, the C++ HTTP server has a master process and a worker process. Both processes run on the same machine and use the same service account, and each client request can come from a different user. The master process can handle SPNEGO and Kerberos authentication using AcquireCredentialsHandle and AcceptSecurityContext, but it has no knowledge of which resource it needs to delegate, only the worker process has the knowledge.
Which SSPIs can I use to forward the client's security context to the worker so that the worker can do impersonation/delegation?
Seems one possible solution is to get client's identity in the master, transfer that to the worker; then in the worker use LsaLogonUser and ImpersonateLoggedOnUser. However, since LsaLogonUser allows logon without password, our security expert is strongly against the use of it.
SSPI also has ExportSecurityContext and ImportSecurityContext, but the documentation is very vague and not sure if it can address my use case. Since the ImpersonateSecurityContext documentation says it "allows a server to impersonate a client by using a token previously obtained by a call to AcceptSecurityContext (General) or QuerySecurityContextToken.", seems I can't call ImpersonateSecurityContext after ImportSecurityContext.
Any suggestion is appreciated.

Answer 1

What you need to do is get a handle to a token in the parent process and duplicate it into the child process.
You do it this way:
In the parent process call ImpersonateSecurityContext as you normally would. This will set your identity. Then call QuerySecurityContextToken to get a handle to the token of that identity. Once you have the handle call DuplicateHandle, but where the target process is a handle to the child process. The returned lpTargetHandle is a locally referenced handle in the target process (the child). You will some how need to transfer this value to the target process.
Once the child process has the handle value you can call ImpersonateLoggedOnUser passing the handle value. At this point the local identity should be the user in question and any outbound calls will use that when creating the new context.
Keep in mind though that the child process will need the SeImpersonatePrivilege.