Problem using WIF with IIS6

Question

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(XmlWriter writer, SecurityToken token) +470
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(SessionSecurityToken sessionToken) +89
    Microsoft.IdentityModel.Web.SessionAuthenticationModule.WriteSessionTokenToCookie(SessionSecurityToken sessionToken) +123

Answer 1

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.