RDP error: Network Level Authentication failed

You type your user name and password into Remote Desktop Connection, click Connect, and before any sign-in screen appears you get an error message. No desktop, no progress bar, nothing. That is exactly what an NLA problem looks like: Network Level Authentication runs before the session is created. If it fails, you never get to see a sign-in prompt where you could correct anything.

This article walks through the realistic causes in the order in which they actually show up, and for each one it gives you the check command, the fix, and the way back in when RDP is completely dead.

The error messages word for word

There is not one message but a handful, and the exact wording already narrows the cause down a lot. These are the variants you will run into most often:

• "The remote computer requires Network Level Authentication, which your computer does not support." The server demands NLA and the client does not deliver it. Typical for old clients, for third-party clients on Linux or macOS, and for badly configured client policies.
• "An authentication error has occurred. The Local Security Authority cannot be contacted." Usually quoted in short form as "LSA cannot be contacted". This is the classic certificate or clock skew message.
• "An authentication error has occurred. The function requested is not supported." That is almost always CredSSP, not NLA in the narrow sense. More on this below.
• "The credentials that were used to connect did not work." Account locked out, disabled, password expired, or the account is missing from the Remote Desktop Users group.
• "The trust relationship between this workstation and the primary domain failed." The computer account in the domain no longer matches.

One important distinction: if the client tells you after twenty seconds that the remote computer cannot be reached, that is not an NLA error but a network, firewall or stopped service problem. NLA errors come back fast, usually within one to three seconds, because the TCP connection is up and only the authentication fails.

Cause 1: Clock skew between client and server

This is by far the most common cause, and it is also the one most often overlooked, because "the clock is a bit off" sounds like a harmless problem. It is not. Two mechanisms break the moment the clock drifts:

• Kerberos tolerates a maximum of five minutes of deviation by default. Beyond that, the domain controller rejects the request with KRB_AP_ERR_SKEW. This affects every domain member.
• The TLS check of the RDP certificate fails when the clock on the client falls outside the validity window of the server certificate. This also hits standalone servers without a domain, and specifically in the case where the server comes up after a reboot with a clock set in the past, so a freshly generated certificate is not valid yet from the point of view of the client.

Check on the server, in a PowerShell session with administrator rights:

w32tm /query /status /verbose
w32tm /query /source
w32tm /stripchart /computer:ptbtime1.ptb.de /samples:5 /dataonly

The stripchart gives you the offset in seconds. Anything below one second is fine, anything above 60 seconds is suspicious, and anything above 300 seconds explains the error.

This is where the systems part ways, and most guides throw both into the same pot:

• Standalone server without a domain: set an external NTP source.
• Domain member: never set your own peer list here. A member server has to take its time from the domain hierarchy, otherwise it drifts away from the domain controller.

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 time.windows.com,0x9" /syncfromflags:manual /update

w32tm /config /syncfromflags:domhier /update

In both cases, restart the service afterwards and synchronize:

net stop w32time
net start w32time
w32tm /resync /rediscover

One special case that catches you out on virtualized servers: if the clock is off by exactly one or two hours, that is not drift but a difference in how the hardware clock is interpreted. Windows expects the RTC in local time, while many virtualization platforms provide it in UTC. Check the time zone first, then switch the interpretation if that is really the problem:

tzutil /g
tzutil /s "W. Europe Standard Time"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Cause 2: Expired or wrongly bound certificate

Without a PKI of your own, Windows generates a self-signed certificate for RDP that is valid for roughly half a year and normally renews itself. "Normally" is the operative word here. If the renewal fails because of permissions in the key store, or if a manually bound certificate from an internal CA expires, you can no longer sign in and you get the message about the Local Security Authority.

Check what is actually there:

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Select-Object Subject, NotBefore, NotAfter, Thumbprint

And then which certificate the listener really uses:

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash

Compare the returned hash with the thumbprints from the first command. Two failure patterns are possible: the hash points to an expired certificate, or it points to a certificate that is not in the store at all any more.

The repair consists of removing the binding and deleting the old certificate. Windows then generates a new one when the service starts:

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -ErrorAction SilentlyContinue

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item

Restart-Service TermService -Force

Two warnings about this. First, restarting TermService drops every existing RDP session, including your own if you somehow still have one. Run it from the console. Second, if a group policy specifies a certificate template for server authentication, the server pulls its certificate from the internal CA. If the CA is unreachable or the template has expired, no new certificate arrives and the error stays. In that case, check the CA first, not the server.

How to confirm success: the first command now returns a certificate with a NotAfter date in the future, and SSLCertificateSHA1Hash points to exactly that certificate.

Cause 3: Account locked out, disabled or password expired

This is where the trap sits that sets NLA apart from every other sign-in problem: with NLA enabled you cannot change an expired password through the RDP client. The dialog "Your password has expired and must be changed" only appears inside the session, and you do not get to the session without passing authentication. Instead, the client simply tells you that the credentials did not work. The password is perfectly correct, it has only expired.

Look at the status of a local account:

net user Administrator

Pay attention to the lines "Account active", "Account expires", "Password expires" and "Password expirable". The matching countermeasures:

net user Administrator "NeuesLangesPasswort!2026"

Enable-LocalUser -Name "Administrator"

Set-LocalUser -Name "Administrator" -PasswordNeverExpires $true

A local account that is locked out after too many failed attempts is a separate state, and it is cleared neither by Enable-LocalUser nor by a password change. It unlocks itself once the lockout duration has passed, which you can look up like this:

net accounts

To unlock immediately without any graphical management tool, go through ADSI:

$u = [ADSI]"WinNT://./Administrator,user"; $u.IsAccountLocked = $false; $u.SetInfo()

If RDP ports are reachable from the internet, lockouts happen practically every day, because bots work their way through your administrator account. That is a strong argument for restricting access instead of unlocking the account over and over again. A different port helps noticeably against mass scans, see changing the RDP port without a reboot.

Finally, group membership. The group name is localized, which scripts tend to trip over. To query it independently of the language, use the well-known SID:

Get-LocalGroupMember -SID "S-1-5-32-555"

Cause 4: NLA disabled or half disabled on the server

Two separate switches determine the behavior, and it is exactly their combination that causes trouble. UserAuthentication controls NLA, SecurityLayer controls the transport security with the values 0 for the old RDP security layer, 1 for negotiate and 2 for enforced TLS.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

The typical dead end: someone switches NLA off because a certificate problem is suspected, but leaves SecurityLayer at 2. That keeps the TLS negotiation with the broken certificate in place, and only the wording of the error changes. If you really want to lower both settings for diagnosis, lower both of them, and restore them afterwards.

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'") | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=0}

The second dead end is even more unpleasant: you set the registry value, reboot, and it is back at 1. In that case it comes from a group policy. Policy values live somewhere else and always win:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication

gpresult /r /scope:computer

As long as a value is set there, every local change only lasts until the next policy refresh. The policy is called "Require user authentication for remote connections by using Network Level Authentication" and has to be changed on the domain controller.

And the most important rule to close this section: switching NLA off permanently is not a solution, it is an open door. Without NLA, anyone who can reach the port can talk to the sign-in screen and therefore to an unprotected part of the session stack. Switch it off for diagnosis, then switch it back on.

Cause 5: Broken domain trust relationship

Every computer account in a domain has a password of its own, which is changed automatically every 30 days by default. If the versions on the server and on the domain controller no longer match, the server can no longer authenticate domain accounts, and NLA fails for every domain user while local accounts keep working. That exact pattern is the proof for this cause.

The classic trigger in server operations is a rollback to an older state, for example from a backup or snapshot that is older than the last password change. Check it:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:meinedomaene.local

Repair it, signed in as a local administrator through the console:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Reset-ComputerMachinePassword -Credential (Get-Credential)

Removing the machine from the domain and rejoining it is not necessary here, and it often makes things worse, because group memberships and permissions of the old computer account can be lost in the process. After the repair, a restart of the Netlogon service is enough:

Restart-Service Netlogon

When RDP is dead: the way in through the console

All the commands so far assume that you can get onto the server somehow. In a real emergency that is exactly what you cannot do. On the KVM root servers from KernelHost you therefore get a VNC console in the customer panel that works independently of RDP, of the Windows firewall, and even of the network stack of the guest system. That is the emergency access with which you get yourself out of any of the situations described above. For dedicated servers, emergency access runs through support.

Three things behave differently on the VNC console than in an RDP session, and they cost time on a regular basis:

• Keyboard layout. The console often gives you a US layout while Windows is set to German, or the other way around. Special characters in passwords then end up wrong, and you take a correct password for a wrong one. When in doubt, use the on-screen keyboard with osk.exe from the sign-in screen.
• Clipboard. Copying from your own machine into the console usually does not work. Expect to type things out, and pick temporary passwords accordingly.
• Signing in as a local account. With domain problems, sign in as .\Administrator, because the dot and the backslash force the local account instead of the domain account.

On the console you then check the basics before you start touching NLA:

sc query TermService

netstat -ano | findstr :3389

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

If fDenyTSConnections is set to 1, remote connections are switched off completely, independently of NLA:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

You enable the firewall rules in a language-independent way through the internal group identifier, because the displayed group name differs depending on the system language:

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

The CredSSP special case that often gets confused

If the message says literally "The function requested is not supported" and mentions the CredSSP encryption oracle remediation, then none of the five causes above is to blame. Here the patch levels of client and server do not match: one side demands the hardened CredSSP variant, the other does not know it yet.

The only clean solution is to update both sides. The registry change with AllowEncryptionOracle on the client that circulates online disables exactly the hardening that causes the error, and with it reopens a known attack path. If you do need it briefly in order to install the updates, set it back as soon as the server is up to date.

How you know it is really fixed

A successful connection is the weakest proof, because it also works when you have switched NLA off for diagnosis. Check the following instead, one after the other:

1. NLA is active again. UserAuthentication is set to 1 and SecurityLayer to 2.
2. The clock is correct. The offset from the stripchart is below one second, and w32tm /query /source names a real source, not "Local CMOS Clock" and not "Free-running System Clock".
3. The certificate is valid. NotAfter is in the future, and the bound hash points to exactly that certificate.
4. The event log confirms that network authentication passed. Event 1149 only appears once NLA has been completed, which makes it the real proof.

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Where-Object Id -eq 1149

For the counter-check on failed attempts, the status codes in event 4625 say more than any client message: 0xC0000071 stands for an expired password, 0xC0000072 for a disabled account, 0xC0000234 for a locked out account and 0xC000006A for a genuinely wrong password.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

And finally the sessions themselves, ideally from the console:

qwinsta

A short reference for troubleshooting

When you set up a new Windows server, it pays to get the time source, the account policies and the access path right from the start, instead of repairing them later under pressure. A good guide for that is the checklist for a new root server, and if you want to secure RDP access on top of that, changing the RDP port without a reboot is the least demanding first step against automated sign-in attempts.