This troubleshooting topic for the IT professional describes how to configure MaxConcurrentAPI to remediate Net Logon service authentication bottlenecks beginning with Windows Server 2003.
This topic presents the following concepts for the Net Logon service and NTLM pass-through authentication to give you the understanding how to configure MaxConcurrentAPI when authentication bottlenecks occur:
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.
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 time out, 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.
The network logon service (NetLogon) implements pass-through authentication. It performs the following functions:
The domain name is passed to LsaLogonUser. The domain name is processed as follows:
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
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.
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.
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.
Resources for impacted technologies
How to configure an ISA Server computer for a very large number of authentication requests
Network Policy Server
The Case of the Mysterious Exchange Server Hang
MaxConcurrentAPI Stories - Chris Gideon
NTLM Authentication with SharePoint - Chris Gideon
NTLM Authentication and SharePoint Part 2 - Chris Gideon
Congratulations Eric Mitchell MSFT, very good article about MaxConcurrentAPI