NTLM Authentication with SharePoint

  • Article

NTLM Authentication in SharePoint

Most SharePoint environments today are using NTLM (the default) as the authentication protocol. This has some hidden performance implications that are not widely known. But before we dive into the world of NTLM Performance bottlenecks with SharePoint lets address the NTLM authentication process first.

Order of actions for inbound user authentication for all accounts in the same domain (roughly)

  1. Internet Explorer (IE) first connects to SharePoint (HTTP Get /) and presents anonymous. Three way TCP handshake here.
  2. SharePoint (IIS-401) rejects anonymous and returns the WWW-Authenticate: NTLM header.
  3. IE calls AcquireCredentialsHandle and passes the appropriate Security Support Provider (SSP) in this case NTLM. IE prompts (depending on the zone the site lives in and options configured) for username and password.
  4. IE calls InitializeSecurityContext which constructs the Auth token containing the Domain Name and Machine name.
  5. SharePoint (IIS) is already listening for connections and parses the inbound request.
  6. AcceptSecurityContext is called by IIS and an Auth Token containing an NTLM challenge (16 –byte random number) is sent to the client (401).
  7. IE parses the reply and InitializeSecurityContext is called again, an Auth Token containing the NTLMChallengeResponse (challenge is encrypted with a hash of user’s password) is sent to SharePoint.
  8. SharePoint (IIS) parses the request. At this point the Secure Channel (SC) Domain Controller (DC) is contacted with the user name, challenge sent to the client, and response received from the client. This is where MaxConcurrentApi comes in to play more on that in a bit.
  9. The DC takes the user name and retrieves the password hash (used to encrypt in step 7) and compares it to the challenge response. If they are identical, authentication is successful.
  10. The DC returns success to the SharePoint (IIS).
  11. SharePoint (IIS) accepts the connection as authenticated.
  12. What happens here will be another post.

MaxConcurrentApi is set by default to a value of 0 which equals two concurrent NTLM authentications. Under load SharePoint can end up waiting on authentication. By adjusting the MaxConcurrentApi value on the SharePoint Web Front End (WFE) you can increase the amount of concurrent authentication and thereby increase WFE performance. This does however increase the load on your DC’s and that’s why I recommend you slowly increase the value while profiling your DC’s with Server Performance Advisor. This way you can avoid overloading the DCs.

If your users are in a domain that is in Native mode a Global catalog (GC) server is required. You can disable this requirement with the IgnoreGCFailures registry key. However, it’s redundant with the group membership caching in Windows Server 2003(and unless you are dealing with a branch office deployment it’s unnecessary). That said, it’s important to point out that if you are in Native mode (users domain) and your secure channel DC is not a GC then the authentication will be proxied to a GC over the GC Channel. Therefore it is a best practice to make sure a GC is placed close (high speed link) to the SharePoint servers.

It is important to note that this is not a SharePoint bottleneck, it’s an NTLM bottleneck. In my next posts I will cover how multiple domains affect this process.