One reason for slow performance in SharePoint (authPersistNonNTLM)
When discussing possible causes for sluggish performance in SharePoint farms, there is one provocative KB article that has helped many people out:
954873 - 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/EN-US
The idea there, in short, is that when an IIS setting named AuthPersistNonNTLM is set to FALSE it tries to re-authenticate the client for every request. By default Windows 2008 servers running IIS 7.x have this set to FALSE. If you set it to TRUE, it can authenticate the client once and not continue to re-authenticate them over and over and over and over. The choice is between sending the Kerberos ticket with every single request (adding 4-5 or more packets to each GET) or keeping individual TCP sessions authenticated and not sending the ticket nearly as often. For many web servers, setting AuthPersistNonNTLM (or APNN for short) to true has provided a very significant performance gain. This could, for example, help solve what appears to be a SharePoint performance problem that could ultimately be a performance problem with a busy global catalog domain server. There are a few ways that this could improve performance.
Keep in mind that this only applies to Kerberos. It has nothing to do with NTLM. Thus the "NonNTLM" bit. Why they didn't call it "AuthPersistKerberos" instead I don't know. Anyway, I think this might be a good point to try to clear up one thing that I've seen some people confused over. Some people think they're using Kerberos when they're actually using NTLM. If you're not sure whether you're using NTLM or Kerberos, one of the best ways to determine the truth is to capture either a Fiddler trace or Netmon trace (don't forget the Office parsers!) between a client and the IIS/SharePoint server. Examine the capture and check the authorization header. It's not uncommon for some to see the header set to "Negotiate" and think that this somehow must mean Kerberos is being used. However, "Negotiate" does not mean it will use Kerberos rather than NTLM. It just means that the client will "Negotiate" the authorization method. A client like Internet Explorer will try to negotiate with Kerberos first if it is able to do so and if it reckons that it is the most secure method given the zone that the URL it is browsing to falls into. If it can't or won't use Kerberos, it will use NTLM instead. So look at the way the client negotiates the authentication. If the header starts with a "T" (example: HTTP: Authorization = Negotiate TlRMTVNTU...) then you're using NTLM. If it starts with a "Y" (example: Authorization: Negotiate YIILjgYGKwYB...) then you're successfully using Kerberos. For those who would prefer an easier way to figure this out, you could consider using the tool DelegConfig. (But sometimes it's difficult to get DelegConfig to work on a SharePoint WFE.)
Obviously we have a KB that says setting APNN to TRUE can be done. And it's easy to imagine how SharePoint performance could benefit from this if you set it to TRUE on all your WFEs and APP servers that are using Kerberos. But should it be done?
In the past I tended to err on the side of caution and try to leave it set to FALSE on an IIS7/Win2008 or IIS7.5/2008R2 server. But now I'm starting to factor into my decision making the very interesting fact that IIS 8 (in Windows 8 and Windows 2012 Server) has it set to TRUE by default. That seems like a very substantial design change. Between kb 954873 and this design change, I became less reluctant to recommend setting APNN on IIS 7 servers true. If TRUE is the new norm for IIS 8 servers, why shouldn't we start making it the norm for IIS 7.x servers? But then the question naturally arises whether or not we trading security for performance by setting it to True?
I've had trouble finding an authoritative answer to this. The best answer that my research and conversations have come up with so far is this: it seems that there is a choice to be made and a tradeoff between potential security and actual performance. Setting APNN to true would increase two potential risks:
(1) man-in-the-middle (MITM) attacks. (Discussed briefly here: https://msdn.microsoft.com/en-us/library/dd767318.aspx.)
(2) TCP Session Spoofing
So to what degree is security traded for performance here? To what degree is are the risks increased? I'm not sure I can give a satisfactory answer here. If you are running IIS with APNN set to true in a corporate environment (which is the only place Kerberos is going to be used), this risk should be relatively low. And if you’re using https rather than http, the risk is even lower. The fact of the matter is that the risk seems sufficiently insignificant in IIS 8 that APNN is set to true by default. If you're using Kerberos in your SharePoint farm running on Windows 2008 servers and are troubleshooting a serious performance issue, KB 954873 seems to indicate that making the change is worth the risk. Should you set APNN to true on your IIS 7.x servers to be proactive about maximizing performance and eliminating potential bottlenecks? This blog post is intended to help others explore--but not necessarily answer--that question.
[Standard caveats, disclaimers, and warnings apply to all information on this blog.]