RDP NLA Error: How to Fix Network Level Authentication Fast

Yeah, you're trying to RDP into a machine and Windows throws that NLA error. Annoying as hell. The culprit here is almost always a mismatch in CredSSP settings — either the remote machine has stricter NLA settings than your client expects, or you're dealing with an older RDP client version. Let's fix it.

The Fast Fix (Registry)

Don't bother with disabling NLA on the server — that's lazy and insecure. Instead, adjust the client-side registry to allow older RDP clients. Do this on the machine you're connecting FROM.

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f

That sets the CredSSP patch level to "Vulnerable" (2). It lets your client talk to servers with older encryption oracles. Reboot or restart the RDP service after:

net stop TermService && net start TermService

Now try connecting again. 9 times out of 10, this is it.

When the Registry Fix Doesn't Work

If you still get the error, the remote machine might have NLA forced on via Group Policy. You'll need to check that server directly.

Check Remote Server's NLA Setting

On the server (the one you're connecting TO), open System Properties > Remote tab. Under Remote Desktop, uncheck "Allow connections only from computers running Remote Desktop with Network Level Authentication". Apply, OK, then restart the Remote Desktop Services.

If that box is grayed out, someone set it with Group Policy. Run gpedit.msc and go to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security. Set "Require user authentication for remote connections by using Network Level Authentication" to Disabled.

Why This Works

NLA uses CredSSP to validate the client before the full RDP session starts. When your client's CredSSP version is newer than the server's, or the server expects a specific encryption oracle version, Windows blocks the connection. The registry key AllowEncryptionOracle tells Windows to accept older encryption methods. Setting it to 2 basically says "I know this is less secure, but let me connect anyway". It's a patch for machines that haven't been updated in a while.

Less Common Variations

Windows 7 Clients Connecting to Windows Server 2019

Windows 7 doesn't support the newer CredSSP updates. You'll need to either update the Windows 7 machine with KB4103718 (if you're still maintaining that dinosaur) or do the registry fix above. Honestly, I'd just upgrade the client.

Azure VMs

If you're trying to RDP into an Azure VM and get NLA errors, check the boot diagnostics in the Azure portal. Sometimes the VM's network security group blocks port 3389. Add an inbound rule for TCP 3389 from your IP. Also, make sure the VM's RDP service is actually running — I've seen it crash after Windows updates.

Domain-Joined Machines

In a domain environment, Group Policy might override local settings. Run gpresult /h gp.html on the server to see which policies are applied. Look for the "Allow Encryption Oracle" setting — if it's set to 0 (Force Updated), you can't override it locally. Talk to your domain admin to loosen that policy.

Prevention Tips

• Keep all machines updated. Most NLA errors happen because one side has a newer CredSSP update. Windows 10/11 20H2 and newer are fine.
• If you manage multiple servers, push a GPO that sets AllowEncryptionOracle to 2. It's a security trade-off, but better than having RDP broken across the org.
• Consider using VPN or RD Gateway instead of exposing RDP directly. NLA is just one layer — you don't want brute force attacks on port 3389.
• Test your RDP connections after big Windows updates. The Fall Creators Update in 2017 broke NLA for a lot of people.

That's it. You'll be connected in 10 minutes. If not, double-check that the remote machine is actually running Windows — I've had people try to RDP into a Linux box and wonder why NLA fails.