I know that error dialog is infuriating — you're just trying to remote in and Windows decides to slam the door. Let's get you back in.
The quick fix (do this first)
Nine times out of ten, this error means the user account isn't in the Remote Desktop Users group on the target machine, or a GPO is overriding that group. Start here:
- Log into the target machine locally (or via console access) with an admin account.
- Open
compmgmt.msc. - Go to Local Users and Groups → Groups → Remote Desktop Users.
- Add the user or the domain group they belong to.
- Sign out and back in on the client, then try RDP again.
If you're on a domain and the machine is managed by Group Policy, the local group edit will get wiped on the next gpupdate. In that case, push the membership from the domain side:
net localgroup "Remote Desktop Users" "DOMAIN\username" /add
Run that from an elevated prompt on the target. It's faster than clicking through the GUI and it works the same way.
If the group is already correct
Then a GPO is blocking session access. This is where 0X00001B85 usually lives on managed networks. The relevant policy is under:
Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections
Check two settings:
- Allow users to connect remotely using Remote Desktop Services — must be Enabled.
- Restrict Remote Desktop Services users to a single Remote Desktop Services session — if Enabled, only Administrators can create a second session. Regular users get bumped with this exact error.
Set the second one to Disabled or Not Configured unless you have a reason to limit sessions. I've seen this bite admins who enable it 'for security' and forget about it for six months.
Check the session permissions directly
There's a permissions layer most people forget about: rdsec.msc. It's the RDP-Tcp listener's own ACL, and it's separate from group membership. If a security template or a hardening script tightened this, you'll get 0X00001B85 even though the user is in Remote Desktop Users.
- On the target, open Administrative Tools → Remote Desktop Services → Remote Desktop Session Host Configuration.
- Under Connections, right-click RDP-Tcp → Properties → Security tab.
- Confirm Remote Desktop Users has User Access and Guest Access permissions.
- Confirm Administrators has Full Control.
If something looks off, hit Advanced → Restore Defaults. That resets the ACL to a known-good state and clears out whatever hardening script broke it.
Why this actually works
RDP access is checked in two places: the user rights assignment ("who can log on through Remote Desktop Services") and the listener ACL ("who can touch this connection"). Windows evaluates both. Fail either one and you get the same error code — which is why this thing is so annoying to diagnose. Group membership fixes the first layer. rdsec.msc fixes the second. GPOs and the single-session restriction live in between and can override both.
The single-session policy in particular is nasty because it doesn't just deny the new session — it fails the connection attempt outright with 0X00001B85 if the connecting user isn't an admin. That's why admins test with their own account, see it work, and then get confused when the regular user still can't get in.
Less common causes
1. The user is in a Deny logon group
Check secpol.msc → Local Policies → User Rights Assignment for Deny log on through Remote Desktop Services. If the account (or a group it's nested in) is listed there, deny always wins. Remove it.
2. RDP certificate mismatch on the listener
If the RDP-Tcp listener has a cert that expired or was issued for a different hostname, some clients report session access errors instead of the usual certificate warning. WMI query to check:
Get-WmiObject -Namespace root\cimv2\terminalservices -Class Win32_TSGeneralSetting | Select-Object SSLCertificateSHA1Hash
Clear that hash if you're not enforcing TLS, or rebind a valid cert.
3. NLA policies on the client vs server
If the server has Require Network Level Authentication enabled and the client is hitting it with saved credentials from a different domain, the pre-auth fails and you can land here. Fix from the client:
cmdkey /list
cmdkey /delete:TERMSRV/servername
Then reconnect and enter credentials fresh.
4. Third-party RDP wrappers
Some remote management tools (older SolarWinds agents, certain Citrix connectors) hook into the RDP stack and corrupt the listener's security descriptor. If this started right after installing something, uninstall it and run Restore Defaults on the RDP-Tcp listener.
Prevention
Set the RDP-Tcp listener ACL once and baseline it. Export it with netsh or document it in your config management so a hardening script can't silently change it. Keep the single-session restriction off unless you have a specific reason — the security benefit is thin and the support tickets are not.
On the domain side, put RDP access in a group policy that targets Remote Desktop Users directly instead of relying on nested groups. Nested membership is where Deny rules sneak in and where troubleshooting goes sideways. And when someone reports 0X00001B85, ask two questions before touching anything: "Did this ever work for this user?" and "What changed last week?" The answer usually points straight at the culprit.