WAN Performance and Kerberos Authentication with SharePoint

By: Knox Cameron | Updated: 2010-12-02 | Comments | Related: > SharePoint

Problem

You implement Kerberos authentication but SharePoint becomes slower, particularly for remote users.

Solution

Kerberos is more efficient for the server, but it can increase traffic between the browser and the server, making your site slower for users. Use a tool like Fiddler to see what is actually happening behind the scenes, and configure IIS to reduce the traffic and make the site faster.

SharePoint page load performance

A while ago, I was involved in troubleshooting performance issues for a global Intranet built using MOSS 2007 on Windows Server 2003 SP2. Users were complaining about how slowly pages loaded. Unfortunately, this is a common issue with SharePoint.

SharePoint is a system with a wide range of capabilities for collaboration and content publishing, as well as being a powerful application platform. Inevitably, this power comes with a price - the need to transmit and receive more data from the browser which will make it slower to use than an old-fashioned html web site. Page load performance can be a real barrier to use, and it is worth making the effort to make it as fast as possible given your circumstances.

There are software and hardware acceleration solutions on the market, some of which are quite effective. However, even without going down the route of add-on products, there are often ways of significantly improving performance by simple (or not so simple) configuration changes.

This tip describes how we investigated the performance problem, one of the issues we uncovered, and how we fixed it. While you may not face this specific issue, the approach can be useful for identifying and fixing the issues in your environment.

Monitoring traffic

The first step in fixing any problem is to understand it. We knew page loads were slow, but we needed to understand why. For this, we needed a way of seeing exactly what requests were going from the browser to the server and what was coming back.

There are a number of different ways of doing this, including utilities like NetMon. However, we decided to use a utility called Fiddler, because it is free, easy to install and easy to use. Fiddler is an unsupported "PowerToy" from Microsoft, but it actually works well with either Internet Explorer or FireFox on the client.

When you run Fiddler, it acts as a proxy on your computer, intercepting traffic between your browser and the web server. By default, it just captures http, but you can configure it to capture https as well (see its documentation for how to do this). Here, I browsed the home page of mssharepointtips.com with Fiddler capturing the requests. I selected the requests from the session list on the left, and selected the Statistics tab on the right, with the chart showing response types.

Select the "Timeline" tab on the right to see a "waterfall" chart of the requests and responses. I also collapsed the session list on the left.

Notice how the page took about two and a half seconds to load, and that most JavaScript, stylesheets and images took about another second. Some other resources took significantly longer, but the browser will generally display the page without waiting for all the resources, and just add them in when they arrive. The "diskette" icon indicates a resource where the server returned a 304 response telling the browser to use its cached copy.

Notice how the bars are hatched. This indicates that Fiddler is using "buffering mode", where it captures responses from the server before passing them on to the browser. This allows you to configure Fiddler to modify the data, but can degrade performance compared to normal browsing. Since we are only interested in observing, click the Streaming button in the toolbar to make Fiddler pass through data as soon as it is received.

Authentication

In an Intranet, content is typically secured so that it can only be accessed by authorized users. This is usually set up to happen transparently, so the user can open a browser and surf the Intranet without being prompted to login. It looks like SharePoint just "knows" who he or she is. Under the covers, the browser and the web server do a lot of work to make this magic happen.

What happens is that the browser always makes an initial request without passing any credentials or authentication information, effectively assuming that the content is available to anyone (as it is usually on the Internet for example). Because the SharePoint Intranet site is secured, the web server (Microsoft's IIS software) returns an "access denied" message (status code 401). Included in this message is information about what authentication mechanisms are available for the browser to use with that site. The browser then re-submits the request with the user's credentials attached in one of the acceptable forms, and (assuming that user is allowed access to the content) receives the requested content in return.

When Windows Integrated Authentication ("WIA") is configured correctly, the browser is able to provide the credentials of the user logged into the client computer automatically, so the user never sees the process occurring. WIA can use either the NTLM or Kerberos protocols to pass credentials. The default configuration for SharePoint is to use WIA with NTLM.

Kerberos versus NTLM

SharePoint uses NTLM by default because it "just works" without requiring any special configuration in the Active Directory ("AD"). However, it has a couple of limitations that are important to know:

NTLM credentials cannot be passed on by the web server to another "back end" service. The most visible impact of this in SharePoint is that the RSS Reader web part will be unable to "logon as the user" to another site, so you won't be able to use it to show data from another Intranet site.
NTLM requires the web server to communicate with a domain controller to verify the user's credentials, resulting in more "back end" traffic and load on the domain controller.

Generally, you should take the effort with any multi-server SharePoint farm to configure and use Kerberos. The steps to do that are beyond the scope of this article, but in overview: you need to configure the SharePoint application pool accounts and web servers to be "trusted for delegation" in the AD, and you need to configure Service Principal Names for all the host names used to access SharePoint sites to the correct application pool accounts. There are additional steps for MOSS to allow Kerberos to be used for the SSP, and for the SQL Server to allow Kerberos to be used for SQL access. The best approach is to get all these in place before installing SharePoint so you can enable Kerberos during the install process.

Authentication traffic overhead

From the above description of the process, you can see that authentication adds some overhead. There are two request/response exchanges instead of only one to get the page. Of course, pages also include references to images, stylesheets, JavaScript files and so on that the browser must also download. To improve performance, the browser will open a number of parallel sessions to download these, and each of these sessions must also go through an initial 'access denied; try again with credentials' process. So, expect to see a number of 401 responses before the browser is able to smoothly download the rest of the resources, something like this:

Each request with a "key" symbol is an initial request which received a 401 access denied response. It is followed by another request for the same resource with authentication information attached, which is successful. This diagram shows part of the page load of a SharePoint 2010 site home page.

However, we were surprised to find that our site looked more like this:

Every single request was being re-authenticated, resulting in a large number of additional request/response transactions. In addition, these transactions were adding significantly to the traffic. Each 401 response was about 2KB in size, because it was not just the 401 error code but a full html "Access denied" error page (even though the user never saw it). Each subsequent response with authentication was about 8KB in size because it included a Kerberos ticket with encrypted group membership information and so on.

The fix

Investigating the problem, we came across this Microsoft KnowledgeBase article: FIX: You may experience slow performance when you use Integrated Windows authentication together with the Kerberos authentication protocol in IIS 6.0. Microsoft changed the behaviour of Kerberos in IIS 6 to force re-authentication of every request. This was done to avoid the risk of "session hijacking", where someone intercepts the traffic and submits their own requests using the captured credentials. If you are willing to accept that risk in your environment in order to improve performance for users, that article contains a registry key setting that will configure IIS 6 to persist the authentication for the duration of the http session.

Looking at the traffic required to display a home page, we found there was 140KB of data being uploaded and 200KB downloaded. By setting this key, we were able to reduce that traffic to 100KB upload and 40KB download, and close to half the number of transactions. This change will not make much difference for users with a local, fast connection to the server, but will make a big difference for users with slow or long-distance connections.

The same issue still exists in IIS 7.0 on Windows Server 2008 - see You may experience slow performance when you use Integrated Windows authentication together with the Kerberos authentication protocol in IIS 7.0. The fix for IIS 7.0 involves a configuration setting in applicationHost.config rather than a registry key.

There is no corresponding KB article for IIS 7.5 on Windows Server 2008 R2, and from my testing, the issue appears to be resolved on that platform. Even the 401 responses seem to be a simple 401 rather than a full html page, so overall performance should be better.

Next Steps

Install Fiddler and analyze the traffic on your site.
Remember to look at both the traffic when you browse the site for the first time (after clearing the cache) and on return visits.
Look for anomalies that affect performance, such as the authentication issue described in the tip above.
Also look for issues such as large, uncompressed text files (html, css, js etc), or large images, or references to files that don't exist.
Do before and after testing to assess the impact of changes.