Accesso VPN senza diritti di desktop remoto: quattro porte separate

Un utente si connette alla VPN, apre una condivisione file e un'applicazione interna, poi un tentativo RDP restituisce «l'account utente non è autorizzato all'accesso remoto». In quel messaggio non c'è nulla di sbagliato nel tunnel. Quattro porte indipendenti si frappongono tra un account VPN e un desktop interattivo, e solo l'ultima l'ha prodotto. Di solito le persone reagiscono aggiungendo l'account ad Administrators, il che concede molto più del desktop e non corregge la porta se un criterio di gruppo la nega. Ecco cosa fa davvero ogni porta e come modificare solo quella che rifiuta.

Quattro porte in un ordine fisso

Il gateway decide innanzitutto se l'identità può stabilire un tunnel: un criterio RADIUS, una condizione di gruppo, un controllo del certificato, un'autorizzazione di Access Server. Poi l'instradamento e i firewall decidono se il pacchetto dal pool del tunnel raggiunge il listener TCP 3389 della destinazione. Poi la stretta di mano NLA del client autentica l'account verso la destinazione. Solo dopo queste tre l'autorità di sicurezza locale verifica se l'account possiede il diritto di accesso richiesto da una sessione remota interattiva.

Poiché l'ordine è fisso, ogni porta nasconde quelle dietro di sé. Un tunnel fallito non dice nulla sull'instradamento; una porta bloccata non dice nulla sul diritto di accesso; un test della porta riuscito non dice nulla sull'ammissione. Per questo «la VPN funziona ma RDP no» non è un solo problema ma un confine tra due di queste porte, e per questo il testo dell'errore è il modo più rapido per capire quale hai incontrato.

Il diritto che rifiuta davvero la sessione

L'accesso al desktop remoto richiede il diritto utente Consenti accesso tramite Servizi Desktop remoto, SeRemoteInteractiveLogonRight. Viene controllato all'accesso, non alla creazione del tunnel, perciò un account può navigare la rete per ore e vedersi comunque negato un desktop. La finestra che lo mostra si trova in Criteri locali, Assegnazione diritti utente, e l'equivalente di dominio è in un GPO.

L'appartenenza predefinita dipende dal ruolo della macchina: le workstation e i server membri lo concedono ad Administrators e Remote Desktop Users, mentre un controller di dominio lo concede solo ad Administrators. Questo singolo fatto spiega la maggior parte della confusione, perché lo stesso account riesce su un file server e fallisce su un DC. Un diritto di negazione prevale sul corrispondente diritto di autorizzazione indipendentemente dall'appartenenza al gruppo, quindi un account a cui è sia consentito sia negato viene negato. Un gruppo di negazione ampio può catturare un amministratore aggiunto per favore.

Leggi i criteri effettivi, non la finestra locale

I criteri locali vengono sovrascritti da qualsiasi GPO di dominio che definisca lo stesso diritto, quindi lo snap-in locale può mostrare un elenco che sembra corretto mentre lo stato effettivo è diverso. Esporta ciò che la macchina applica davvero, poi cerca il diritto e leggi i SID invece dei nomi visualizzati:

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

In quell'output, *S-1-5-32-544 è Administrators e *S-1-5-32-555 è Remote Desktop Users.

Se non compare nessuno dei due, nessuno tranne un titolare di criteri può aprire un desktop, qualunque cosa suggerisca la finestra locale Utenti e gruppi. Allora gpresult nomina il GPO che ha vinto, ed è l'oggetto che devi modificare; cambiare i criteri locali su una macchina aggiunta al dominio è un test, non una correzione.

Concedi il diritto più ristretto che serve

La risposta abituale è il gruppo Remote Desktop Users sulla destinazione. Porta il diritto per impostazione predefinita, è molto più piccolo di Administrators e separa «può aprire un desktop» da «può gestire il server». Dove i criteri hanno riassegnato il diritto esplicitamente, aggiungi il gruppo o l'account a quei criteri invece di aggiungere un gruppo che nessuno intendeva come controllo di accesso.

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

Controlla l'elenco delle negazioni prima di aggiungere qualcosa. Se un diritto di negazione nomina un gruppo che contiene l'utente, la modifica corretta è rimuovere l'account da quel gruppo o restringere la negazione, non aggiungere una seconda autorizzazione altrove. Annota quale diritto hai cambiato e dove, perché un successivo aggiornamento dei GPO ripristinerà silenziosamente lo stato precedente e il ticket si riaprirà con lo stesso messaggio.

Tieni il percorso di rete come decisione separata

Il gruppo VPN non deve raggiungere ogni porta. Quando un gruppo ha bisogno di un'applicazione e non di un desktop, una regola del firewall limitata al pool del tunnel e alla porta dell'applicazione dà effetto a quei criteri, mentre il diritto di accesso resta intatto.

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

La configurazione per client di OpenVPN e le autorizzazioni di gruppo di Access Server possono limitare i prefissi di destinazione nello stesso spirito; nessuna delle due concede un diritto di accesso di Windows, e un diritto di accesso non può aprire una porta. Tienile in finestre di modifica separate, perché una regola di porta e un diritto vengono approvati da persone diverse.

Verifica nello stesso ordine in cui si applicano le porte: l'account può stabilire il tunnel, la sessione raggiunge il listener, il client si autentica e l'account possiede il diritto. Un ping che fallisce mentre il test della porta riesce è un firewall che risponde diversamente a ICMP, non la prova che RDP sia bloccato. Il riferimento Microsoft sul diritto di accesso elenca i valori predefiniti per ruolo della macchina e la regola per cui la negazione prevale sull'autorizzazione.