When users attempted to access CRM 2011 via the external facing URL, the application was throwing a windows authentication prompt. Multiple attempts were made to authenticate by manually typing in the password , however it was failing with a 401 unauthorized.
You may find the below information on the platform trace:
Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType><Message>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. </Message><StackTrace> at
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 privileges on this directory, which allowed things to 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 option – load user profile. Unfortunately, the temporary directory underneath the user directory (for example – %windir%\serviceprofiles\networkservice\AppData\Local\Temp for the default NetworkService identity we use for DefaultAppPool) is not writable by anyone other than NetworkService and the system administrator by default.
Dynamics CRM, by default does not choose “load user profile” = true. CRM worker process writes to the common temp folder. When CRM is running on a service account, it will still try to use the common temp folder.
CRM AppPool is granted permissions to the temp folder , via the installation prerequisites.
If , for some reason , the AppPool account cannot any longer access this location or has limited access, due to revoked permissions/updates /group policies or other unforeseen reasons we will see similar symptoms.
Would allow the CRM process to load its own profile, where it is guaranteed to have full access and control . This was how the issue can be resolved.
Or focus on the permissions on the temp folder
Dynamics CRM Team