"Sign in as Different user" doesn't work in SharePoint Portal?

 

Microsoft SharePoint providers a feature allows you to “Sign in as another user”.

 

I got two escalations regarding the “Sign in as Different user” feature recently.

The customer’s design of this feature is pretty simple:

- Links “Sign in as Different User” to a page

- This page returns 401 response to client

- Then client like IE will pop up a credential window

- After provide the credential, redirect to the original page

The problem my customers have is after provide the new credential, they were still seeing the original user’s name on the portal. If they refresh the page couple of time, they can see the new user’s name.

Solution

I found customers are using NTLM authentication instead of Kerberos. The problem fixed by configured Kerberos for their site.

 

So, why?

 

When NTLM is used, “session-based authentication” or “connection-based authentication” is enabled. That means the authentication only happens per TCP/IP connection. By default, IE creates 2~6 TCP connections per web server based on IE version. As the article described, this can be changed via registry key. When IE sends request via an “authenticated” connection, there is no authentication required. This scales much better when the connections are reused to make multiple requests.

 

Now, we can understand the cause of my customer’s problem. Given the using of “session-based” authentication, even you provided new credential, an existing connection may be picked and that’s why the previous user’s information still showed.

 

When Kerberos authentication is used, IIS7 and IIS 7.5 force the re-authentication of every request. That’s why we fixed this issue by switch to Kerberos authentication.

 

There is another simple solution with NTLM: set “authPersistSingleRequest” to true. As this turns NTLM to “request-based” authentication.

 

Setting this flag to true specifies that authentication persists only for a single request on a connection. IIS resets the authentication at the end of each request, and forces reauthentication on the next request of the session.

https://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication

 

Further More

 

Easy and perfect solution? No.

 

We had a lot customer’s reports regarding severe performance issue with IIS 7 when using Kerberos. This is due to Kerberos is “Request-based” instead of “Session/Connection-based”. You can found the article here.

 

You may experience slow performance when you use Integrated Windows authentication together with the Kerberos authentication protocol in IIS 7.0.

https://support.microsoft.com/kb/954873

 

So, both the current solution requires switch from “Session-based” authentication to “Request-based” authentication. And this is a big potential performance issue.

 

Consider a single html page with many images, javascript and css files. We need to authentication all these requests again and again. A NTLM authentication involves 3 pair of requests/responses, and Kerberos requires 2 pair of requests/responses. It is 3X or 2X more requests. In addition, there are additional bytes send due to the header, and some Kerberos header can be huge.

 

I investigated an intermal Sharepoint site which implemented this, and found it uses a better solution. This solution tries to close all existing TCP connections by sending “Connection: Close” to the browser client. So, when user provides a new credential, IE always set up a new connection. Here is the how this solution designed.

 

- Links “Sign in as Different User” to a page named ConnectionClose.aspx

- In this page, generates lots of dummy img tags point to another ASPX page. IIS returns this page including the “Connection: Close” header. This can be configured on IIS or set via code.

- After received response contains such header, IE closes the TCP connection.

- After page loaded, a java script change the URL to another page which sends 401 response.

- Then, IE opens new connection since all existing connections were closed.

 

With this solution, we don’t have to use the “request-based” authentication. Here is the fiddler trace for this solution with a Sharepoint site. 

 

 

See you next time,

 

Wei Zhao from APGC DSI Team