In some instances of WSS or MOSS when you use the "Sign in as Different User" option, the new login doesn't "take". Is there any known issue here? Usually logging out and then logging back in with the second user does work. This seems like a pretty big problem and I've seen it on and off over the years, mostly while testing with different identities.

UPDATE 1: I'm seeing it in several hosted WSS situations, so I don't actually know what authentication they are using. Interestingly, I don't see it in some hosted WSS situations, too. And consistently within the instance. This might tell us that the authentication method might matter.

UPDATE 2: Another piece of info I should have included in the first place: The reason that I'm asking this is that the $().SPServices.SPGetCurrentUser in SPServices sometimes returns the previous user. All I'm doing in that function is loading the _layouts/userdisp.aspx?Force=True page and pulling the Name from the page. It's the column with the label 'Account', but the InternalName is 'Name':

<!--  FieldName="Account"

Here's the SPServices function:

// Function which returns the account name for the current user in DOMAIN\username format
$.fn.SPServices.SPGetCurrentUser = function() {
    var username = "";
        async: false, // Need this to be synchronous so we're assured of a valid value
        url: $().SPServices.SPGetCurrentSite() + "/_layouts/userdisp.aspx?Force=True", // Force parameter forces redirection to a page that displays the information as stored in the UserInfo table rather than My Site.
        complete: function (xData, Status) {
            $(xData.responseText).find("table.ms-formtable td#SPFieldText").each(function() {
                if(/FieldInternalName=\"Name\"/.test($(this).html())) username = $(this).text();
    return username.replace(/(^[\s\xA0]+|[\s\xA0]+$)/g, '');

One would like to think that this page would always represent the currently logged in user, but sometimes it represents the prior user. Not good.

UPDATE 3: I may have come up with a fix for this in my SPServices library, at least. It doesn't solve the larger problem that SharePoint seems to have, though. I added a unique Query String parameter (just the current time) to the call to userdisp.aspx in SPGetCurrentUser per arunduttgp's suggestion. This seems to force the browser to do a hard refresh on the page in the AJAX call, getting the correct values for the logged in user even when the current SharePoint page is showing the prior user incorrectly.

 url: $().SPServices.SPGetCurrentSite() + "/_layouts/userdisp.aspx?Force=True&" + new Date().getTime(),
  • Happens to me all the time too while testing. Usually refreshing the page a few times (+/- ctrl key) eventually gets the right identity going. I'm yet to find anything that gives an explanation and haven't had a chance to dig deeper. It almost seems like a credential caching issue of some kind.
    – Paul Lucas
    Commented Mar 24, 2010 at 21:28
  • It happens to me a lot as well! One of the tests that I wanted to check was if it happens when the site is using kerberos, ntlm, or both. As we are only using kerberos I can't test that. Not sure if that would really matter. Commented Mar 24, 2010 at 21:54
  • In most cases I'm seeing it with NTLM, so that may eliminate that possibility!
    – Paul Lucas
    Commented Mar 24, 2010 at 21:56
  • Does this happen with 2010 as well?
    – MBSurf
    Commented Mar 25, 2010 at 14:51
  • I haven't worked with 2010 enought to know if it happens there, too. Anyone else? Commented Mar 25, 2010 at 16:02

7 Answers 7


I get this a lot, just not consistently. A page refresh will sometimes sort it out. I've taken to just using the "runas" command to avoid using "Sign in as Different User" and the associated issues.

runas /user:{Domain}\{UserID} [/savecred] "C:\Program Files\Internet Explorer\iexplore.exe [Optional URL]"

You can create shortcuts on your desktop to make this easier.


Just refreshing the page is not enough, the majority of times this is simply due to browser caching but a page refresh will not refresh the browser cache.

In IE you would click Cntrl + F5 to clear the cache and do a full refresh, not sure what the same command would be in FireFox or other browsers but the concept will be the same.

  • Charles I don't think its a browser caching issue. If there has been content changed on the page, I see the new content. It's just that the logged in identity does not change until the page has been refreshed a few times
    – Paul Lucas
    Commented Mar 25, 2010 at 12:20
  • Apologies I only read the question briefly and it read like an easy fix. I see it in more detail now, although its not something that I have seen before. Commented Mar 25, 2010 at 19:13
  • No worries, Charles! I wish it were as simple as a refresh. Commented Mar 25, 2010 at 19:27

I see Paul's comment above about seeing the issue more with NTLM. I run Kerberos in the vast majority of my environments, and I very rarely see it at all, so it could be the case where it's related to NTLM.

It's got to be some sort of cache either within the browser or the session. I wouldn't think that there's a way to force a refresh through the script, unless you can refresh the destination URL before reading from it.


I don't necessarily have a solution for you (other than the "refresh the page a couple times" others have mentioned, but as a data point I only started seeing this behavior when I first upgraded to IE8. In fact on machines where I still have IE7, I never see it at all. I'd be curious if others share this experience.

  • I think you're right about IE7... I've never seen it happen with IE6 either! LOL.
    – Paul Lucas
    Commented Mar 26, 2010 at 20:11
  • Although I have seen it with FireFox 3.6
    – Paul Lucas
    Commented Mar 26, 2010 at 20:13

A more dependable way to determine the logged on user may be to just ask the server instead of going through SharePoint ( which at this point is acting as a middle man). Getting the variable directly may help with the whole refresh question as there may be some lag as the credentials are updated, guessing here.

This page should help. Specifically, the LOGON_USER variable will have the value you need.


I'm dealing with same issue of login as Different user not refreshing the page to show the new user and that users permissions. Usually though (Firefox) after a page refresh the correct user and permissions are showing.

But I think a related problem is that if a user lands on the AccessDenied.aspx page and attempts to logon as a different person (using the provided link) it seems to have a similar failure of not updating with the new users permissions and such. Only workaround is to have users close all browser windows and start over by logging in with the correct credentials.

I don't know if this is a new shortcoming of using Windows Integrated Auth and updated browsers holding onto previous credentials or what.


I like Clayton Firth's solution, using the "runas" command. Any way to make it prompt for the user? Also, can I run this command from a link within SharePoint? Essentially I would like to replace the "Sign in as Different User" menu option witht the "runas" command.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.