RDP Restricted Admin helps an administrator connect to a remote Windows computer without delegating reusable user credentials to it. This reduces a credential-theft risk when the remote computer is compromised. It also changes authentication and onward access, so enabling it is not a complete defence against pass-the-hash.
Choose the connection mode by the threat you need to address. Protecting a legitimate administrator’s credentials from a hostile remote machine is one objective. Preventing a hostile client from logging in with an already stolen secret is another.
Why the remote computer matters
Remote desktop access creates a session on another computer. In a credential-delegating sign-in, credentials available to that remote session can create exposure if the destination is compromised. Microsoft’s credential-protection guidance explains why logon type and the location of credential material matter.
An administrator should therefore avoid treating successful RDP encryption as proof that the destination is safe. The connection can be encrypted while the remote operating system is under someone else’s control. Reduce privileged sign-ins to systems you do not trust and use managed administrative devices.
Restricted Admin and Remote Credential Guard
Microsoft’s Remote Credential Guard documentation compares the two modes. Restricted Admin requires the connecting user to have administrator rights on the destination. Onward network access uses the remote computer’s identity rather than the user’s identity. Remote Credential Guard uses Kerberos and supports onward single sign-on as the user while keeping credentials on the client.
| Decision | Restricted Admin | Remote Credential Guard |
|---|---|---|
| Reusable user credentials delegated to destination | Avoided by this mode | Avoided by this mode |
| Authentication | Can negotiate supported authentication, including NTLM | Requires Kerberos |
| User rights on destination | Administrator rights required | Remote desktop access rights required |
| Onward network identity | Remote computer account | Connecting user |
| Best starting question | Do I need an administrative session without user credential delegation? | Can this environment support protected Kerberos-based user access? |
Compatibility and the intended access path decide which mode can work. Check the supported client, destination, domain relationships and policy in Microsoft’s current deployment guidance. Do not reuse an old registry recipe merely because it appeared in a 2014 article.
The pass-the-hash trade-off
MITRE documents pass-the-hash use with RDP when Restricted Admin is enabled. An intruder who already has suitable NTLM hash material may be able to authenticate to a destination that accepts it. That is different from stealing credentials from a legitimate administrator after they connect.
Keep those directions separate when assessing a product comparison table. A mode can reduce the remote host’s opportunity to capture the user’s secrets while still leaving an incoming authentication route that needs its own restrictions.
This tension was discussed during Aorato’s independent research period, before its acquisition by Microsoft. Mike Pilkington’s November 2014 SANS research examined Restricted Admin and referenced Aorato’s original discussion. Those were the author’s tests on the software of that period. They are useful historical context, not fresh Impulsec measurements of a current Windows build.
Choose and verify a policy
- Identify the account and destination. Record why administrative rights are needed and whether the target is trusted. Avoid routine use of a broadly privileged domain account.
- Check the required workflow. Determine whether the remote session must reach file shares or other services as the user. Restricted Admin’s onward computer identity can change that behaviour.
- Verify the authentication path. For Remote Credential Guard, confirm that Kerberos works for the intended connection. Do not assume every RDP route or intermediary supports the same mode.
- Restrict incoming access. Limit which devices and identities can reach RDP. Treat network reachability, local rights and credential protection as separate checks.
- Test the actual result. Validate the selected mode, expected onward access and failure behaviour in an approved environment before broad rollout. Write down the rollback plan.
A connection that silently falls back to a less protective mode can undermine the intended policy. Verify enforcement rather than relying on a shortcut name or a setting that was applied months ago. Use current vendor guidance for supported configurations.
Add controls around the connection
Credential isolation and unique local administrator passwords address risks that a connection mode alone does not solve. Credential Guard protects supported secrets on eligible systems. Windows LAPS can reduce reuse of local administrator passwords between computers. Neither proves that a remote session or an already compromised account is harmless.
Investigate unexpected administrative logons, unusual source devices and onward access that does not fit the account’s role. A successful authentication record needs context from the destination and the account’s normal activity.
Our hash and ticket reuse comparison explains the underlying credentials. The Windows access-revocation article covers why disabling an account does not instantly terminate every ticket or established session.
My recommendation
Where the required environment supports it, assess Remote Credential Guard first for user-preserving remote access. Use Restricted Admin deliberately when its administrative requirements and onward identity fit the job. In both cases, constrain the source devices, destination rights and accounts that can connect. The mode is one part of a remote-administration policy, not the whole policy.
Share this article
Stuart Kerr Spindlow is Impulsec’s Publisher, Chief Editor and Lead Reviewer. He writes and maintains coverage of consumer cybersecurity and digital-safety software, with a focus on practical suitability, limitations and the evidence behind product claims. Read Stuart’s full profile.