I recently did a investigation troubleshooting why a user who was fully in the domain‑group authorised for RDP — kept getting “not authorised for remote login” on a Windows server. The server was domain‑joined, Group Policy said the user had RDP access, and there were no deny rules. Yet login kept failing silently.
Here is the path I followed — the rabbit‑holes I went down — and ultimately what exposed the real problem. I hope this helps any sysadmin who runs into similar confusion.
1. Understanding Windows RDP access: two gates
When Windows allows someone to log on via RDP (on a typical server or workstation), two conditions must be satisfied.
Issue 1 : User Right “Allow log on through Remote Desktop Services”
This is the user‑right, internally known as SeRemoteInteractiveLogonRight. You configure it via:
Computer Configuration → Policies → Security Settings
→ Local Policies → User Rights Assignment
→ Allow log on through Remote Desktop Services
You list the users or groups you trust. By default, built‑in Administrators and Remote Desktop are allowed. (Microsoft Learn)
Issue 2 : Actual local group membership (or equivalent)
In practice, “being allowed” isn’t enough if the user’s account isn’t effectively permitted by membership in either:
- The local Remote Destkop Users group, or
- A group with equivalent privileges
A widely cited real‑world example shows this clearly: a domain group was granted the user‑right, but RDP still failed — until the group was added to the local Remote Desktop Users group.
“To use Remote Desktop Services to successfully log on to a remote device, the user or group must be a member of the Remote Desktop Users or Administrators group and be granted the Allow log on through Remote Desktop Services right.” (Microsoft Learn)
In other words — both conditions must be satisfied.
2. My setup: I thought both gates were satisfied
Here was my assumption:
- I used GPO to assign the “Allow log on through Remote Desktop Services” right to a domain‑wide group (e.g BEAR\Local-Access-Users)
- I also used a “Restricted Groups” GPO to control membership of the local Remote Desktops Users group. I assumed this would add the same group (or equivalent) to local group membership.
Specifically, Restricted Groups looked like:
Restricted Groups → Local Group: Remote Desktop Users
Members: BEAR\TerminalServicesAccess, BEAR\Administrator-ServerAdministrators
But Local-Access-Users was not in that list.
So even though I had given them the user right (Condition 1), Condition 2 failed — they were not in any group permitted to log on via RDP.
3. Investigation Logic
I went down several tracks before spotting the real issue:
| Attempt | What I checked / changed | Result |
|---|---|---|
| Verified “Allow log on through RDS” included domain group | gpresult /rsop.msc on the server | Showed correctly applied |
| Checked there was no “Deny logon” policy | Verified GPO, no deny entries | Still failed |
| Removed disconnected sessions (in case of session limit) | Cleared stale sessions | No change |
| Considered Network Level Authentication (NLA) / credential issues | Checked NLA / registry | Not relevant — other users could login |
Looked at registry under HKLM\SYSTEM\…\RDP‑Tcp for explicit allow/deny lists |
No relevant entries (UserFilter, etc.) | Nothing blocking there |
Each step appeared correct — until I re‑examined how Restricted Groups works.
4. How Restricted Groups work
As per Microsoft documentation: Restricted Groups is used to control local group membership. It takes away any prior members not listed, and ensures only the configured members remain. (Microsoft Learn)
This means:
- Members not in the “Members” list are removed.
- Local group membership is effectively controlled, and overrides what someone might manually add.
Therefore, since I had not placed Local-Access-Users into the “Members of Remote Desktop Users” in Restricted Groups, on policy refresh the group was removed (or simply never added).
Therefore comdition 2 failed every time. Users were allowed by right, but not permitted by group membership.
5. The fix: unify both configuration aspects
To fix it, I had to:
- Update the Restricted Groups GPO definition:
Local group : Remote Desktop Users
Add the group: BEAR\Local-Access-Users - Force a policy refresh on target servers:
gpupdate /force - Confirm local group membership
net localgroup "Remote Desktop Users"
That added condition 2. Combined with condition 1 (user‑right), RDP works again.
6. Why this is not obvious — and why it causes confusion
A lot of documentation talks only about the user right (Allow log on through RDS), or only about “add this group to Remote Desktop Users group.” The requirement for both is often glossed over or buried.
Many admins assume granting the right is enough; others use Restricted Groups to enforce local membership — but mixing the two without properly reconciling membership leads to silent failures.
Microsoft documentation itself states:
“To use Remote Desktop Services to successfully sign in to a remote device, the user or group must be a member of the Remote Desktop Users or Administrators group and be granted the Allow log on through Remote Desktop Services right.” (Microsoft Learn)
Powershell Used during Investigation
Here are the key steps I followed — in script/snippet form — to diagnose and fix the issue:
# 1. Verify effective rights on server
gpresult /r /scope computer | Select-String -Pattern "Remote Desktop Services"
# 2. List local Remote Desktop Users group membership
net localgroup "Remote Desktop Users"
# 3. Add the domain group to local RDP‑Users (if not present)
// This should be done via GPO Restricted Groups — not manually on each server
# 4. Force policy update
gpupdate /force
# 5. Re-check membership
net localgroup "Remote Desktop Users"
# 6. Attempt RDP login
mstsc.exe /v:<server>
References
- Microsoft: “Allow log on through Remote Desktop Services” policy setting — explains
SeRemoteInteractiveLogonRight. (Microsoft Learn) - Microsoft: Documentation on Restricted Groups — how it manages local group membership and can overwrite existing membership. (Microsoft Learn)
Conclusion
When you deploy RDP access via GPO in a corporate environment, you must treat “user rights” and “group membership” as separate — and mandatory — gates.
Using Restricted Groups requires you to explicitly list every group or user you want to allow in Remote Desktop Users If you forget one, logons will silently fail with “not authorised”, even though the user‑right seems correct.