在 IIS6 中使用 WIF 时出现问题答案

【问题标题】：Problem using WIF with IIS6在 IIS6 中使用 WIF 时出现问题
【发布时间】：2010-09-27 20:46:07
【问题描述】：

我们在 IIS 6 上使用 SessionAuthenticationModule 时遇到问题，尝试访问应用程序时，出现以下异常：

数据保护操作不成功。这可能是由于没有为当前线程的用户上下文加载用户配置文件造成的，这可能是线程模拟时的情况。

我能够解决的是，可以在 IIS 7 中启用配置文件，但我们的托管公司使用 IIS 6。有什么想法吗？可以尝试一下，或者只是一般的想法？

堆栈跟踪：

[CryptographicException: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.]
    System.Security.Cryptography.ProtectedData.Protect(Byte[] userData, Byte[] optionalEntropy, DataProtectionScope scope) +456
    Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Encode(Byte[] value) +54

[InvalidOperationException: ID1074: A CryptographicException occurred when attempting to encrypt the cookie using the ProtectedData API (see inner exception for details). If you are using IIS 7.5, this could be due to the loadUserProfile setting on the Application Pool being set to false. ]
    Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Encode(Byte[] value) +146
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +47
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(XmlWriter writer, SecurityToken token) +470
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(SessionSecurityToken sessionToken) +89
    Microsoft.IdentityModel.Web.SessionAuthenticationModule.WriteSessionTokenToCookie(SessionSecurityToken sessionToken) +123

【问题讨论】：

标签： asp.net-mvc-2 iis-6 wif

【解决方案1】：

创建虚拟窗口服务并在您的 Web 服务上安装窗口服务，并将其登录帐户更改为与您的 Web 应用程序池帐户相同。应该可以的

【讨论】：

【解决方案2】：

我在本地 IIS7 服务器上遇到了同样的问题，并通过在应用程序池上将 loadUserProfile 设置为 true 来解决它。我发现以下有关 IIS6 的信息：

在 IIS6 中，所有工作进程，无论配置了哪个进程标识，都使用 C:\windows\temp 作为临时目录。更具体地说，默认情况下，没有一个工作进程加载它们的“用户配置文件”，导致它们都使用 c:\windows\temp 作为临时目录。 Windows 允许所有用户在此目录上读/写/创建者权限，这允许事情“正常工作”。这样做的负面影响是默认情况下所有 AppPool 都有效地共享同一个临时目录，这可能导致跨 appPool 信息泄露。对于 IIS7，我们选择了更安全的默认设置，现在默认为所有应用程序池加载用户配置文件。

loadUserProfile and IIS7

所以看起来 IIS6 默认不应该锁定临时目录。我想知道您的主机是否出于同样的原因将其锁定。

【讨论】：

谢谢，会检查是否可能。我们实际上结束了，因为我的应用程序由外部提供商托管，实现了一个使用机器密钥的替代令牌处理程序（因此不需要“用户配置文件”）。这不是最佳解决方案，但可以作为临时解决方案。

【解决方案3】：

我在拥有有效帐户但从未使用该帐户登录的服务器上遇到此异常。用户在 AD 上，这就是它成为可能的方式。除了以用户身份实际登录之外，我几乎尝试了所有方法。我终于想到了这样做，它就像一个魅力。

【讨论】：

【解决方案4】：

您可以通过使用 RSA 而不是 DPAPI 来保护会话令牌，从而绕过对用户配置文件的需求。这实际上是所有部署的最佳实践，尤其是负载平衡（以及企业中谁没有负载平衡？）

Dominick Baier 对此写了一些东西： http://leastprivilege.com/2010/02/19/wcf-wif-and-load-balancing-and-a-bit-of-azure/

【讨论】：