Desktop remoto su dispositivi Entra joined, gestito da Intune

Abilitare l'RDP via policy non apre il firewall, net localgroup nasconde i membri Entra, e AADSTS293004 vuol dire che il nome digitato non è quello giusto.

Accendere il desktop remoto è una casella da spuntare. Accenderlo sui dispositivi giusti, far entrare le persone giuste, e poi collegarsi davvero da una macchina che non appartiene al tenant: quello è costato un pomeriggio, e quattro ostacoli su cinque si sono presentati come qualcosa di diverso da ciò che erano.

Un disegno a due livelli

L’RDP è superficie d’attacco. Merita di essere deciso due volte: su quali macchine esiste, e chi può usarlo.

Livello	Cosa controlla	Come
Dispositivo	Su quali PC l’RDP è abilitato	Policy assegnate a un gruppo di dispositivi
Utente	Chi può connettersi	Un gruppo Entra aggiunto al gruppo locale Remote Desktop Users

Abilitare il servizio non basta. Su un dispositivo Entra joined possono collegarsi solo l’utente principale e gli amministratori locali. Un utente Standard — cioè quello che crea il profilo Autopilot — va autorizzato esplicitamente.

I due gruppi

RDP-Enabled-Devices — tipo Assigned, non dinamico. È una scelta: una regola dinamica accenderebbe l’RDP su ogni dispositivo che dovesse rientrarci. Per una cosa che apre una porta in ingresso, si decide macchina per macchina.
RDP-Users — tipo Assigned. Le persone autorizzate.

Tre policy, tutte assegnate al gruppo di dispositivi

A — Abilitare il servizio

Dispositivi → Configurazione → Crea criterio → Catalogo impostazioni.

Impostazione	Valore
Consenti agli utenti la connessione remota tramite Desktop remoto	Attivata
Richiedi l’autenticazione utente per le connessioni remote con NLA	Attivata

B — Aprire il firewall

Sicurezza degli endpoint → Firewall → Windows Firewall Rules.

Campo	Valore
Direzione	In
Azione	Consenti
Protocollo	`6` (TCP)
Porte locali	`3389`
Indirizzi remoti	`192.168.50.0/24`
Profili	Dominio, Privato — mai Pubblico

Restringere l’intervallo di indirizzi remoti è ciò che trasforma «l’RDP è acceso» in «l’RDP è acceso, e solo da dove ho detto io». Se l’accesso remoto arriva da un subnet router VPN, il traffico raggiunge il dispositivo già tradotto all’indirizzo del router, quindi l’intervallo si può stringere a quel solo IP.

C — Autorizzare gli utenti

Sicurezza degli endpoint → Protezione account → Appartenenza a gruppi utente locali.

Campo	Valore
Gruppo locale	Remote Desktop Users
Azione	Add (Update)
Utenti/gruppi selezionati	il gruppo Entra `RDP-Users`

Le policy di protezione account sono fra le più lente a essere consegnate. Dai loro tempo prima di concludere che qualcosa non funziona — il che ci porta al primo falso allarme.

Primo ostacolo — il gruppo che sembrava vuoto

Sul dispositivo, il controllo ovvio:

net localgroup "Remote Desktop Users"

L’elenco è tornato vuoto. Sembrava che la policy non avesse funzionato.

Aveva funzionato dall’inizio. net localgroup non mostra i membri Entra. È uno strumento vecchio, che conosce gli account locali e di dominio e omette in silenzio ciò che non sa descrivere.

Get-LocalGroupMember "Remote Desktop Users"

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

I membri Entra compaiono come SID che iniziano per S-1-12-1-, con origine AzureAD. È corretto e previsto: non cercare un nome leggibile.

Secondo ostacolo — credenziali rifiutate

Confermato il gruppo, mstsc verso il dispositivo, utente AzureAD\utente@dominio — rifiutato.

Causa: la NLA non può validare credenziali cloud quando client e bersaglio non condividono un dominio o un tenant. Il client non ha modo di dimostrare chi sia l’utente alla macchina remota prima che la sessione inizi.

Rimedio: mstsc → Mostra opzioni → Avanzate → «Usa un account Web per accedere al computer remoto». In un file .rdp corrisponde a enablerdsaadauth:i:1. Il client ottiene un token Entra e presenta quello.

Terzo ostacolo — «l’utilizzo di un indirizzo IP non è supportato»

Con l’account web attivo, collegarsi per indirizzo IP smette di funzionare. Il token viene emesso per un dispositivo, e un dispositivo si identifica con un nome.

Quindi serve un nome. Il che apre la questione di dove quel nome si risolva.

Quarto ostacolo — un DNS che funziona solo a casa

Un host override sul firewall di casa (WA-AUTOPILOT001.home.arpa → 192.168.50.21) risolve benissimo in casa e non significa niente da fuori, perché un client sulla rete di qualcun altro usa il resolver di quella rete.

La risposta portatile è una voce nel file hosts del client.

Quinto ostacolo — AADSTS293004

Nome a posto, connessione tentata, e:

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

Causa: collegandosi a WA-AUTOPILOT001.home.arpa, Entra cerca esattamente quella stringa fra i dispositivi del tenant. L’oggetto si chiama WA-AUTOPILOT001, senza suffisso. La ricerca fallisce.

Rimedio: mettere nel file hosts il nome nudo e collegarsi a WA-AUTOPILOT001.

Esito: accesso con l’utente Entra più MFA, sessione RDP stabilita da un client non aggregato, su rete esterna.

Due alternative, e perché non le ho prese

Disattivare la NLA. mstsc mostrerebbe direttamente la schermata di accesso della macchina, dove si può digitare AzureAD\utente@dominio senza token né FQDN. Funziona ovunque. Espone però una schermata di accesso a chiunque riesca a raggiungere la porta 3389 prima di qualsiasi autenticazione. Accettabile in un laboratorio che stai sbrogliando; non una cosa da lasciare accesa.

Installare un client VPN mesh sulla VM. Diventerebbe un nodo con un nome risolvibile da ovunque, e il file hosts uscirebbe dal problema. Sinceramente allettante. Il motivo per esitare è che aggiunge una via d’accesso che vive fuori dal perimetro Intune: una cosa in più che fa entrare e che non è governata dalle policy di questa serie.

Gli errori, in breve

Sintomo	Causa
RDP abilitato ma ogni connessione va in timeout	La policy non apre il firewall: è una regola a parte
Remote Desktop Users sembra vuoto	`net localgroup` nasconde i membri Entra — usare `Get-LocalGroupMember`
Credenziali rifiutate con `AzureAD\utente@dominio`	La NLA non valida credenziali cloud fra tenant estranei → usare l’account web
«L’utilizzo di un indirizzo IP non è supportato»	Il flusso con account web vuole un nome, non un indirizzo
`AADSTS293004`	Il nome usato non coincide con quello del dispositivo in Entra — togliere il suffisso interno
Una policy firewall che non si applica mai	Piattaforma impostata su Windows (ConfigMgr) invece di Windows