We sometimes see customers running into problems when using the "Sign in as Different User" feature in SharePoint.
Common problems are
The Sign in as Different User functionality is not meant to be used as a security feature! This feature allows users which have more than one AD account to quickly login with a different account to SharePoint - but it does not guarantee that no artefacts from the previous user remain!
If you have to guarantee that one user cannot see data from a different user you have to logoff/logon in Windows. Don't use the Sign in as a different user.
I've seen issues with this too, and that's why I always like to use IE's InPrivate Browsing feature to help keep things seperate when I need this functionality.
I have a lot of problems with IE9 and Sign in as Different User..
Stefan, is there any deep-dive type documentation on precisely how the "Sign in as Different User" feature works under the hood? Is there any documentation regarding known issues related to using this feature in IE7, IE8 or IE9?
Whether or not documentation exists, can you provide some technical details regarding your comment "but it does not guarantee that no artefacts from the previous user remain"?
I don't have a complete list of things. The sign in as different user is actually an artificial 401 response to request credentials from the client machine. That gives you the dialog to logon with other credenitals. But (e.g.) the cookies and session variables filled by the previous user account are still there. Web parts might rely on these and show information for the previous user rather than the new based on the info in cookie and session variables.
But these are just examples.
In general: there is not a complete list and if you need to separate users, login as different users on your browser machine.
As always, I appreciate your reply.
I agree that your solution to "log in as different users on [the] browser machine" would definitively prevent any potential related conflicts given the discussed scenario. With this said, having users log in to Windows each time they wish to switch users within SharePoint is not always feasible or desirable especially considering that the functionality exists. I understand what you are saying about cookies and sessions, however I can think of numerous scenarios where the "Sign in as a Different User" is commonly used. For example, consider a boardroom collaboration setting with a group of people, a single PC, and a projector or large screen.
Would it be possible for MSFT to publish a white paper that communicates the known scenarios where "Sign in as a Different User" issues may surface for the SharePoint Administrator and Developer communities at large? It would be advantageous for all to have official guidance where specific log in and usability issues related to the "Sign in as a Different User" functionality may arise when using SharePoint.
sorry - I'm the wrong audience to ask this question. First of all: I don't have a complete list. Second: I work in support and I'm not part of the product group designing the product.
My role is to assist customers in using the product and to help to use the product in the way it is designed - and that is what I was trying to do when publishing this blog post.
Thank you for your reply - your post and comments are much appreciated.
For technical guidance purposes, I ask that you please forward this post internally through the appropriate channels and request clarity from the product group. I would like to respectfully request that technical documentation be made publicly available related to known issues with the "Sign in as a Different User" feature within SharePoint.
I would need an active support case to leverage such channels.
So if this important for you, please open a support case to request such guidance.
There are support articles that exists on this topic. The main KB article provides 3 different options to address....although none are that appealing.
I prefer the first approach over the others.....only issue is it will get undone with hotfixes and upgrades if the js file is targeted in the install for updating. support.microsoft.com/.../en-us
Full KB: (Should be updated to include SP 2010)
Another issue with this feature is it will often get stuck on the other user - even after you use Login as another User to log back in as yourself. I'm in a situation right now where every new browser session it goes back to the "other" user and that's even after deleting cookies! I'm guessing that's why it was removed from 2013.
Is there a fix for going back to the "other" user yet? I'm having this problem now even though the cookies and my profile were deleted from the computer. It only occurs on the computer that was used for the different login. Any othe computer on the network is fine.
I have a problem ,I created a group with Full Controll permission in my subsite and stop inherit permission from parrent,
And the problem is the user have full control in that site but he cant create a publishing page , when he select publishing page from more optiopn-> pages- > publishing page ---- it shows sign in as different user .. (sharepoint 2010)
a Publishing page needs resources in the root site - e.g. the Content type and the page layout.
In General you should reduce rights from root to leaves and not vice versa.