模拟和 CredentialCache.DefaultCredentials 给 HTTP 401 Unauthorized答案

【问题标题】：Impersonation and CredentialCache.DefaultCredentials gives HTTP 401 Unauthorized模拟和 CredentialCache.DefaultCredentials 给 HTTP 401 Unauthorized
【发布时间】：2010-10-18 03:57:35
【问题描述】：

我有一个从 Web 客户端调用的 ASMX Web 服务（在我的 localhost - WinXP IIS 5.1 上）。我的 web 服务必须使用另一个 ASMX web 服务（在 Win 2003 服务器 IIS 6.0 上）。

当我以“硬编码”方式在我的网络服务代码中提供凭据时：

engineWSE.Credentials = new System.Net.NetworkCredential("myUser", "myPass", "myDomain");

...远程 Web 服务的后续调用工作正常。

现在我试图在一些初始测试中冒充自己。我对此的初步阅读告诉我这可能是一个大主题，但这是我为初学者所做的：

在我的 WebClient 的虚拟目录我的本地主机上的站点
在我的 webclient 站点的 web.config 中，我建立了：authentication mode="Windows" 和 identity impersonate="true"
在我的 web 服务的 web 方法中，它必须调用远程服务，我改为：
```
engineWSE.Credentials = System.Net.CredentialCache.DefaultCredentials;
```
当远程 web 服务被调用时 DefaultCredentials，我得到了以下错误：

System.Web.Services System.Web.Services.Protocols.SoapException：服务器无法处理请求。--->

System.Net.WebException：请求失败，HTTP 状态 401：未授权。

在 System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse （SoapClientMessage 消息、WebResponse 响应、Stream responseStream、Boolean asyncCall）

在 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] 参数)

我不确定我是否误解并试图过度简化“模拟”，或者远程 Web 服务是否以某种方式连接为仅接受带有 3 个参数（即用户名、密码、域）的凭据。

【问题讨论】：

标签： asmx impersonation credentials

【解决方案1】：

您是否使用过 netmon 或 wireshark 来确保凭据通过？服务提供商的日志告诉你什么？另外，请确保 web.config（或其他 .config）中没有配置模拟标签。

编辑：

可能是 HostingEnvironment.Impersonate() 块 - 默认情况下使用应用程序池的身份，或者您传递给它的任何用户令牌的身份。

【讨论】：

感谢下面的回答和评论。在这一点上，我真正知道的是任何 web.config 中都没有模拟标签（除了。我会调查你的额外建议。
@unknown - 您可以将用户凭据设置为模拟：msdn.microsoft.com/en-us/library/xh507fc5(VS.71).aspx。请参阅第三个灰色框示例。

【解决方案2】：

根据以下 MSDN article，它不适用于 HTTP 和 FTP 协议。当您连接到远程服务器时，您必须明确提供凭据。

【讨论】：

感谢文章参考。我也明白你的意思，但我怀疑我在这里理解不够（即我相信必须有某种方法可以在 Intranet 环境中利用 Windows 身份验证并通过另一台服务器（也与调用服务和 webclient 在同一域中） .
@unknown - 您是否将虚拟目录设置为集成 Windows 身份验证

【解决方案3】：

@ Michael Kniskern - HTTP 当然可以。模拟功能会将凭据从 ASP.Net 应用程序传递到 IIS。使用集成 Windows 身份验证，最终用户的凭据将被使用，而不是默认的 ASPNET 帐户（或附加到应用程序池的帐户）。我相信那篇 MSDN 文章中提到的 HTTP 和 FTP 是针对 DefaultNetworkCredentials 的。

【讨论】：

【解决方案4】：

这是典型的双跳问题 - 除非在您的域中正确配置了 Kerberos 委派，否则您不能使用通过模拟获得的用户凭据来访问另一台服务器。 this问题的重复

【讨论】：

【解决方案5】：

正如@Michael Levy 所说，这是一个双跳问题。这意味着除非您配置 Kerberos (Negotiate)，否则 NTLM 可能在运行 IIS 的 Windows 环境中使用，在机器 A 上有一个带有浏览器的客户端试图访问机器 B 上的网站时，将可以访问该站点但是，当这个站点将尝试联系机器 C 上的服务，应使用池凭据。

网站 A 调用服务 B 反过来调用服务 C 也是如此。

在为网站配置 Kerberos 时，应考虑多种因素。首先是要知道它是否是农场。如果是，您必须为场中所有机器部分的池定义一个通用用户。这是必需的，因为 Kerberos 使用域名来标识用于加密安全令牌的主体。如果您在同一个场的不同机器上有不同的用户，因为他们都将通过相同的域名访问，所有请求都将搜索相同的条目。更多详细信息，请访问Kerberos and load balancing。

例如，假设您有一个以 myApp.intranet 作为 URL 的站点。在 AD 中，您可以将 SPN 设置为域 MyDomain 中的 myUser (setspn -S MyDomain\myUser HTTP/myapp.intranet)。当请求发送到 KDN 时（有关 KDN 的更多信息，请参阅末尾的 kerberos 链接），它将始终返回使用 myUser 加密的令牌，但 IIS 将尝试使用不同的用户对其进行解密。为同一个服务 (HTTP/myapp.intranet) 创建多个 SPN 可能很诱人，但这会导致 KRB 错误。

此外，如果您使用的是 IIS 7+，如果您想保持启用内核模式身份验证（强烈推荐），则必须在 ApplicationHost.config 中设置一些细节：useAppPoolCredentials=true。此值必须在 configuration\system.webServer\security\authentication\windowsAuthentication 上设置。这是因为默认情况下，Kernel-mode auth will use the Computer account，而不是池帐户，这将使我们回到多用户场景。

在所有情况下，必须启用 AD 主体的 Trust this user for ... of the Delegation tab 才能进行委派。然后，您必须决定是要使用一般委托还是受限委托。

正如我之前所说，您还必须为正确的用户和正确的服务设置 SPN。用户很容易识别，因为它将是您在池中定义的用户，但根据您的配置，服务可能会有点棘手。 DNS、浏览器和可能的其他变量可能会改变应该使用的内容。我们的试验和错误表明：

如果您的 DNS 条目是 A 条目，则直接使用它
如果您的条目是 CName，在我们的测试中，它使用了与之关联的 A 条目
我们曾遇到过使用 CName 的案例，而且它似乎与浏览器的版本有关。

请注意，如果没有专门设置 SPN，并且您通过 NetBIOS 名称访问您的网站，则将请求 HTTP/机器服务，并且默认情况下，HOST service (search for extra) 可以用来代替 HTTP，因此 HOST/机器将使用。这对于在小型网络上轻松配置很有用。

还要记住，如果你想限制从 NTLM 到 Kerberos 的停机时间，你应该首先修改 ApplicationHost，然后，使用 SetSPN。您还可以在任何操作之前禁用协商并仅保留 NTLM，直到一切都设置好，然后，如果可能，仅启用协商（不启用 NTLM）。这应该会迫使客户修改他们访问您网站的方式。如果你不这样做，缓存机制似乎会在 NTLM 上保留一段时间。

希望这会有所帮助。如果您在配置 Kerberos 时仍有问题，WireShark 是您最忠实的朋友。您可以在以下页面中找到有关如何调试 Kerberos 的信息： - Debug Kerberos for a website - Debug AD problems with Kerberos（最大令牌大小是其中之一） - Kerberos tools and other links - General network capture Kerberos debugging

【讨论】：