Windows Server: Enable Network Level Authentication (NLA) on RDP

Network Level Authentication (NLA) checks a user's credentials before Windows Server builds a full Remote Desktop session. With NLA on, an unauthenticated client never reaches the logon screen, so anonymous connections, scanner traffic and pre-auth resource use stop at the door. This guide turns NLA on for your Windows VPS or Admin RDP — by GUI, PowerShell and Group Policy — and then confirms it works on TCP port 3389.

Before you start

• Administrator access to the server and its local or domain account credentials.
• A second way in. Open the browser console in your VPS provider's control panel and keep that tab open until you have reconnected with RDP successfully.
• A client that supports CredSSP: Windows 7 / Server 2008 R2 or later with current updates, or a current Microsoft Remote Desktop app on macOS, iOS or Android.
• Your connection details from your VPS provider's control panel: the server IP and the RDP port (3389 unless it was changed).
• Note the current RDP settings so you can compare afterwards.

Read the current state first. UserAuthentication = 1 means NLA is on, 0 means it is off.

$rdp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
Get-ItemProperty -Path $rdp | Select-Object UserAuthentication, SecurityLayer, PortNumber

PortNumber should show 3389. If it shows another port, check the port guide linked at the end before you continue.

Enable NLA on Windows Server RDP

Option 1: System Properties

1. Run sysdm.cpl (or open Settings, System, About, Advanced system settings).
2. Go to the Remote tab.
3. Tick Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended).
4. Click Apply, then OK.

The checkbox writes the same registry value described below, so you can use whichever route suits your workflow.

Option 2: PowerShell

This is the fastest route on a fresh VPS and the easiest to script across several servers.

$rdp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
Set-ItemProperty -Path $rdp -Name UserAuthentication -Value 1 -Type DWord
Get-ItemProperty -Path $rdp -Name UserAuthentication

The change applies to new connections. Sessions that are already open stay connected, so a current admin session keeps running while you test.

NLA works with the default SecurityLayer value of 1 (Negotiate), which lets the client and server agree on TLS. Leave it alone unless you have a specific reason to pin the transport layer.

Option 3: Group Policy

Use this when several servers must share the setting, or when you want the configuration to survive a rebuild from a golden image.

1. Run gpedit.msc for a local policy, or open Group Policy Management on a domain.
2. Navigate to Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security.
3. Open Require user authentication for remote connections by using Network Level Authentication and set it to Enabled.
4. Apply the policy.

gpupdate /force

Group Policy reasserts the value on refresh, so if someone later flips the checkbox in System Properties, the policy will put it back. Check with gpresult /h %temp%\rsop.html if the setting does not seem to take.

Check it works

1. Confirm the port is reachable from your workstation:

Test-NetConnection 203.0.113.10 -Port 3389

TcpTestSucceeded: True means the network path is open.

1. Connect with an explicit port:

mstsc /v:203.0.113.10:3389

With NLA enabled, the credential prompt appears before the session is created. You should see the certificate confirmation (once), the username and password box, and only after a successful sign-in does the remote desktop and its logon screen appear.

1. Re-read the registry value to confirm it stuck:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication

1. Review recent sessions on the server side:

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' -MaxEvents 10 |
  Select-Object TimeCreated, Id, Message

You should see logon and reconnect events that line up with your test connections, and nothing from addresses you do not recognise.

Troubleshooting

• "The remote computer requires Network Level Authentication, which your computer does not support" — the client is old or missing CredSSP updates. Update the client OS or app rather than switching NLA off on the server; a current Microsoft Remote Desktop build on Windows, macOS, iOS and Android all support it.
• "An authentication error has occurred. The function requested is not supported" — usually a CredSSP mismatch between an unpatched client and a patched server. Patch both sides and reboot before changing any registry workaround you find online.
• Connection drops right after you enter credentials — the account may lack the right to sign in over RDP. Add it to the local Remote Desktop Users group, or check Allow log on through Remote Desktop Services in secpol.msc.
• You cannot connect at all after the change — open the browser console in your VPS provider's control panel, set UserAuthentication back to 0, reconnect on port 3389, and fix the client before re-enabling.

Next steps

• Secure Remote Desktop on Windows Server for the wider checklist around NLA.
• Check that Windows is listening on RDP port 3389 if connections behave strangely.
• RDP Hardening: Preventing Privilege Escalation via Group Policy to limit what a signed-in session can do.
• Connect to your Admin RDP from Windows, Mac and phone.