Acceso VPN sin derechos de escritorio remoto: cuatro puertas separadas

Un usuario se conecta a la VPN, abre un recurso compartido y una aplicación interna, y luego un intento de RDP devuelve «la cuenta de usuario no está autorizada para el inicio de sesión remoto». En ese mensaje no hay nada malo con el túnel. Cuatro puertas independientes se interponen entre una cuenta de VPN y un escritorio interactivo, y solo la última lo produjo. La gente suele responder añadiendo la cuenta a Administrators, lo que concede mucho más que el escritorio y no arregla la puerta si una directiva de grupo la deniega. Esto es lo que hace realmente cada puerta y cómo cambiar solo la que rechaza.

Cuatro puertas en un orden fijo

La pasarela decide primero si la identidad puede establecer un túnel: una política RADIUS, una condición de grupo, una comprobación de certificado, un permiso de Access Server. Después el enrutamiento y los cortafuegos deciden si el paquete del grupo de túneles llega al receptor TCP 3389 del destino. Después el apretón de manos NLA del cliente autentica la cuenta contra el destino. Solo después de esas tres, la autoridad de seguridad local comprueba si la cuenta posee el derecho de inicio de sesión que exige una sesión remota interactiva.

Como el orden es fijo, cada puerta oculta las que tiene detrás. Un túnel fallido no dice nada sobre el enrutamiento; un puerto bloqueado no dice nada sobre el derecho de inicio de sesión; una prueba de puerto correcta no dice nada sobre la admisión. Por eso «la VPN funciona pero RDP no» no es un solo problema sino una frontera entre dos de estas puertas, y por eso el texto del error es la forma más rápida de saber a cuál se enfrentó.

El derecho que realmente rechaza la sesión

El inicio de sesión en el escritorio remoto requiere el derecho de usuario Permitir inicio de sesión a través de Servicios de Escritorio remoto, SeRemoteInteractiveLogonRight. Se comprueba al iniciar sesión, no al configurar el túnel, por lo que una cuenta puede navegar por la red durante horas y aun así se le deniega un escritorio. El diálogo que lo muestra está en Directivas locales, Asignación de derechos de usuario, y el equivalente de dominio está en una GPO.

La pertenencia predeterminada depende del rol de la máquina: las estaciones de trabajo y los servidores miembros lo conceden a Administrators y Remote Desktop Users, mientras que un controlador de dominio lo concede solo a Administrators. Ese único hecho explica la mayor parte de la confusión, porque la misma cuenta triunfa en un servidor de archivos y falla en un DC. Un derecho de denegación vence al derecho de permiso correspondiente con independencia de la pertenencia a grupos, así que una cuenta a la que se permite y se deniega a la vez queda denegada. Un grupo de denegación amplio puede atrapar a un administrador añadido como favor.

Lea la política efectiva, no el diálogo local

Cualquier GPO de dominio que defina el mismo derecho sobrescribe la política local, así que el complemento local puede mostrar una lista que parece correcta mientras el estado efectivo es distinto. Exporte lo que la máquina aplica realmente, luego busque el derecho y lea los SID en lugar de los nombres para mostrar:

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

En esa salida, *S-1-5-32-544 es Administrators y *S-1-5-32-555 es Remote Desktop Users.

Si no aparece ninguno, nadie excepto un titular de política puede abrir un escritorio, diga lo que diga el diálogo local de Usuarios y grupos. Entonces gpresult nombra la GPO que ganó, y ese es el objeto que debe editar; cambiar la política local en una máquina unida al dominio es una prueba, no una solución.

Conceda el derecho más estrecho que encaje

La respuesta habitual es el grupo Remote Desktop Users en el destino. Lleva el derecho de forma predeterminada, es mucho más pequeño que Administrators y separa «puede abrir un escritorio» de «puede administrar el servidor». Donde la política ha reasignado el derecho explícitamente, añada el grupo o la cuenta a esa política en lugar de añadir un grupo que nadie concibió como control de acceso.

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

Compruebe la lista de denegaciones antes de añadir nada. Si un derecho de denegación nombra un grupo que contiene al usuario, el cambio correcto es quitar la cuenta de ese grupo o estrechar la denegación, no añadir un segundo permiso en otro sitio. Anote qué derecho cambió y dónde, porque una actualización posterior de la GPO restaurará silenciosamente el estado anterior y el ticket se reabrirá con el mismo mensaje.

Mantenga la ruta de red como una decisión aparte

El grupo de VPN no tiene que llegar a todos los puertos. Cuando un grupo necesita una aplicación y no un escritorio, una regla de cortafuegos limitada al grupo de túneles y al puerto de la aplicación da efecto a esa política, mientras el derecho de inicio de sesión queda intacto.

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

La configuración por cliente de OpenVPN y los permisos de grupo de Access Server pueden restringir los prefijos de destino con el mismo espíritu; ninguno de los dos concede un derecho de inicio de sesión de Windows, y un derecho de inicio de sesión no puede abrir un puerto. Manténgalos en ventanas de cambio separadas, porque una regla de puerto y un derecho los aprueban personas distintas.

Verifique en el mismo orden en que se aplican las puertas: ¿puede la cuenta establecer el túnel, llega la sesión al receptor, se autentica el cliente y tiene la cuenta el derecho? Un ping que falla mientras la prueba de puerto tiene éxito es un cortafuegos que responde de forma distinta a ICMP, no una prueba de que RDP esté bloqueado. La referencia de Microsoft sobre el derecho de inicio de sesión enumera los valores predeterminados por rol de máquina y la regla de que la denegación prevalece sobre el permiso.