Remote Desktop on Entra-joined devices, managed by Intune

Turning on Remote Desktop is a checkbox. Turning it on for the right devices, letting in the right people, and then actually connecting from a machine that is not part of your tenant — that took a whole afternoon, and four of the five obstacles announced themselves as something other than what they were.

A design with two levels

RDP is attack surface. It deserves to be decided twice: on which machines it exists, and who may use it.

Level	Controls	How
Device	Which PCs have RDP enabled at all	Policies assigned to a device group
User	Who may connect to them	An Entra group added to the local Remote Desktop Users group

Enabling the service is not enough on its own. On an Entra-joined device only the primary user and local administrators can connect. A Standard user — which is what the Autopilot profile creates — has to be authorised explicitly.

The two groups

• RDP-Enabled-Devices — type Assigned, not dynamic. This is deliberate: a dynamic rule would switch RDP on for every device that happens to match it. For something that opens an inbound port, decide machine by machine.
• RDP-Users — type Assigned. The people allowed to connect.

Three policies, all assigned to the device group

A — Enable the service

Devices → Configuration → Create policy → Settings catalog.

Setting	Value
Allow users to connect remotely by using Remote Desktop Services	Enabled
Require user authentication for remote connections by using NLA	Enabled

B — Open the firewall

Endpoint security → Firewall → Windows Firewall Rules.

Field	Value
Direction	In
Action	Allow
Protocol	6 (TCP)
Local Port Ranges	3389
Remote Address Ranges	192.168.50.0/24
Profiles	Domain, Private — never Public

Restricting the remote address range is what turns “RDP is on” into “RDP is on, from where I said”. If remote access arrives through a VPN subnet router, traffic reaches the device already translated to the router’s address, so the range can be narrowed to that single IP.

C — Authorise the users

Endpoint security → Account protection → Local user group membership.

Field	Value
Local group	Remote Desktop Users
Action	Add (Update)
Selected users/groups	the Entra group RDP-Users

Account protection policies are among the slowest to be delivered. Give them time before concluding that something is wrong — which brings us to the first false alarm.

Obstacle 1 — the group that looked empty

On the device, the obvious check:

net localgroup "Remote Desktop Users"

The list came back empty. The policy appeared not to have worked.

It had worked from the start. net localgroup does not display Entra members. It is an old tool that understands local and domain accounts and silently omits what it cannot describe.

Get-LocalGroupMember "Remote Desktop Users"

ObjectClass  Name                        PrincipalSource
-----------  ----                        ---------------
Other        S-1-12-1-213546227-...      AzureAD

Entra members appear as SIDs beginning S-1-12-1-, with source AzureAD. That is correct and expected — do not go looking for a readable name.

Obstacle 2 — credentials refused

With the group confirmed, mstsc to the device, username AzureAD\user@domain — refused.

Cause: NLA cannot validate cloud credentials when the client and the target do not share a domain or tenant. The client has no way to prove who the user is to the target machine before the session starts.

Fix: mstsc → Show options → Advanced → “Use a web account to sign in to the remote computer”. In an .rdp file this is enablerdsaadauth:i:1. The client obtains an Entra token and presents that instead.

Obstacle 3 — “using an IP address is not supported”

With the web account enabled, connecting by IP stops working. The token is issued for a device, and a device is identified by name.

So: use a name. Which raises the question of where that name resolves.

Obstacle 4 — DNS that only works at home

A host override on the local firewall (WA-AUTOPILOT001.home.arpa → 192.168.50.21) resolves beautifully at home and means nothing from anywhere else, because a client on someone else’s network uses their resolver.

The portable answer is an entry in the client’s hosts file.

Obstacle 5 — AADSTS293004

Name in place, connection attempted, and:

AADSTS293004: The target-device identifier ... was not found in the tenant

Cause: connecting to WA-AUTOPILOT001.home.arpa, Entra looks for exactly that string among the devices in the tenant. The device object is called WA-AUTOPILOT001 — no suffix. The lookup fails.

Fix: put the bare name in the hosts file and connect to WA-AUTOPILOT001.

Result: sign-in with the Entra user plus MFA, RDP session established from an unjoined client on an external network.

Two alternatives, and why they were not taken

Disabling NLA. mstsc would then show the machine’s own logon screen, where AzureAD\user@domain can be typed without a token or an FQDN. It works everywhere. It also exposes a logon screen to anyone who can reach port 3389 before any authentication has happened. Fine in a lab you are debugging; not something to leave in place.

Installing a mesh VPN client on the VM. It would become a node with a name resolvable from anywhere, and the hosts file would disappear from the problem. Genuinely tempting. The reason to hesitate is that it adds an access path that lives outside the Intune perimeter — one more thing that grants entry and is not governed by the policies in this series.

The errors, in short

Symptom	Cause
RDP enabled but every connection times out	The policy does not open the firewall — that is a separate rule
Remote Desktop Users appears empty	net localgroup hides Entra members — use Get-LocalGroupMember
Credentials refused with AzureAD\user@domain	NLA cannot validate cloud credentials between unrelated tenants → use a web account
“Using an IP address is not supported”	The web-account flow needs a name, not an address
AADSTS293004	The name used does not match the device name in Entra — drop the internal suffix
A firewall policy that never applies	Platform set to Windows (ConfigMgr) instead of Windows