0

我们在 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
4

4 回答 4

2

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

于 2011-03-23T16:31:40.797 回答
1

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

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

loadUserProfile 和 IIS7

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

于 2010-10-26T12:15:43.433 回答
0

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

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

于 2011-08-06T21:51:11.467 回答
0

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

于 2012-10-10T15:55:17.400 回答