Accés a la VPN sense drets d’escriptori remot: quatre portes separades

Un usuari es connecta a la VPN, obre un recurs compartit i una aplicació interna, i després un intent d’RDP retorna «el compte d’usuari no està autoritzat per a l’inici de sessió remot». En aquest missatge no hi ha res dolent pel que fa al túnel. Entre un compte de VPN i un escriptori interactiu hi ha quatre portes independents, i només l’última el va produir. Normalment la gent respon afegint el compte a Administrators, cosa que atorga molt més que l’escriptori i no arregla la porta si la política de grup la denega. Aquí tens què fa realment cada porta i com canviar només la que rebutja.

Quatre portes en un ordre fix

La passarel·la primer decideix si la identitat pot establir un túnel: una política RADIUS, una condició de grup, una comprovació de certificat, un permís d’Access Server. Després l’encaminament i els tallafocs decideixen si el paquet del pool del túnel arriba a l’oient TCP 3389 de la destinació. Després l’aplec NLA del client autentica el compte contra la destinació. Només després d’aquests tres, l’autoritat de seguretat local comprova si el compte té el dret d’inici de sessió que exigeix una sessió remota interactiva.

Com que l’ordre és fix, cada porta amaga les que té al darrere. Un túnel fallit no diu res de l’encaminament; un port bloquejat no diu res del dret d’inici de sessió; una prova de port correcta no diu res de l’admissió. Per això «la VPN funciona però l’RDP no» no és un sol problema sinó una frontera entre dues d’aquestes portes, i per això el text de l’error és la manera més ràpida de saber a quina has topat.

El dret que realment rebutja la sessió

L’inici de sessió a l’escriptori remot requereix el dret d’usuari Permetre l’inici de sessió a través dels serveis d’escriptori remot, SeRemoteInteractiveLogonRight. Es comprova en iniciar la sessió, no en configurar el túnel, i per això un compte pot navegar per la xarxa durant hores i tot i així se li denega un escriptori. El diàleg que el mostra és a Polítiques locals, Assignació de drets d’usuari, i l’equivalent de domini és en una GPO.

La pertinença per defecte depèn del rol de la màquina: les estacions de treball i els servidors membres el concedeixen a Administrators i Remote Desktop Users, mentre que un controlador de domini el concedeix només a Administrators. Aquest sol fet explica la major part de la confusió, perquè el mateix compte funciona en un servidor de fitxers i falla en un DC. Un dret de denegació supera el dret d’autorització corresponent independentment de la pertinença al grup, així que un compte que té alhora permís i denegació queda denegat. Un grup de denegació ampli pot atrapar un administrador afegit com a favor.

Llegeix la política efectiva, no el diàleg local

Qualsevol GPO de domini que defineixi el mateix dret sobreescriu la política local, així que l’element incrustat local pot mostrar una llista que sembla correcta mentre l’estat efectiu és diferent. Exporta què aplica realment la màquina, després cerca el dret i llegeix els SID en lloc dels noms de visualització:

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

En aquesta sortida, *S-1-5-32-544 és Administrators i *S-1-5-32-555 és Remote Desktop Users.

Si no hi apareix cap dels dos, ningú excepte un titular de política pot obrir un escriptori, faci el que faci el diàleg local d’usuaris i grups. Llavors gpresult anomena la GPO que ha guanyat, i aquest és l’objecte que has d’editar; canviar la política local en una màquina unida al domini és una prova, no una solució.

Concedeix el dret més estret que encaixi

La resposta habitual és el grup Remote Desktop Users a la destinació. Porta el dret per defecte, és molt més petit que Administrators i separa «pot obrir un escriptori» de «pot administrar el servidor». On la política ha reassignat el dret explícitament, afegeix el grup o el compte a aquesta política en lloc d’afegir un grup que ningú no va pensar com a control d’accés.

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

Comprova la llista de denegacions abans d’afegir res. Si un dret de denegació anomena un grup que conté l’usuari, el canvi correcte és treure el compte d’aquest grup o reduir la denegació, no afegir un segon permís en un altre lloc. Anota quin dret has canviat i on, perquè una actualització posterior de la GPO restaurarà silenciosament l’estat anterior i el tiquet es reobrirà amb el mateix missatge.

Mantén la ruta de xarxa com una decisió a part

El grup de la VPN no ha d’arribar a tots els ports. Quan un grup necessita una aplicació i no un escriptori, una regla de tallafocs limitada al pool del túnel i al port de l’aplicació dona efecte a aquesta política, mentre el dret d’inici de sessió queda intacte.

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

La configuració per client d’OpenVPN i els permisos de grup d’Access Server poden restringir els prefixos de destinació en el mateix esperit; cap dels dos no atorga un dret d’inici de sessió de Windows, i un dret d’inici de sessió no pot obrir un port. Mantén-los en finestres de canvi separades, perquè una regla de port i un dret s’aproven per persones diferents.

Verifica en el mateix ordre en què s’apliquen les portes: pot el compte establir el túnel, pot la sessió arribar a l’oient, s’autentica el client i té el compte el dret. Un ping que falla mentre la prova de port té èxit és un tallafocs que respon diferent a l’ICMP, no una prova que l’RDP estigui bloquejat. La referència del dret d’inici de sessió de Microsoft llista els valors per defecte segons el rol de la màquina i la regla que la denegació supera l’autorització.