Allow log on through Remote Desktop: user rights explained

Being able to sign in to a server and being allowed to sign in over Remote Desktop are two different things. Windows checks a set of user rights for every RDP connection. If one is missing, or a deny right matches, the user sees a message that they are not authorized, even with the right password. This guide explains those rights and how to fix the error safely.

Before you start

• Administrator access, either over Remote Desktop to 203.0.113.10:3389 or through the browser console in your VPS provider's control panel.
• The name of the user who cannot connect.
• A Windows edition with secpol.msc: Windows Server, or Windows 10/11 Pro and higher.

The rights that control RDP sign-in

Open Local Security Policy (secpol.msc) and go to Local Policies → User Rights Assignment. Four rights matter:

• Allow log on through Remote Desktop Services: who may start an RDP session. By default this includes Administrators and Remote Desktop Users.
• Deny log on through Remote Desktop Services: who may never start an RDP session. Empty by default.
• Access this computer from the network: with Network Level Authentication (NLA), which is on by default, the user authenticates over the network before the session starts. They need this right too. By default it includes Users and Administrators.
• Deny access to this computer from the network: blocks the NLA step, and so blocks RDP, for anyone listed.

The Remote Desktop Users group

The simplest way to give a normal user RDP access is to add them to the built-in Remote Desktop Users group. That group already has the allow right, so there is no need to edit policy.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "deploy"

Members of Administrators can always sign in over RDP unless a deny right blocks them. Only add people to Administrators if they truly need full control. More on groups in Manage local users and groups on Windows Server.

Check the current settings

The quickest way to see all four rights at once is to export the policy and filter it. In an elevated Command Prompt:

secedit /export /areas USER_RIGHTS /cfg %TEMP%\rights.inf
findstr /i "RemoteInteractiveLogonRight NetworkLogonRight" %TEMP%\rights.inf

Example output:

SeNetworkLogonRight = *S-1-1-0,*S-1-5-32-544,*S-1-5-32-545,*S-1-5-32-551
SeRemoteInteractiveLogonRight = *S-1-5-32-544,*S-1-5-32-555

The values are security identifiers (SIDs). Common ones:

• S-1-5-32-544: Administrators
• S-1-5-32-555: Remote Desktop Users
• S-1-5-32-545: Users
• S-1-1-0: Everyone
• S-1-5-113: Local account (any local user)

A line starting with SeDenyRemoteInteractiveLogonRight or SeDenyNetworkLogonRight shows the deny lists. If either line includes a group your user belongs to, that is the cause.

Fix "not authorized for remote login"

The error usually reads: The connection was denied because the user account is not authorized for remote login. Work through these in order:

1. Group membership. Check the user is in Remote Desktop Users or Administrators:

   Get-LocalGroupMember -Group "Remote Desktop Users"

Add them if missing.

1. Allow right. In secpol.msc, open Allow log on through Remote Desktop Services. Make sure Administrators and Remote Desktop Users are listed. If someone removed them, click Add User or Group and add them back.

1. Deny rights. Open both Deny log on through Remote Desktop Services and Deny access to this computer from the network. Remove the user or group that should not be there. Watch out for Local account and Local account and member of Administrators group. Some hardening baselines add these, and on a standalone server they block every local user.

1. Apply. Run gpupdate /force in an elevated prompt.

The user does not need to restart anything. They just try to connect again.

Restrict RDP to specific people

To allow only certain users over RDP while keeping local access for others:

• Keep the allow right limited to Administrators and Remote Desktop Users.
• Put only approved people in Remote Desktop Users.
• Use the deny right only for specific accounts you want to block, such as a service account that should never sign in interactively.

This keeps the rules easy to follow. Avoid long deny lists, which are hard to audit.

Check it works

Keep your own session open, then ask the user to connect to 203.0.113.10:3389, or test with their account yourself in a second Remote Desktop window. They should reach the desktop. If you changed deny rights, also confirm that your own admin account can still open a new session.

Troubleshooting

• Error persists after adding the user to the group: a deny right still matches. Re-run the secedit export and check the deny lines.
• Setting is greyed out in secpol.msc: a domain or local Group Policy sets it. Run gpresult /h report.html and look for the right in the report.
• "To sign in remotely, you need the right to sign in through Remote Desktop Services": the same issue on newer Windows. Follow the fix steps above.
• You locked out Administrators: sign in through the browser console in your VPS provider's control panel, open secpol.msc and remove Administrators from the deny right.
• Error mentions credentials, not authorization: that is a password problem. See Fix "Your credentials did not work".

Next steps

• Give a new person access step by step: Create a Windows user with RDP access.
• Tour the policy console: Local Security Policy basics.