asp.net WindowsImpersonationContext函数 [英] asp.net WindowsImpersonationContext function

问题描述

任何人都可以解释下面几行的功能:

Can anyone please explain the function of the lines below:

WindowsIdentity wId = (WindowsIdentity)HttpContext.Current.User.Identity;
WindowsImpersonationContext wIdCon = wId.Impersonate();

用于具有IIS基本身份验证的POST方法，并且工作正常. 但是，如果将IIS身份验证设置为Windows，则以上操作将不再起作用.

That is used on a POST method with IIS basic authentication and works fine. If however the IIS authentication is set to windows the above no longer works.

示例中有太多代码可以转储.

There is simply way too much code to dump for an example.

推荐答案

对Impersonate()的调用使IIS从那时起就伪装成发出请求的用户.出于多种原因，这很有用，主要是，后续代码仅在不拒绝发出请求的用户访问的情况下才起作用.

The call to Impersonate() makes IIS pretend to be the requesting user from that point on. This is useful for a number of reasons, chiefly that the subsequent code will only work if the requesting user is not denied access.

这对于基本而言有效，因为为网站提供了用户名和密码，因此可以以用户身份登录. Windows身份验证失败，因为它使用kerberos，并且仅获得引用用户的票证，而不是用户密码.

This works for basic because the website is given the username and password and can therefore login as the user. Windows authentication is failing becuase it uses kerberos and is only given a ticket refering the the user - not the users password.

要使Windows身份验证有效，您需要允许网站帐户(该帐户是您应用程序的应用程序池标识)允许模拟用户使用.这是在其Active Directory中帐户的委派标签中完成的.

To get Windows authentication to work, you need to allow the website account (the one that is the app pool identity for your application) to impersonation users. This is done in the delegation tab of their account in Active Directory.

如果他们没有委托选项卡，则首先需要添加SPN(服务主体名称). SPN允许客户知道哪个帐户正在运行该网站，以及如何加密到kerberos票证，以便该网站可以打开它.只要客户和服务器都信任第三方(标准MS实施中的AD服务器)，这就是允许客户端和服务器进行对话而无需彼此告诉对方密码的一种方式.

If they don't have a delegation tab, you first need to add an SPN (a Service Principal Name). The SPN allow clients to know which account is running the website and therefore how to encrypt to kerberos ticket such that the website can open it. It's all a way of allowing client and server to talk without every telling each other their passwords as long as they both trust a 3rd party (the AD server in the standard MS implementation).

这都是一个常见的问题，被称为kerberos double hop.这一切都源于以下事实:从客户端到网站的Kerberos有效(网站对客户端用户凭据的了解足够多，可以服务页面等)，但是没有给出从网站到需要Web用户凭据的资源的第二跳他们作为网站帐户是不允许的.有关更多信息，请参见 understanding-kerberos -msdn上的双跳

This is all part of a common problem known as kerberos double hop. it all stems from the fact that Kerberos from the client to the website works (the website knows enough about the client users credentials to serve pages etc) but the 2nd hop from the website to the resource that requires the web users credentials is not being given them as the website account is not allowed to. For more info see understanding-kerberos-double-hop on msdn

尝试运行setspn /q http/machine_name_or_fqdn例如

setspn /q http/mywebbox
setspn /q http/mywebbox.my.domain.com

setspn /q http/mywebbox
setspn /q http/mywebbox.my.domain.com

这些spn反对哪个用户? IIS需要以与SPN相同的用户身份运行网站的appPool.

Which user are these spn's set against? IIS needs to have the appPool for the website running as same user as the SPN.

一旦确认，我建议使用 fiddler 工具来检查之间传递的信息客户端和服务器-确认正在收到401错误响应(即，您需要进行身份验证)，并立即使用具有有效kerberos标头的请求重试.

Once you've confirmed that, I'd suggest using the fiddler tool to check what is passing between the client and the server - confirm that is getting a 401 error response (i.e. you need to authenticate) and immediately retrying with the request having a valid kerberos header.

一旦客户端通过kerberos与服务器对话，就需要确保已在AD中设置了appPool帐户，并允许其代表用户进行委派.

Once you've got the client to server talking via kerberos, you need to ensure the appPool account has been set in AD as allowed to delegate on behalf of users.

这篇关于asp.net WindowsImpersonationContext函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！