Ran into a super painful problem about 3 weeks ago. When users were logged onto a Terminal Server (Server 2008 R2) and running Internet Explorer 8 (Why, you ask, would I allow IE to run in Terminal Services? Normally I wouldn’t but the client’s app needs to be run within IE) any time they tried to download a file, or open a link that moved them to a new tab or window, the site “forgot” who they were and prompted them to re-authenticate. This happened on many different sites, and not just on the app I mentioned.
We started down the normal troubleshooting path, allowing the site in Pop-up blocker, adding the site to the Trusted Sites list, lowering the security on the Trusted Sites list to “Low”, enabling Computability Mode, etc. Nothing would allow the file to be downloaded without having to re-login to the site.
As we continued testing, we removed all Group Policies that were locking down the Terminal Server, we created new users with fresh profiles, and double checked registry and file system permissions, again nothing would resolve the problem.
Finally, we came across this blog post over at the MSDN site, Here. Turns out, that when a new tab is opened, it starts running under a different process, combine that with users running on a Server 2008 R2 without “Power Users” permissions, like in the case of Terminal Services, and it creates a situation where the new process does not have permission to access the cookie that was stored by the other running process. This is not the case on Windows 7, as users without “Power Users” permissions don’t experience this same problem.
Internet Explorer changes it’s behavior of where it stores cookies and other data depending on the permissions for the user running the process. Any application which launches a new tab, in turn launches a new process and this will not have permission to access data like cookies from the process which launched it. Since the users are in a locked down environment, this Internet Explorer behavior should be turned off.
The registry value that we needed to change was located here:
We needed to create a new DWORD called “TabProcGrowth” and set it’s value to 0.
The reason we are setting this value at HKLM and not HKCU is so that every users who uses this machine will have this setting applied to them. I’m far too lazy to change it and every user’s HKCU level.
After making this changed we were able to log in with new test users, and existing users alike and verify that we were no longer seeing the problem!