Remote Credential Guard and Restricted Admin Mode: Stop RDP From Leaving Credentials on Every Server You Touch

Every time an administrator opens a standard Remote Desktop session and types a password, that credential lands in the memory of the remote host. LSASS on the target now holds a reusable secret — an NTLM hash, a Kerberos TGT, sometimes the cleartext password — for the lifetime of the session and often long after disconnect. If that server is already compromised, the attacker didn't need to phish you. You walked your Domain Admin token straight into their memory and handed it over. This is the mechanic behind most lateral movement in real intrusions: harvest one credential, RDP outward, harvest the next, repeat until you own the domain.

Windows ships two features that break this loop by keeping the credential on the machine you're sitting at. They solve slightly different problems, and choosing wrong will either fail to protect you or lock your admins out of the servers they need.

The core problem: credential exposure on the target

A normal RDP logon is an interactive network logon. To let you run programs as yourself on the far side, Windows must have your credential material available there. That's convenient and it's exactly what pass-the-hash and pass-the-ticket tooling feeds on. The two mitigations invert the trust model:

• Restricted Admin mode — you log in without sending a credential at all. The remote session runs as the machine's local administrator identity rather than as you. Nothing reusable of yours lands on the target.
• Remote Credential Guard — you still authenticate as yourself and get single sign-on to network resources, but the credentials stay in the client's LSASS. The target proxies auth requests back to your machine instead of holding your secrets.

Restricted Admin mode

Restricted Admin was Microsoft's first answer (KB2871997, back-ported to Windows 7 / Server 2008 R2). Because the session runs as the target's local admin, you get no network SSO — try to reach a file share from inside the session and it fails, because "you" are now the machine account. That property is a feature for jump-box and DMZ scenarios and a nuisance for daily admin work.

Enable it on the target with a registry value, then connect with the client flag:

REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 0 /f

mstsc.exe /restrictedAdmin /v:server01.corp.local

Be deliberate here. Restricted Admin creates a network identity that is the local admin of the target, which means a stolen client session can pass-the-hash outbound to other machines that trust that account. Pair it with unique local admin passwords (see LAPS) so one box's local admin can't authenticate to the next.

Remote Credential Guard

Remote Credential Guard (Windows 10 1607+ / Server 2016+) is the better fit for interactive administration because it preserves SSO. Your Kerberos tickets are requested on demand and served from the client, never persisted on the target. Requirements worth checking before you roll it out:

• Both client and server are domain-joined to the same or trusting domains.
• Authentication is Kerberos — RCG does not work over NTLM, so it also nudges you toward retiring NTLM.
• You are not required to be a local admin on the target (unlike Restricted Admin), so it suits tiered access models.

Allow it on the target and connect:

REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 0 /f

mstsc.exe /remoteGuard /v:server01.corp.local

To make it non-optional fleet-wide, push the policy Restrict delegation of credentials to remote servers under Computer Configuration → Administrative Templates → System → Credentials Delegation and set it to Require Remote Credential Guard. Use Prefer during a pilot so hosts that can't negotiate it fall back rather than fail.

Which one, when

Rule of thumb: Remote Credential Guard for interactive admin of trusted, domain-joined servers where you need SSO; Restricted Admin for untrusted or standalone targets and break-glass access where you want zero of your identity on the box.

Neither is a silver bullet. Restricted Admin can enable outbound pass-the-hash if local admin accounts are shared; Remote Credential Guard still relies on your client being clean, since that's where the credentials now live. Both should sit inside a broader privileged-access design: dedicated admin workstations, the Protected Users group, tiered accounts, and RDP exposure hardening so the front door isn't reachable from the internet in the first place.

Auditing it across your estate

The failure mode isn't configuring one server — it's the drift. A GPO gets scoped to the wrong OU, a new server is provisioned before the baseline applies, or someone flips DisableRestrictedAdmin to 1 to troubleshoot a connection and never reverts it. WinSentinel audits the credential-delegation posture directly: it reports whether DisableRestrictedAdmin is set, whether the Restrict delegation policy requires or merely prefers Remote Credential Guard, and whether NTLM is still available to undercut it — folding the result into the machine's security score alongside the rest of the logon-hardening checks. On the free tier that's the full audit on the machine in front of you, every module, no limits. For an organization running admin jump boxes and server fleets, the Pro central node rolls those per-host results into one view, flags the moment a server drifts off the required-RCG baseline, and lets you dispatch the fix instead of RDP-ing to each box by hand.

Restricted Admin and Remote Credential Guard are among the cheapest high-leverage controls in Windows: a registry value and a GPO that quietly remove the single most valuable thing an attacker harvests from a compromised server — your credentials. Turn them on, require the right one per tier, and audit that they stay on.