VPN Access Without Remote Desktop Rights: Four Separate Gates

A user connects to the VPN, opens a file share and an internal application, and then an RDP attempt returns "the user account is not authorized for remote login". Nothing about the tunnel is wrong in that message. Four independent gates sit between a VPN account and an interactive desktop, and only the last one produced it. People usually respond by adding the account to Administrators, which grants far more than the desktop and does not fix the gate if Group Policy denies it. Here is what each gate actually does, and how to change only the one that is refusing.

Four gates sit in a fixed order

The gateway first decides whether the identity may establish a tunnel at all: a RADIUS policy, a group condition, a certificate check, an Access Server permission. Then routing and firewalls decide whether the packet from the tunnel pool reaches the destination's TCP 3389 listener. Then the client's NLA handshake authenticates the account against the destination. Only after those three does the local security authority check whether the account holds the logon right that an interactive remote session requires.

Because the order is fixed, each gate hides the ones behind it. A failed tunnel says nothing about routing; a blocked port says nothing about the logon right; a successful port test says nothing about admission. That is why "the VPN works but RDP does not" is not one problem but a boundary between two of these gates, and why the error text is the fastest way to tell which one you hit.

The right that actually refuses the session

Remote Desktop sign-in requires Allow log on through Remote Desktop Services, the user right SeRemoteInteractiveLogonRight. It is checked at logon, not at tunnel setup, which is why an account can browse the network for hours and still be refused a desktop. The dialog that shows it lives under Local Policies, User Rights Assignment, and the domain equivalent lives in a GPO.

Default membership depends on the machine's role: workstations and member servers grant it to Administrators and Remote Desktop Users, while a domain controller grants it to Administrators only. That single fact explains most of the confusion, because the same account succeeds on a file server and fails on a DC. A deny right beats the matching allow right regardless of group membership, so an account that is both allowed and denied is denied. A broad deny group can catch an administrator who was added as a favour.

Read the effective policy, not the local dialog

Local policy is overwritten by any domain GPO that defines the same right, so the local snap-in can show a correct-looking list while the effective state is different. Export what the machine actually applies, then search for the right and read the SIDs rather than the display names:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

In that output *S-1-5-32-544 is Administrators and *S-1-5-32-555 is Remote Desktop Users.

If neither appears, nobody except a policy holder can open a desktop, no matter what the local Users and Groups dialog suggests. gpresult then names the GPO that won, which is the object you have to edit; changing local policy on a domain-joined machine is a test, not a fix.

Grant the narrowest right that fits

The ordinary answer is the Remote Desktop Users group on the destination. It carries the right by default, it is much smaller than Administrators, and it separates "may open a desktop" from "may manage the server". Where policy has reassigned the right explicitly, add the group or the account to that policy instead of adding a group nobody intended as an access control.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

Check the deny list before you add anything. If a deny right names a group that contains the user, the correct change is removing the account from that group or narrowing the deny, not adding a second allow somewhere else. Record which right you changed and where, because a later GPO refresh will silently restore the previous state and the ticket will reopen with the same message.

Keep the network path a separate decision

The VPN group does not have to reach every port. When a group needs an application and not a desktop, a firewall rule scoped to the tunnel pool and the application port gives effect to that policy, while the logon right stays untouched.

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

OpenVPN's own per-client configuration and Access Server group permissions can restrict the destination prefixes in the same spirit; neither of them grants a Windows logon right, and a logon right cannot open a port. Keep them in separate change windows, because a port rule and an entitlement get approved by different people.

Verify in the same order the gates apply: can the account establish the tunnel, can the session reach the listener, does the client authenticate, and does the account hold the right. A ping that fails while the port test succeeds is a firewall answering differently for ICMP, not proof that RDP is blocked. Microsoft's logon-right reference lists the defaults per machine role and the deny-overrides-allow rule.