谁能解释一下下面几行的功能:
WindowsIdentity wId = (WindowsIdentity)HttpContext.Current.User.Identity;
WindowsImpersonationContext wIdCon = wId.Impersonate();
它用在带有 IIS 基本身份验证的 POST 方法上并且工作正常。 但是，如果 IIS 身份验证设置为 windows，则上述操作将不再有效。
对于示例来说，要转储的代码太多了。
最佳答案
对 Impersonate() 的调用使 IIS 从那时起假装是发出请求的用户。出于多种原因，这很有用，主要是后续代码仅在请求用户未被拒绝访问时才有效。
这适用于 basic，因为网站已获得用户名和密码，因此可以以用户身份登录。 Windows 身份验证失败，因为它使用 kerberos，并且只得到一张引用用户的票证，而不是用户密码。
要使 Windows 身份验证起作用，您需要允许网站帐户(即应用程序的应用程序池标识)模拟用户。这是在 Active Directory 中他们帐户的委派选项卡中完成的。
如果他们没有委派选项卡，您首先需要添加一个 SPN(服务主体名称)。 SPN 允许客户知道哪个帐户正在运行该网站以及如何加密到 kerberos 票据以便该网站可以打开它。只要客户端和服务器都信任第 3 方(标准 MS 实现中的 AD 服务器)，这就是允许客户端和服务器无需每次都告诉对方密码即可进行通信的一种方式。
这是称为 kerberos 双跃点的常见问题的一部分。这一切都源于这样一个事实，即从客户端到网站的 Kerberos 可以正常工作(该网站对客户端用户凭据足够了解以提供页面等)，但是没有给出从网站到需要 Web 用户凭据的资源的第二跳他们作为网站帐户是不允许的。有关详细信息，请参阅 understanding-kerberos-double-hop on msdn
编辑:
尝试运行 setspn/q http/machine_name_or_fqdn 例如
setspn /q http/mywebbox
setspn /q http/mywebbox.my.domain.com
这些 spn 是针对哪些用户设置的？ IIS 需要让网站的 appPool 以与 SPN 相同的用户身份运行。
一旦您确认了这一点，我建议您使用 fiddler检查客户端和服务器之间传递的内容的工具 - 确认收到 401 错误响应(即您需要进行身份验证)并立即重试具有有效 kerberos header 的请求。
一旦您让客户端通过 kerberos 与服务器通信，您需要确保已在 AD 中将 appPool 帐户设置为允许代表用户进行委派。
关于asp.net WindowsImpersonationContext 函数，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11953262/