Problem using WIF with IIS6

We have a problem using the SessionAuthenticationModule on IIS 6, when trying to access the application, the following exception occures:

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.

What I have been able to work out is that there is possible to enable the profiles in IIS 7 but our hosting company uses IIS 6. Any ideas what to do? Something to try, or just general ideas?

Stacktrace:

[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(开发者_如何学GoXmlWriter writer, SecurityToken token) +470
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(SessionSecurityToken sessionToken) +89
    Microsoft.IdentityModel.Web.SessionAuthenticationModule.WriteSessionTokenToCookie(SessionSecurityToken sessionToken) +123

create dummy window service and install window service on your web service and change it's logon account to be the same as your web app app pool account. that should work

I had this same problem with a local IIS7 server and resolved it by setting the loadUserProfile to true on the app pool. I found the following regarding IIS6:

With IIS6, all worker processes, regardless of which the process identity was configured, used to C:\windows\temp as the temporary directory. More specifically, none of the worker processes loaded their 'user profile' by default, causing all of them to use c:\windows\temp as a temporary directory. Windows allows all users read/write/creator privledges on this directory, which allowed things to 'just work'. The negative side effect of this is that all AppPools are effectively sharing the same temporary directory by default, which could lead to cross-appPool information disclosure. With IIS7, we've chosen a more secure default and now load user profile by default for all application pools.

loadUserProfile and IIS7

So it looks like IIS6 shouldn't be locking down the temp directory by default. I wonder if your hoster has locked it down for the same reasons.

I got this exception on a server where I had a valid account but never logged into it using that. The users are on AD, which is how this becomes possible. I tried almost everything except for actually logging in as the user. I finally thought of doing that, and it worked like a charm.

You can get around the need for a user profile by using RSA instead of DPAPI to secure session tokens. This is a best practice in fact for all deployments but particularly for load balanced (and who isn't load balanced in an enterprise?)

Dominick Baier wrote up a little something on this: http://leastprivilege.com/2010/02/19/wcf-wif-and-load-balancing-and-a-bit-of-azure/