SharePoint 2007 and Internet Explorer 8 – side effect with Sign-in As different User

Hello @all,

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.




Comments (6)
  1. Anonymous says:

    hello sudhanshu, using Visual Studio 2008 + SharePoint Extention to create a feature. After complile you will have a WSP-File for in the folder structure. Now you can run stsadm -o addsolution to and over central admin in (operation/solution management) you can deploy this solution to your webapplication.



  2. Anonymous says:

    Hi Ruben,

    as i know the behavior is a combination of client side and server side config. On IIS server execute: "cscript adsutil.vbs GET w3svc/<webappidentifier>/AuthPersistSingleRequest" and check the current authentication setting. In case AuthPersistSingleRequest = true, then the environment is currently running in workarround 2. please compare both env. with this config.

    In case the server config is to 100 % in the same state then i would think about, Proxy, Network, Firewall  and browser config. The OOTB browser behavior is e.g. socket timeout = 30 sec. after doing sign-in as different user the browser has a 30 sec. sockect connection timeout value. If no communication happens during 30-60 sec. the socket connection will be closed. In case we see any issue on network side that your socket connection will terminated then we have the same behavior as in workaround 2 again. A network related socket termination can be done by proxy and  firewalls.

    i hope this helps.



  3. Anonymous says:

    hi Thomas,i recommand to open a support ticket for detailed help.Further speps would go into debugging analysis. which Server OS version and IIS version do you use?

    regards patrick

  4. Ruben says:

    Thanks for the information.

    We are having that problem on our test environment, but not with our production one. Booth have the same configuration, and from the same PC we have an automatic refresh when we sign in as different user in the production but no on the test.

    So my question is if there may be some different configuration on the servers or these is only configuration of Explorer 8 on the PC.

  5. I've tried it with the following  (workaround 3)

    workaround 1 and 2 isn't an option

     public class FixSignInAsAnotherUserHttpModule : IHttpModule


           public void Dispose()



           public void Init(HttpApplication context)


               context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);

               context.EndRequest += new EventHandler(context_EndRequest);


           void context_EndRequest(object sender, EventArgs e)




                   var context = ((HttpApplication)sender).Context;

                   if (context.Request.Url.ToString().ToLower().Contains("/_layouts/accessdenied.aspx?loginasanotheruser=true"))






               catch (Exception ex)




           void context_PreRequestHandlerExecute(object sender, EventArgs e)




    and added to the web.config

    <add name="FixSignInAsAnotherUserHttpModule" type="ONPRVP.Common.HttpModules.FixSignInAsAnotherUserHttpModule, ONPRVP.Common, Version=, Culture=neutral, PublicKeyToken=5ec763fc9d10a840" />    

    but in my case, it still doesn't work

  6. sudhanshu says:

    hi can some one tell me how we can provide on production(MOSS 2007) sign as adifferent user feature although it is present on my test server

Comments are closed.

Skip to main content