RDP Network Level Authentication, Restricted Admin Mode, Active Directory: The Three Settings That Decide Who Owns Your Session

Every Remote Desktop hardening checklist ends with the same three items: RDP Network Level Authentication, Restricted Admin Mode, Active Directory cached credentials. Ticking all three does not make a Remote Desktop session safe. Two of them are genuine defensive wins, and the third — Restricted Admin mode — protects the credentials you type while handing an attacker who already holds a hash a way in.

This article separates the three settings, shows how they constrain each other, and gives the registry values, Group Policy paths and event fields needed to audit each one.

What Is RDP Network Level Authentication, Restricted Admin Mode, Active Directory Hardening

A Remote Desktop connection to a domain-joined host involves three independent decisions, each configured in a different place:

1. Network Level Authentication (NLA) — is the user authenticated before a session is established?
2. The security layer — how is the channel itself authenticated and encrypted?
3. Credential delegation mode — does the client send credentials to the remote host at all?

A fourth setting, the number of cached logons, decides how much credential material is left behind on the host afterwards. Most audit tooling reports these as four unrelated checkboxes. In practice they interact: choosing the wrong security layer silently disables NLA, and enabling the "safe" delegation mode changes what an attacker needs in order to log on.

The Security Layer Comes First

The Three Security Layers

Microsoft documents three security layers for an RD Session Host connection. The distinction matters more than it looks, because one of the three is mutually exclusive with NLA:

That last sentence is Microsoft's, from Configure Server Authentication and Encryption Levels. It is the reason a host can carry an "NLA required" policy and still not have NLA in play: where the negotiated layer lands on native RDP encryption, Microsoft's own exclusion applies and Network Level Authentication cannot be used.

Negotiate being the default is the quiet problem, and it is not a legacy artifact: Microsoft's current SecurityLayer reference still documents 1 (negotiate) as "the default value". It does not enforce TLS — it accepts whatever the client offers and downgrades to the RDP Security Layer for a client that claims no TLS support. An attacker controlling the client side of the handshake controls that choice.

Encryption Levels

A separate setting, the encryption level, governs key strength. Microsoft lists four values, with Client Compatible as the default:

Low is worth stating plainly: it leaves server-to-client traffic — the screen contents of an administrative session — in the clear.

All of these settings live under Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security, and Microsoft notes that these Group Policy settings "will take precedence over the settings configured in Remote Desktop Session Host Configuration, with the exception of the Server Authentication Certificate Template policy setting."

Why Network Level Authentication Matters

NLA moves user authentication ahead of session establishment. Microsoft's original description is still the clearest: it "completes user authentication before you establish a Remote Desktop connection and the logon screen appears," and the stated advantages are that the remote computer "uses a limited number of resources before authenticating the user" and that this "can help provide better security by reducing the risk of denial-of-service attacks" (Configure Network Level Authentication).

The value of that pre-authentication boundary is not theoretical. In the workarounds published with its advisory for CVE-2019-0708, the pre-authentication Remote Desktop Services remote code execution vulnerability commonly called BlueKeep, Microsoft wrote:

NLA turned a wormable pre-auth bug into a post-auth one. That is the whole argument for requiring it — it puts every future pre-authentication RDP vulnerability behind a credential check.

The host-side setting is a single registry value:

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

1 requires NLA, 0 disables it. Microsoft's own Azure VM troubleshooting guidance uses exactly this value to temporarily disable and re-enable NLA — which is also how it tends to get switched off permanently during an incident and never switched back.

Restricted Admin Mode: The Control That Cuts Both Ways

Restricted Admin mode changes what the client sends. Microsoft's Remote Credential Guard documentation lists its security benefits precisely:

• Credentials aren't sent to the remote host
• The Remote Desktop session connects to other resources as the remote host's identity
• An attacker can't act on behalf of the user and any attack is local to the server

Microsoft's comparison table marks Restricted Admin mode as preventing Pass-the-Hash, and for helpdesk scenarios explicitly recommends it: "RDP connections should only be initiated using the /RestrictedAdmin switch." Note also that RDP access under Restricted Admin is granted by membership of the Administrators group on the remote host, not the Remote Desktop Users group.

Both the mode and Remote Credential Guard depend on one host-side value:

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

The Inversion

Here is where the two readings diverge, and the distinction is directional.

Microsoft's claim is about credentials leaving the client: with Restricted Admin, nothing lands on the remote host, so nothing can be harvested there and replayed. That is true.

The consequence is about credentials entering the host. Because the client no longer sends a password, the logon is satisfied with credential material the client already holds — which means an NTLM hash is sufficient. Public research documented this the year the feature shipped. Portcullis Labs (author MRL, 20 October 2013) described the client sending "empty credentials in the TSPasswordCreds structure" on Windows 8.1 and Windows Server 2012 R2, and demonstrated authentication by passing a hash where the password would go. Their proof of concept was not a stock client: it required FreeRDP-pth, a patched FreeRDP whose -p argument carries an NT hash instead of a password.

# FreeRDP-pth, the 2013 patched client — -p takes the NT hash
xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

A stock build will not accept that: it treats the hash as a plaintext password and the logon fails. Current FreeRDP implements the capability natively, with the option documented as "Pass the hash (restricted admin mode)":

xfreerdp3 /u:test /pth:36374BD2767773A2DD4F6B010EC5EE0D /v:192.168.226.129

The same post notes the technique works only for administrators — members of the Remote Desktop Users group cannot authenticate this way. With the native Windows client, the equivalent is injecting the hash into a logon session first:

sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:"mstsc.exe /restrictedadmin"

So both statements hold. Restricted Admin mode prevents your credentials being stolen from the remote host, and it lowers the bar for logging on to that host from a plaintext password to a hash. If pass-the-hash is already viable in your environment, enabling Restricted Admin mode domain-wide extends it to interactive RDP access on every host where it is turned on.

There is a second consequence. Because authentication is evaluated against a token rather than a typed password, controls enforced at the destination can be bypassed. SpiderLabs (Apurva Goenka, 15 November 2023 — published under Trustwave, since acquired by LevelBlue) documented that authentication "doesn't take place on the Remote Desktop server but instead on the client itself," so "authentication factors enforced on the destination server such as MFA provisioned via Duo, Okta...are rendered ineffective" (Restricted Admin Mode – Circumventing MFA On RDP Logons).

Cached Logons: What Stays Behind

Cached domain credentials let a user sign in when no domain controller is reachable. Microsoft's guidance on Interactive logon: Number of previous logons to cache (in case domain controller is not available) states the risk directly: "An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords." The cached information "does not expire, but can get overwritten."

The default is 10 logons on member servers and client computers, and the accepted range is 0 through 50. Microsoft's defaults table lists the domain controller effective default as No effect — the setting simply does not apply there.

Be careful how you cite the recommendation, because Microsoft's own page is not one-voiced. Its Countermeasure section says to configure the value to 0, disabling local caching. Its Best practices section says the Windows security baselines "don't recommend configuring this setting" at all. Its Potential impact section suggests 2 for end-user computers so mobile users can still sign in off-network. The defensible position for a Tier 0 member server is a low value; for laptops, 0 breaks offline logon entirely. One caveat that is routinely got wrong: this setting does not apply to domain controllers, whose effective default Microsoft lists as "No effect" — DCs hold the directory and do not cache domain logons.

Detection

Event 4624 carries the fields needed to distinguish these logons. Version 2 of the event (Windows 10 and later) added a RestrictedAdminMode field, which per Microsoft is "only populated for RemoteInteractive logon type sessions" and is a Yes/No flag indicating whether Restricted Admin mode was used.

That detail matters for writing a correct rule: a Restricted Admin RDP session is still Logon Type 10 (RemoteInteractive), not Type 3. The mode is visible in the flag, not in the logon type.

Microsoft's monitoring recommendation on that same page is worth adopting verbatim: if Restricted Admin mode must be used by certain accounts, monitor logons for those accounts with Logon Type = 10 and Restricted Admin Mode = "Yes", and trigger an alert when Restricted Admin Mode = "No" for them. Inverting it is equally useful — alert when RestrictedAdminMode = "Yes" for accounts that should never use it, since attacker tooling reaches for /restrictedadmin precisely because it accepts a hash.

Auditing the Configuration

Auditing the configuration itself is a registry read on each host:

$ts = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
Get-ItemProperty -Path $ts -Name UserAuthentication, SecurityLayer, MinEncryptionLevel
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name DisableRestrictedAdmin -ErrorAction SilentlyContinue

An absent DisableRestrictedAdmin value means the mode is not enabled; a value of 0 means it is.

Remediation

1. Require TLS as the security layer. Enable Require use of specific security layer for remote (RDP) connections and select SSL, under Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security. Issue RD Session Host certificates from your internal CA rather than accepting the self-signed default.

2. Require NLA. In the same policy path, enable Require user authentication for remote connections by using Network Level Authentication. Group Policy takes precedence over local configuration, which is what you want for drift control.

3. Raise the encryption level. Set Set client connection encryption level to High so that traffic is 128-bit in both directions, and confirm no host is left at Low.

4. Decide on Restricted Admin mode deliberately, per tier. Do not enable it domain-wide by reflex. Where administrators connect to lower-trust hosts, prefer Remote Credential Guard via the Restrict delegation of credentials to remote servers policy set to Require Remote Credential Guard. Where it is genuinely needed for helpdesk work, enable it only on those hosts and alert on its use elsewhere. Note Microsoft's caveat: when Restrict Credential Delegation is enabled, "the /restrictedAdmin switch will be ignored" and Remote Credential Guard is used instead.

5. Enable delegation of nonexportable credentials on remote hosts — required for both Restricted Admin and Remote Credential Guard — via Remote host allows delegation of nonexportable credentials.

6. Lower cached logons on servers. Set Interactive logon: Number of previous logons to cache to a low value under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Validate against your offline-logon requirements before applying it to laptops.

7. Deploy LAPS. Microsoft pairs its Restricted Admin guidance with Windows LAPS, which "mitigates the risk of lateral escalation" from shared local administrator passwords — the exact condition that makes a single stolen hash useful on every host.

Verify the Result

Verify the result rather than trusting the GPO report:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" |
    Select-Object UserAuthentication, SecurityLayer, MinEncryptionLevel

UserAuthentication should be 1 and SecurityLayer should be 2 (TLS).

These controls reinforce each other with the rest of your authentication hardening — requiring TLS on RDP is the same argument as requiring SMB signing and LDAP signing on NTLM relay paths, and constraining who may reach Tier 0 over RDP is inseparable from constraining Kerberos delegation and password policy.

How EtcSec Detects This

EtcSec audits these four settings independently, because they fail independently. PA038_RDP_NLA_NOT_REQUIRED raises a finding when no GPO in the domain sets UserAuthentication to 1. PA038_RDP_SECURITY_LAYER_WEAK fires unless a policy pins the security layer to TLS, so the Negotiate default that can silently downgrade is reported too. TERMINAL_SERVICES_NOT_HARDENED covers the broader Terminal Services and RDP configuration surface, and CACHED_LOGONS_EXCESSIVE fires on a Winlogon\CachedLogonsCount above 4. These are policy-level checks: a clean result means the policy exists, and confirming it actually landed on every host is still the registry read above.