Acceso VPN sen dereitos de escritorio remoto: catro portas separadas

Un usuario conéctase á VPN, abre un recurso compartido e unha aplicación interna, e despois un intento de RDP devolve «a conta de usuario non está autorizada para o inicio de sesión remoto». Nesa mensaxe non hai nada mal co túnel. Catro portas independentes están entre unha conta de VPN e un escritorio interactivo, e só a última o produciu. A xente adoita responder engadindo a conta a Administrators, o que concede moito máis ca o escritorio e non arranxa a porta se unha directiva de grupo a denega. Velaquí que fai realmente cada porta e como cambiar só a que rexeita.

Catro portas nunha orde fixa

A pasarela decide primeiro se a identidade pode establecer un túnel: unha política RADIUS, unha condición de grupo, unha comprobación de certificado, un permiso de Access Server. Despois o encamiñamento e as devasas deciden se o paquete do pool do túnel chega ao oínte TCP 3389 do destino. Despois o apretón de mans NLA do cliente autentica a conta contra o destino. Só despois desas tres, a autoridade de seguridade local comproba se a conta ten o dereito de inicio de sesión que esixe unha sesión remota interactiva.

Como a orde é fixa, cada porta agocha as que están detrás. Un túnel fallido non di nada do encamiñamento; unha porta bloqueada non di nada do dereito de inicio de sesión; unha proba de porta correcta non di nada da admisión. Por iso «a VPN funciona pero RDP non» non é un só problema senón unha fronteira entre dúas destas portas, e por iso o texto do erro é a forma máis rápida de saber a cal se enfrontou.

O dereito que realmente rexeita a sesión

O inicio de sesión no escritorio remoto require o dereito de usuario Permitir o inicio de sesión a través dos servizos de Escritorio remoto, SeRemoteInteractiveLogonRight. Compróbase ao iniciar sesión, non ao configurar o túnel, polo que unha conta pode navegar pola rede durante horas e aínda así denegarlle un escritorio. O diálogo que o mostra está en Directivas locais, Asignación de dereitos de usuario, e o equivalente de dominio está nunha GPO.

A pertenza predeterminada depende do rol da máquina: as estacións de traballo e os servidores membros concédeno a Administrators e Remote Desktop Users, mentres que un controlador de dominio só o concede a Administrators. Ese único feito explica a maior parte da confusión, porque a mesma conta ten éxito nun servidor de ficheiros e falla nun DC. Un dereito de denegación vence o dereito de permiso correspondente independentemente da pertenza ao grupo, así que unha conta á que se permite e se denega á vez queda denegada. Un grupo de denegación amplo pode atrapar un administrador engadido como favor.

Lea a política efectiva, non o diálogo local

Calquera GPO de dominio que defina o mesmo dereito sobrescribe a política local, así que o complemento local pode mostrar unha lista que parece correcta mentres o estado efectivo é distinto. Exporte o que a máquina aplica realmente, despois busque o dereito e lea os SID en lugar dos nomes para mostrar:

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

Nesa saída, *S-1-5-32-544 é Administrators e *S-1-5-32-555 é Remote Desktop Users.

Se non aparece ningún, ninguén excepto un titular de política pode abrir un escritorio, diga o que diga o diálogo local de Usuarios e grupos. Entón gpresult nomea a GPO que gañou, e ese é o obxecto que debe editar; cambiar a política local nunha máquina unida ao dominio é unha proba, non unha solución.

Conceda o dereito máis estreito que encaixe

A resposta habitual é o grupo Remote Desktop Users no destino. Leva o dereito por defecto, é moito máis pequeno ca Administrators e separa «pode abrir un escritorio» de «pode administrar o servidor». Onde a política reasignou o dereito explicitamente, engada o grupo ou a conta a esa política en lugar de engadir un grupo que ninguén concibiu como control de acceso.

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

Comprobe a lista de denegacións antes de engadir nada. Se un dereito de denegación nomea un grupo que contén o usuario, o cambio correcto é quitar a conta dese grupo ou estreitar a denegación, non engadir un segundo permiso noutro sitio. Anote que dereito cambiou e onde, porque unha actualización posterior da GPO restaurará silenciosamente o estado anterior e o ticket reabrirase coa mesma mensaxe.

Manteña a ruta de rede como unha decisión á parte

O grupo da VPN non ten que chegar a todas as portas. Cando un grupo precisa unha aplicación e non un escritorio, unha regra de devasa limitada ao pool do túnel e á porta da aplicación dá efecto a esa política, mentres o dereito de inicio de sesión queda intacto.

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

A configuración por cliente de OpenVPN e os permisos de grupo de Access Server poden restrinxir os prefixos de destino co mesmo espírito; ningún dos dous concede un dereito de inicio de sesión de Windows, e un dereito de inicio de sesión non pode abrir unha porta. Manteñaos en xanelas de cambio separadas, porque unha regra de porta e un dereito son aprobados por persoas distintas.

Verifique na mesma orde en que se aplican as portas: pode a conta establecer o túnel, chega a sesión ao oínte, autentícase o cliente e ten a conta o dereito. Un ping que falla mentres a proba de porta ten éxito é unha devasa que responde distinto a ICMP, non unha proba de que RDP estea bloqueado. A referencia de Microsoft sobre o dereito de inicio de sesión enumera os valores por defecto segundo o rol da máquina e a regra de que a denegación prevalece sobre o permiso.