in the last weeks I could see a side effect with SharePoint 2007 and Internet Explorer 8. We publish a KB with 3 different workarounds as solution
KB 2435214 – SharePoint 2007 and Internet Explorer 8 has problems with “Sign in as a different user” does not clear ASP.Net Session object
In SharePoint 2007 using Internet Explorer 8 and “Sign in as a different user” displays old Session data. After 30 seconds the session object is completely refreshed and all data is correct.
What does this mean for SharePoint?
Normally users browse over the portal with their own account. In case a user switch to another identify the user will use the function: Sign-In as different User. An administrator is doing this more then ones a day. This “easy” function has a little requirement, the authentication behavior of the client (Browser) is very important.
After calling “Sign in as a different user” the user will enter new Credentials and under the hood of the IE6 & IE7, the browser will drop the existing socket connection and create with the new credentials a new socket connection. The IIS and SharePoint Web Application create for a new socket connection a new Session object and the old Session will be deleted automatically. With IE8 this behavior has changed because the IE8 use a Session based authentication and IE8 use the same connection as before. This means the web application need to delete the session object manually. Unfortunately SharePoint 2007 was ealier in the market as IE8, so the manually deletion is not in place.
The root cause of the behavior was really nice. Browser like IE6 and IE7 have a connection based authentication architecture and IE8 has a new design, it’s a session based authentication. With IE8 it take 30 sec. until the old connection times out or the session object is refreshed. As solution we have 3 workarounds with 3 advantages or disadvantages:
Workaround 1: customize init.js file or overload the method of LoginAsAnother() with an addition line of code: document.execCommand(“ClearAuthenticationCache”);
-> can be critical with patching SharePoint in case the js file will be changed. After each patching we need to check the js-customization.
Workaround 2: change IIS authentication behavior to force the authentication for each incoming http request
Run the following:
cscript adsutil.vbs SET w3svc/<webappidentifier>/AuthPersistSingleRequest TRUE
example: cscript adsutil.vbs SET w3svc/1048141505/AuthPersistSingleRequest TRUE
-> this will create more IIS authentication overhead of the WFE and DC, but the implementation is very easy
Workaround 3: create a custom httpmodule and deploy it over the farm (all webapplications)
Task of the custom http module: after calling sign-in as different user a custom http module implement EndRequest method of http module interface: Logic to implement: after calling “/_layouts/AccessDenied.aspx?loginasanotheruser=true” run httpcontext.Session.Clear();
Implementation: after sending Response of “/_layouts/AccessDenied.aspx?loginasanotheruser=true” it’s important to call httpcontext.Session.Clear();
More details to implementing a custom httpmodule:
-> this is an additional customization in the farm but in my opinion a elegant solution.
I hope this helps.