Añadir un usuario a un grupo VPN no concede acceso por sí solo

Ha puesto la cuenta en el grupo correcto, el inicio de sesión ha funcionado y la conexión sigue rechazándose, o se conecta y no llega a nada útil. El reflejo habitual es añadir al usuario a más grupos hasta que algo ceda, y así las organizaciones conceden mucho más de lo que pedía el ticket. La pertenencia a un grupo es una entrada en la decisión de autorización, nunca la decisión misma: la puerta de enlace reúne unos cuantos hechos sobre la sesión, los empareja con una política ordenada y solo entonces decide a qué puede tocar la sesión. Si ha fallado otra condición, cambiar el grupo no cambia nada salvo su exposición.

La pertenencia a un grupo es una condición, no un permiso

En RADIUS el grupo llega como atributo de autorización, y los atributos describen la sesión en lugar de concederla. El servidor responde con Access-Accept o Access-Reject; al aceptar puede adjuntar Filter-Id, Class o los atributos de túnel de RFC 2868, y el equipo de red del otro extremo los interpreta como decida el fabricante. Nada en el protocolo asigna un grupo al acceso completo; esa asignación la escribe quien configuró la política en la puerta de enlace o en el servidor de acceso a la red, y puede ser tan estrecha como un solo host.

Por eso un mismo nombre de grupo se comporta distinto en dos sistemas. Microsoft NPS compone políticas de red a partir de condiciones, restricciones y ajustes y las evalúa en un orden configurado. OpenVPN Access Server tiene su propio modelo de grupos y reglas de acceso, mientras que un servidor OpenVPN comunitario suele delegar toda la cuestión en un script client-connect o en un archivo de client-config-dir. Cada uno consume un grupo; ninguno comparte la lógica de precedencia del otro.

Decide la regla que coincidió, no el grupo que esperaba

La mayoría de los motores se detienen en la primera política que coincide o en la más específica. Si la política 3 deniega y la política 7 permite, la sesión puede fallar sin llegar nunca a la regla que la habría dejado pasar. El orden es un ajuste real en NPS y en la mayoría de los productos de control de acceso a la red, y se desplaza con los años.

Las condiciones que viajan con el grupo son la otra mitad. La postura del dispositivo, el método de autenticación, el MFA completado, la red de origen, el sujeto del certificado o una ventana horaria pueden estar en la misma política. Cuando una no se cumple, la política no coincide, el motor cae y se aplica la denegación por defecto. Desde el asiento del usuario parece que se ignora el grupo; desde el asiento del motor nunca se consultó el grupo.

Los detalles del directorio producen la misma ilusión. Una política que empareja por pertenencia a grupos de Windows lee los SID del token del usuario, y allí solo se enumeran grupos de seguridad, un grupo de distribución nunca aparece. El grupo primario se lleva en su propio campo y no en la lista enumerada, así que una política anclada a ese grupo puede fallar en silencio.

Lea el registro de aceptación o denegación antes de tocar un grupo

Pregunte primero una cosa: ¿llegó la petición a la fase de autorización? En NPS la respuesta está en el registro de eventos, donde 6272 registra acceso concedido, 6273 una denegación y 6274 una petición que el servidor descartó antes de evaluar la política. Esos tres números dividen el problema en tres investigaciones distintas, y solo una trata de grupos.

Cuando el registro no está al alcance, pregunte al servidor directamente y lea lo que devuelve. Una respuesta sin Filter-Id y sin atributos de túnel dice que el servidor considera la sesión corriente y que la puerta de enlace aplica reglas propias. Una respuesta con atributos que el punto de aplicación no implementa es otro fallo: la autorización pasó y el dispositivo ignoró el resultado.

radtest alice 'password' 10.0.0.5 0 testing123

Compare los atributos devueltos con los que documenta la puerta de enlace, no con lo que sugiere el nombre del grupo. Esa comparación suele separar un problema de política de un problema de aplicación.

Un cambio de grupo no es retroactivo

Los atributos de autorización se devuelven una vez, cuando se autentica la sesión. La puerta de enlace los guarda en la sesión y no relee el directorio para cada paquete, por eso una sesión establecida sigue funcionando después de sacar a alguien de un grupo, y una nueva puede fallar mientras la vieja sigue viva.

Para que el cambio surta efecto hace falta una nueva decisión de autorización, no solo claves nuevas. Donde el servidor admite autorización dinámica RFC 5176, una Disconnect-Request o CoA-Request a UDP 3799 fuerza la reevaluación de la sesión; si no, desconecte al cliente y deje que se reconecte. La renegociación refresca las claves del túnel y normalmente deja intacto el resultado de autorización.

Arregle la condición, no el grupo

Cuando sabe qué política saltó, la reparación suele ser pequeña: reordene una denegación que eclipsa el permiso buscado, añada la condición de dispositivo o MFA que falta a la política que quería emparejar, o escriba una regla estrecha para ese recurso en lugar de promover al usuario a un grupo que lleva otros diez.

Un bucle corto mantiene el cambio honesto:

• Reproduzca la denegación con la cuenta original y anote el ID de evento antes de cambiar nada.
• Cambie un solo objeto, el orden de políticas, una condición o un grupo, y registre cuál.
• Abra una sesión nueva, confirme que la concesión aparece en el registro y que el recurso se abre de verdad.
• Pruebe un usuario que aún debe ser rechazado, para que el arreglo no haya ampliado la política por accidente.

Si la concesión es correcta y el recurso no se abre, el problema se ha mudado a enrutamiento o resolución de nombres en el momento en que la autorización pasó. Mantenga las dos fallas separadas y el próximo ticket costará minutos, no una tarde.