NTLM and authentication bottlenecks

Follow the validation path

For domain NTLM authentication, the resource server receives the client’s response and asks a domain controller to validate it through Netlogon. A trusted-domain scenario can add more secure-channel hops. Delays on any of those hops can surface to the user as a credential prompt, a timeout, or access denied.

This path differs from a client obtaining a Kerberos service ticket directly from a KDC. Interactive logon can work while the resource server’s NTLM validation path is unhealthy.

Draw the actual path for the failed request: client, resource server, its contacted DC, and any trusted-domain DC. Collect timestamps on all of them. A packet capture on only the user’s workstation may never show the slow secure-channel operation.

Confirm NTLM is being used

On the accepting machine, inspect the authentication package in a successful or failed logon event. If NTLM auditing has been configured, inspect the Operational channel:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddHours(-1)
} -MaxEvents 100

Check that the necessary audit policies are enabled; having the channel available isn’t enough. Also look for 4776 events in the DC’s Security log where credential validation auditing is enabled. 4776 records both successful and failed NTLM validation, not only failures. It doesn’t identify the destination resource server, so match it with the server’s own events. Microsoft’s event reference explains the fields.

Low CPU can hide a saturated authentication queue

Only a limited number of validation operations can occupy a Netlogon secure-channel path concurrently. A server can have plenty of free CPU and memory while requests wait for a busy or distant DC.

On the machines in the validation path, inspect the available Netlogon performance counters:

Get-Counter -ListSet Netlogon |
    Select-Object -ExpandProperty PathsWithInstances

Use Performance Monitor or a collector to capture Semaphore Waiters, Semaphore Holders, Semaphore Timeouts, and Average Semaphore Hold Time together over the failure window. Counter names are localized; listing the installed set avoids assuming that an English counter path exists everywhere.

Waiters show queued work, holders show occupied slots, and timeouts show callers giving up. Hold time helps distinguish excessive arrival rate from slow completion. A screenshot taken after the incident won’t show which of those caused the outage.

MaxConcurrentApi is a measured tuning decision

First inspect any explicit override:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' `
    -Name MaxConcurrentApi -ErrorAction SilentlyContinue

An absent value means the OS default applies. Microsoft’s guidance records a default of 10 for Windows Server 2012 and later member servers and DCs, with different defaults for workstations and older systems.

If waiters build on one server while it has spare semaphore capacity, examine its downstream DC as well. Raising the first server’s concurrency can simply deliver more work to the same bottleneck. Use the full collection and calculation in Microsoft’s MaxConcurrentApi performance guidance before planning a registry change and Netlogon restart.

Reduce unnecessary validations

Look for an application opening many short-lived authenticated connections, a service retrying with an old password, unexpected fallback from Kerberos, DC selection across a slow link, or an unusually long trust path. Correcting the source of repeated work often has more value than increasing the queue’s capacity.

Do not infer semaphore use from an overall NTLM authentication count. It is not a one-to-one measurement of the constrained operation. Also identify PAC-validation traffic when investigating shared Netlogon dependencies. Microsoft’s hardening timeline records enforced PAC-validation changes from 2025; use the behavior of the installed updates when drawing that path.

Separate validation from session security

NTLM’s negotiate, challenge, and authenticate messages can be carried inside SMB, HTTP, or another application transport. The resource server’s validation request is a separate Netlogon exchange. NTLMv2 improves the response calculation; it does not turn that exchange into Kerberos or give it Kerberos ticket delegation.

Applications can also negotiate signing, sealing, and extended protection around authentication. A successful credential validation therefore does not prove that the application’s integrity or channel-binding requirements were met. Conversely, failure before a validation request reaches a DC may leave no 4776 for the attempt. Microsoft’s NTLM protocol overview separates authentication from the resulting security context.

For example, a resource server in domain R can ask an R DC to validate an A-domain user, with the request continuing to A. If R’s holders are below capacity while A’s queue grows, raising R’s limit won’t create capacity in A. Check the remote instance names in the Netlogon counters and collect over the same window to see where the queue builds.

Capture rate and wait time together

Use a time series rather than a single cumulative timeout total. For a one-minute local sample, after selecting the appropriate installed counter paths:

$paths = (Get-Counter -ListSet Netlogon).PathsWithInstances
Get-Counter -Counter $paths -SampleInterval 5 -MaxSamples 12 |
    Export-Counter -Path .\netlogon-sample.blg -FileFormat BLG

This writes a local performance log. Sample the relevant hops during the same incident and note reboots or counter resets. Look for the timeout counter increasing during the failure; an old nonzero total might be unrelated. Long hold time with modest arrival rate points somewhere different from short hold time with a burst of callers.

If performance evidence does not identify the origin, collect bounded Netlogon debug logging on the relevant machine using the supported logging procedure. Preserve its previous setting and storage limits, then restore that setting afterward. The log can contain account and infrastructure details.

Modern blocking can occur before DC validation

NTLMv1 was removed from Windows 11 24H2 and Windows Server 2025. NTLMv2 remains distinct from that removal, although NTLM is deprecated. Do not describe every newer-system failure as removal of all NTLM. See the Windows Server removed-feature list.

Windows Server 2025 and Windows 11 24H2 also support SMB client NTLM blocking. On a supporting client, inspect its effective configuration:

Get-SmbClientConfiguration |
    Select-Object BlockNTLM
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation' `
    -Name BlockNTLMServerExceptionList -ErrorAction SilentlyContinue

Inspect available properties on that OS and the responsible GPO. This control is for outbound SMB authentication; it is not the domain’s general NTLM restriction policy. A share failing only from hardened clients can therefore have a correct server-side credential-validation path that is never used. Microsoft’s SMB NTLM-blocking guidance explains its scope.

Retire NTLM with an application inventory

Audit the real client and server population first, identify why each application is using NTLM, test Kerberos where the application supports it, then stage restrictions. Blocking NTLM without that inventory can turn a hidden dependency into an outage.

For failures that follow aliases or application identities, start with SPNs. For repeated bad-password traffic, use account lockout investigation.