all of sudden windows machines failing to authenticate for domain users.

Hi srikanth byragoni,

Event 5719 indicates that the computer could not set up a secure session with a domain controller, while 5783 signifies that the session to the DC is down. This explains why authentication fails even though the DC is reachable via basic port checks; the pipe used for NTLM authentication is saturated or unresponsive due to the high load generated by your SQL or backup processes.

To investigate the MaxConcurrentApi bottleneck, you must use Performance Monitor (perfmon.exe) to look at the Netlogon object. Open Performance Monitor, click the green plus sign to add counters, and locate the Netlogon section in the list. Within this section, select the Semaphore Waiters counter and add it to the view. This counter represents the number of threads waiting to obtain a slot in the Netlogon queue to perform NTLM authentication. If this value is consistently greater than zero during the issue, it confirms that your server is unable to process authentication requests fast enough, causing the 15-minute delays you observed during RDP attempts.

If the Semaphore Waiters counter validates this bottleneck, you should increase the MaxConcurrentApi registry value. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters and create a new DWORD named MaxConcurrentApi if it does not already exist. For a Windows Server handling heavy SQL or application traffic, setting this value to 10 (decimal) is a common starting point, though it can be increased up to 150 if necessary. This change requires a restart of the Netlogon service to take effect. This adjustment allows the server to handle more simultaneous authentication threads, preventing the queue buildup that leads to the 5719 and 5783 errors.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Hello,

I'm writing to follow up on the authentication drops you are experiencing on your SQL servers. Based on the symptoms, domain logins failing while local admin access remains functional, the primary suspect remains Ephemeral Port Exhaustion. If you have had the chance to check the System Event Log for Event ID 4227 or run the netstat command during an outage, confirming a high number of connections in the TIME_WAIT state would validate the need to adjust the TcpTimedWaitDelay and MaxUserPort registry keys.

If the port usage appeared normal during the incident, we should pivot to investigating a potential MaxConcurrentApi bottleneck. This occurs when the Netlogon service cannot handle the volume of authentication requests, which is common in high-load SQL environments using NTLM. You can verify this by checking the "Semaphore Waiters" counter under the Netlogon performance object; a non-zero value indicates that the authentication queue is backing up, requiring a different registry adjustment.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

Hello srikanth byragoni,

This specific behavior where domain authentication fails while local administration and basic network connectivity remain intact, strongly points to Ephemeral Port Exhaustion on the affected Windows Servers. Since these are SQL servers, they are likely generating a high volume of outbound connections or handling a massive number of client requests that are leaving TCP ports in a TIME_WAIT state. When the dynamic port range (defaulting to approximately 16,000 ports on Windows Server 2008 and later) is fully consumed, the operating system cannot allocate a new source port to establish the necessary RPC or Kerberos connection to the Domain Controller for user authentication. Local login continues to work because it validates against the local SAM database and does not require an outbound network socket. The 3-4 hour auto-resolution likely coincides with the completion of a specific SQL job or application workflow that finally releases the held sockets, or the natural expiration of enough TIME_WAIT states if the storm subsides.

To confirm this diagnosis, you need to examine the System Event Log on an affected server for Event ID 4227 ("TCP/IP failed to establish an outgoing connection because the selected local endpoint was recently used to connect to the same remote endpoint"). When the issue is active, open an administrative command prompt or PowerShell session and run netstat -ano | find /c "TIME_WAIT". If this return value is close to or exceeds the default dynamic port range limit (typically around 16,000 if not customized), you have confirmed port exhaustion. You should also check if the MaxUserPort registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters has been modified; if it is absent, the system uses the default range.

If port exhaustion is the root cause, the immediate remediation involves tuning the TCP/IP stack to accommodate the SQL workload. You should navigate to the registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and set (or create) a DWORD value named TcpTimedWaitDelay with a decimal value of 30 (reducing the wait time from the default 240 seconds). Additionally, creating a DWORD named MaxUserPort and setting it to 65534 (decimal) will expand the available ephemeral port range to its maximum. A server reboot is required for these registry changes to take effect. If the issue persists despite these changes, you should then investigate the Netlogon performance counter specifically for "Semaphore Waiters" to rule out a MaxConcurrentApi bottleneck, though port exhaustion remains the primary suspect given the SQL context.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP