SharePoint: Users intermittently notice they are logged in as someone else
Problem:
Intermittently users notice that they have automatically been logged in as a different user.
For example, while browsing, you look in the upper right-hand corner of the page and see another users display name listed there. Clicking around more may result in switching back to yourself, or switching to another user altogether.
Possible Causes:
This is always caused by an intermediate network device doing some type of caching or TCP session re-use. We’ve never once seen this behavior turn out to be a problem with SharePoint.
Problematic network devices can include proxy servers, load balancers, accelerators, firewalls, etc. Just because your network device is not specifically mentioned in the “usual suspects” list below does not mean it isn’t at fault.
For example, we most often see this with F5 load balancers when they are using a feature called “OneConnect”. OneConnect is supposed to increase network throughput by reusing TCP connections. However, it can cause problems with SharePoint because (for example) UserA will browse to a site and OneConnect will re-use a TCP connection from UserB. Now UserA is logged in as UserB. OneConnect should probably only be used in Anonymous browsing scenarios. See this for more info: https://support.f5.com/csp/article/K7208
We’ve also seen this behavior when trying to use NTLM authentication with Azure Application Gateway V2. NTLM is not currently supported with V2, probably for this reason. You would either need to use a different authentication method, or revert to a V1 gateway.
And we found that a Citrix feature called connection multiplexing may cause this problem as well.
And more recently, we’ve also seen this problem with the Amazon (AWS) Application Load Balancer (ALB). AWS techs confirmed it shouldn’t be used with Windows authentication. We switched to a Network Load Balancer (NLB), and the issue was resolved.
Testing / Isolation:
You can test this by creating a HOSTS file entry on a client machine that points the web application host name (for example: teams.contoso.com) at the IP address of one SharePoint web-front-end (WFE) server. Doing so should bypass intermediate network devices and send the client traffic directly to the WFE. If you can no longer reproduce the behavior, that pretty well proves the problem is caused by a network device outside of SharePoint.
Resolution:
If you’re using an F5 or Citrix NetScaler anywhere in the network path between the client and SharePoint servers, make sure that all applicable One Connect profiles are disabled on the F5, and Connection Multiplexing is disabled on the NetScaler.
If you’re using Azure Application Gateway, make sure you’re using V1, or an authentication type other than NTLM.
And if you’re using an AWS Application Load Balancer, you’ll need to switch to a Network Load Balancer (NLB).
And as long as you’re reading about SharePoint and NTLM, you might as well see my other article here.
Some other terms to help “findability” for this article:
Wrong user name
wrong display name
switch user
switch profile
username accountname loginname
account name login name
logged in as another user
authenticated as other user
different user name
session hijack
tcp reuse
session reuse