使用SSPI支持多进程的kerberos约束委派 [英] support kerberos constrained delegation using SSPI for multiprocess

问题描述

我需要使用SSPI在Windows上为我们的C ++ HTTP服务器产品支持Kerberos约束委派.

I need to support Kerberos constrained delegation for our C++ HTTP server product on Windows using SSPI.

对于单个流程服务器，可以使用follow工作流程，并且我有一个有效的原型. 1)调用AcquireCredentialsHandle 2)调用AcceptSecurityContext 3)调用ImpersonateSecurityContext 4)做委派 5)调用RevertSecurityContext

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

但是，C ++ HTTP服务器具有一个主进程和一个辅助进程.这两个进程都在同一台计算机上运行并使用相同的服务帐户，并且每个客户端请求都可以来自不同的用户.主进程可以使用AcquireCredentialsHandle和AcceptSecurityContext处理SPNEGO和Kerberos身份验证，但是它不知道需要委派哪个资源，只有工作进程才知道. 我可以使用哪些SSPI将客户端的安全上下文转发给工作人员，以便工作人员可以进行模拟/委派?

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?

似乎一种可能的解决方案是在主服务器中获取客户的身份，然后将其转让给工作人员.然后在工作进程中使用LsaLogonUser和ImpersonateLoggedOnUser.但是，由于LsaLogonUser允许不使用密码登录，因此我们的安全专家强烈反对使用它.

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还具有ExportSecurityContext和ImportSecurityContext，但是文档非常模糊，不确定是否可以解决我的用例.由于ImpersonateSecurityContext文档说它允许服务器使用以前通过调用AcceptSecurityContext(常规)或QuerySecurityContextToken所获得的令牌来模拟客户端".似乎我不能在ImportSecurityContext之后调用ImpersonateSecurityContext.

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.

任何建议都值得赞赏.

推荐答案

您需要做的是在父进程中获取令牌的句柄，并将其复制到子进程中.

What you need to do is get a handle to a token in the parent process and duplicate it into the child process.

您可以这样操作:

在父进程中，通常会调用ImpersonateSecurityContext.这将设置您的身份.然后调用QuerySecurityContextToken获取该标识令牌的句柄.一旦有了句柄调用DuplicateHandle，但是目标进程是子进程的句柄.返回的lpTargetHandle是 target 进程(子进程)中本地引用的句柄.您将了解如何将该值转移到目标进程.

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.

一旦子进程具有句柄值，您可以调用ImpersonateLoggedOnUser传递句柄值.此时，本地身份应该是有问题的用户，在创建新上下文时，所有外拨电话都将使用该本地身份.

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.

请记住，尽管子进程将需要SeImpersonatePrivilege.

Keep in mind though that the child process will need the SeImpersonatePrivilege.

这篇关于使用SSPI支持多进程的kerberos约束委派的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！