Share via

Windows: Configuring MaxConcurrentAPI for NTLM Pass-Through Authentication

  • Article

This troubleshooting topic for the IT professional describes how to configure MaxConcurrentAPI to remediate Net Logon service authentication bottlenecks beginning with Windows Server 2003.

Introduction

This topic presents the following concepts for the Net Logon service and NTLM pass-through authentication to give you the understanding of how to configure MaxConcurrentAPI when authentication bottlenecks occur:

Understanding how NTLM pass-through authentication uses the Net Logon service

When a domain-joined server receives an NTLM authentication request for a domain account, NTLM pass-through ([MS-APDS] Section 3.1) occurs. The NTLM server uses the Netlogon pass-through method ([MS-NRPC] Section 3.2) to exchange messages with the domain controller (DC). The Net Logon service establishes a secure channel between the server and the domain controller and passes the challenge response through the secure channel to a domain controller. The domain controller returns the account’s information used by Winlogon and security groups. The Net Logon service starts automatically when the computer is a member of a domain, and automatically regulates the number of its RPC requests across the secure channel to prevent domain controllers from being overwhelmed with authentication requests.

NTLM pass-through authentication, as well as Kerberos PAC validation for non-privileged services and Digest validation, are performed by dedicated threads in the Lsass.exe process on Windows-based computers. There are a maximum number of these threads that are available to handle these requests concurrently, and if the requests exceed the availability of the threads and the requests cannot wait any longer, authentication time-out occurs.

The setting for MaxConcurrentAPI specifies the maximum number of simultaneous, logon-related, application programming interface (API) calls that can be transmitted across a secure channel at any one time. Because MaxConcurrentAPI can be set differently on each computer, a variety of interplays can happen. The following example provides an explanation of how MaxConcurrentAPI manages these transmissions. The values listed in this example are not necessarily default values.

  • Workstations A, B and C with MaxConcurrentAPI = 1
  • Member server A with MaxConcurrentAPI = 5
  • Member server B with MaxConcurrentAPI = 10
  • Domain controller with MaxConcurrentAPI = 10
  • Trusted domains = 7

MaxConcurrentAPI always defaults to 1 per secure channel on workstations. The member servers are allocated only one secure channel to a domain controller in their domain but in this example, member server A can use 5 threads and member server B can use 10 threads in their secure channels for pass-through authentication. The domain controller has one secure channel for each trust it is forwarding the authentication request to, and in this example, MaxConcurrentAPI is set to 10 threads on the DC. So the total number of Net Logon service request slots equals 70 (7 X 10). And the number of threads, set by MaxConcurrentAPI, which the domain controller can handle is 10.

The optimal setting can be dependent upon a number of processing conditions in your environment. See the Knowledge Base articles listed below for some of those conditions.

MaxConcurrentAPI is implemented using semaphore objects, which will be displayed in the performance monitoring tool. The semaphore object limits the number of concurrent threads to the value of MaxConcurrentAPI. If the number of concurrent requests ever exceeds MaxConcurrentAPI, the excess requests are queued and then serviced randomly. The bottleneck occurs when a thread waits for 45 seconds and more Net Logon service requests are being issued. As the threads timeout, the client computer attempts another Net Logon service request through the member server to the domain controller. These subsequent requests result in a prompt to the user to re-enter credentials before the new request is queued on the member server, repeating the cycle.

Understanding Netlogon pass-through authentication

The network logon service (NetLogon) implements pass-through authentication. It performs the following functions:

  • Selects the domain to pass the authentication request to
  • Selects the server within the domain
  • Passes the authentication request through to the selected server to the domain controller.

The domain name is passed to LsaLogonUser. The domain name is processed as follows:

  1. If the domain name matches the name of the SAM database, the authentication is processed on that computer. On a Windows workstation that is a member of a domain, the name of the SAM database is considered to be the name of the computer. On an Active Directory domain controller, the name of the account database is the name of the domain. On a computer that is not a member of a domain, all logons process requests locally.
  2. If the specified domain name is trusted by this domain, the authentication request is passed through to the trusted domain. On Active Directory domain controllers, trusted domains can be set. On a member of a domain, the request is always passed through to the domain member’s domain, letting that domain controller determine whether the specified domain is trusted.
  3. If the domain name specified is not trusted by the domain, the authentication request is processed on the computer being connected to as if the domain name specified were that domain name. The Net Logon service does not differentiate between a nonexistent domain, an untrusted domain, and an incorrectly typed domain name.

The Net Logon service selects a server in the domain by a process called discovery. A Windows workstation discovers the name of one of the domain controllers in its domain. That domain controller then discovers the name of an Active Directory domain controller in each trusted domain. The component that does the discovery is the DC Locator that runs in the Net Logon service. The DC Locator uses either NETBIOS or DNS name resolution to locate the necessary servers, depending on the type of domain and trust that is configured.

What is MaxConcurrentApi?

MaxConcurrentApi is a registry key which specifies the maximum number of simultaneous, logon-related, application programming interface (API) calls that can be transmitted across a secure channel at any one time.

Location: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Default:

  • domain joined workstations: 1. One call at a time on member workstations.
  • domain joined servers: 10 beginning with Windows Server 2012. 10 threads for member servers. (Prior to Windows Server 2012 default was 2.)
  • domain controllers: 10 beginning with Windows Server 2012.  10 threads for domain controllers. (Prior to Windows Server 2012 default was 1.)

API calls can be transmitted concurrently only on secure channels that are digitally signed or encrypted.

Configuring MaxConcurrentApi

The default value is optimal for most installations, but you can add the MaxConcurrentAPI entry to the registry to increase its value.

Warning: Increasing the MaxConcurrentApi value to greater than 10 may result in other resource bottlenecks such as exhausting the resources of the contacted domain controller or pass-through domain controllers or impact host performance. Therefore, the load and the performance of the desired setting should be tested in a nonproduction environment before you implement the change in a production environment. Additionally, be aware that service load conditions may change based on each scenario and business environment. Therefore, monitoring NetLogon performance is advised as the MaxConcurrentApi value might need to be changed if the service load changes significantly.

To calculate the appropriate value to set MaxConcurrentAPI and configure it, see How to do performance tuning for NTLM authentication by using the MaxConcurrentApi setting.

Additional resources

Resources for impacted technologies

Technologies Resources

ISA

How to configure an ISA Server computer for a very large number of authentication requests

Network Policy Server

NPS: MaxConcurrentApi

Exchange

The Case of the Mysterious Exchange Server Hang

SharePoint

MaxConcurrentAPI Stories - Chris Gideon

NTLM Authentication with SharePoint - Chris Gideon

NTLM Authentication and SharePoint Part 2 - Chris Gideon