RDP Hardening: Using Local Security Policy to Limit User Rights

Local Security Policy on Windows Server decides who may log on through Remote Desktop and what those accounts can do once they are inside. This guide walks through RDP hardening with Local Security Policy by editing User Rights Assignment in secpol.msc, so a compromised RDP account cannot quietly become a local administrator.

Before you start

• A Windows VPS or Admin RDP plan with Administrator access. Connect as 203.0.113.10:3389.
• A second administrator account you have already signed in with at least once, plus a standard test account.
• Your VPS provider's control panel open at your VPS provider's control panel so you can reach the browser console if RDP stops working.
• Basic familiarity with secpol.msc. If it is new to you, read Local Security Policy basics on Windows Server first.

Open Local Security Policy and record the current state

1. Sign in over RDP as 203.0.113.10:3389 with an administrator account.
2. Press Win+R, type secpol.msc and press Enter. Accept the UAC prompt.
3. Expand Security Settings > Local Policies > User Rights Assignment. Each entry is a right granted to accounts or groups.
4. Export the current policy so you have a rollback point:

mkdir C:\temp
secedit /export /cfg C:\temp\secpol-before.inf

Open the file in Notepad. The lines that matter start with SeRemoteInteractiveLogonRight, SeDenyRemoteInteractiveLogonRight, SeInteractiveLogonRight and SeDebugPrivilege. Keep this file.

Restrict who can log on through Remote Desktop

This is the most valuable setting in the console. By default, members of Administrators and Remote Desktop Users may connect.

1. Create a dedicated group for people who need a desktop, not full control:

net localgroup "RDP-Operators" /add
net localgroup "RDP-Operators" deploy /add

1. In secpol.msc, open Allow log on through Remote Desktop Services.
2. Keep Administrators in the list. Add RDP-Operators. Remove Remote Desktop Users if you want one explicit group to audit.
3. Open Deny log on through Remote Desktop Services and add accounts that must never connect: Guest, service accounts, and any local account used by an application.

Strip standing administrator rights from RDP users

A user rights policy is only half the job. If the account is still in the local Administrators group, it can undo everything you configured.

1. List current administrators:

net localgroup Administrators

1. Remove the day-to-day account:

net localgroup Administrators deploy /remove

1. Confirm the account is now standard, then sign out and back in so the token is rebuilt:

whoami /groups | findstr /i "S-1-5-32-544"

No output means the account is no longer an administrator. Keep at least one separate administrator account for maintenance.

Lock down the dangerous user rights

Work through these in secpol.msc and make sure each lists only Administrators, or nobody at all:

• Debug programs — lets a process read another process's memory. Remove everyone except Administrators.
• Take ownership of files or other objects — grants access to any file on disk.
• Back up files and directories and Restore files and directories — these bypass file permissions entirely.
• Load and unload device drivers — kernel-level access.
• Create a token object — should be empty.
• Impersonate a client after authentication and Replace a process level token — leave these with Administrators and the service accounts that genuinely need them, such as NT SERVICE\MSSQLSERVER on a SQL Server host.
• Change the system time and Shut down the system — remove interactive users unless they need it.
• Deny log on locally, Deny log on as a batch job, Deny log on as a service — add service accounts and any account that should only ever arrive over RDP.

Apply the policy and save a baseline

1. Force the policy to apply immediately:

gpupdate /force

1. Export the hardened state so you can reapply it after a rebuild:

secedit /export /cfg C:\temp\secpol-hardened.inf

1. Sign out completely, then sign back in as the standard RDP user. User rights are evaluated at logon, so an existing session keeps its old token.

To reapply later on a rebuilt server:

secedit /configure /db C:\temp\secedit.sdb /cfg C:\temp\secpol-hardened.inf /areas USER_RIGHTS

Check it works

• As the standard user, run whoami /priv. You should see few privileges and no SeDebugPrivilege.
• Run whoami /groups and confirm the account is not in BUILTIN\Administrators.
• Try to open secpol.msc as the standard user. It should fail with an access denied message.
• Run query user from an administrator session to see who is connected.
• From a second machine, try to connect as an account on the deny list. The connection should be refused before the desktop loads.
• Open Event Viewer > Windows Logs > Security and look for event ID 4625 (failed logon) and 4624 (successful logon) entries matching your tests.

Troubleshooting

• "The connection was denied because the user account is not authorized for remote login." The account is missing from Allow log on through Remote Desktop Services, or it sits in the deny right. Add it to the allow list, run gpupdate /force, and reconnect.
• Nobody can reach RDP, including administrators. Open the browser console from your VPS provider's control panel and add Administrators back to the allow right, or restore C:\temp\secpol-before.inf with secedit /configure. If the server is unreachable, an OS reinstall from your VPS provider's control panel is the last resort.
• Your changes disappear after a reboot. A domain Group Policy is overriding the local policy. Run gpresult /h C:\temp\gpresult.html and check which GPO wins — local settings lose to domain settings.
• The standard user still gets UAC prompts for admin tasks. The account is still in Administrators, possibly through a nested group. Check with net localgroup Administrators and whoami /groups.
• A service stops starting after you edited user rights. You removed a right the service account needs. Re-add that specific account to Log on as a service and Impersonate a client after authentication, then restart the service.

Next steps

• Allow log on through Remote Desktop: user rights explained covers the logon rights you just edited in more depth.
• RDP Hardening: Preventing Privilege Escalation via Group Policy takes the same idea further with GPO-based restrictions.
• Set an account lockout policy against RDP password guessing so brute-force attempts are stopped automatically.
• Windows Server: Securing Remote Desktop Session Management (RDP) Best Practices adds session timeouts and Network Level Authentication.