Gestionar correctamente los grupos de usuarios y el grupo principal en Sophos Firewall

Los grupos de usuarios de Sophos Firewall agrupan políticas comunes para usuarios autenticados. Permiten unificar Access Time, cuotas, Traffic Shaping, Remote Access y Sign-in Restrictions. Sin embargo, un grupo no concede acceso automáticamente: también intervienen la identidad detectada, el grupo principal efectivo, la política concreta de firewall o VPN y su orden.

El procedimiento rápido y seguro es el siguiente:

1. Determinar de qué origen proceden los usuarios y qué tarea debe resolver el grupo.
2. Utilizar un grupo de tipo Normal para usuarios normales y planificar por separado las identidades de dispositivos basadas en IP como Clientless.
3. Crear o importar un grupo piloto pequeño, con una función clara y el menor número posible de políticas comunes.
4. En Authentication > Services, comprobar el Default Group previsto o, en el servidor Entra, el grupo de reserva.
5. Para Active Directory, documentar el orden en Authentication > Groups > Reorder y definir el grupo principal esperado.
6. Evitar las excepciones por usuario o documentarlas expresamente, porque prevalecen sobre las políticas de grupo.
7. Generar un nuevo inicio de sesión y comprobar Group y Other group memberships en Authentication > Users.
8. Probar la función afectada con un usuario positivo y otro negativo; para el tráfico, comprobar también la Firewall Rule ID esperada.
9. Incorporar más usuarios solo tras completar correctamente el piloto y revisar periódicamente el orden de los grupos, el Default Group y las excepciones.

⚠️ Reorder no es una función de ordenación inofensiva. En usuarios de AD, mover un grupo puede cambiar el grupo principal y, con ello, MFA, cuotas, Access Time, Remote Access y otras políticas para muchos usuarios. Antes se documentan el orden existente, las políticas de grupo, los usuarios piloto y la vía de recuperación.

Entender el modelo de grupos en pocos minutos

En el firewall, un grupo es un portador común de políticas. Puede asignar la misma configuración a varios usuarios para no tener que mantener cada cuenta por separado. No sustituye ni la autenticación ni una regla de firewall. Un usuario puede aparecer en el grupo correcto y seguir sin acceso si falta la regla, la política VPN, la zona, la ruta o la ruta de retorno esperadas.

Para la operación conviene separar cuatro preguntas:

1. ¿De dónde procede la identidad? De forma local, de Active Directory, LDAP, RADIUS, Microsoft Entra ID o de una asignación Clientless basada en IP.
2. ¿Qué grupo es efectivo? En AD puede ser el grupo principal o, para funciones compatibles, otra pertenencia a grupo.
3. ¿Qué política de grupo se aplica? Access Time, Quota, Remote Access y otros campos siguen reglas de evaluación distintas.
4. ¿Qué regla permite el tráfico? Las políticas de grupo por sí solas no abren una ruta de red.

No mezclar grupos Normal, importados y Clientless

Un grupo local de tipo Normal es adecuado para usuarios que se autentican mediante un servicio compatible. Un usuario local recibe el grupo en su objeto de usuario. Con un origen de usuarios externo, los registros locales suelen crearse únicamente después del primer inicio de sesión correcto.

Las cuentas temporales para invitados se generan mediante Guest user settings y heredan un grupo restrictivo seleccionado de forma consciente. Crear y operar de forma segura usuarios invitados en Sophos Firewall describe la creación, la validez, la validación en Captive Portal y la retirada de las cuentas.

Los grupos de AD se incorporan mediante el asistente de importación. La pertenencia se mantiene en el directorio y se evalúa durante el inicio de sesión. El proceso completo de servidor, LDAPS e importación se describe en Conectar Active Directory con Sophos Firewall. Para LDAP genérico se deben planificar por separado la base de búsqueda, memberOf u otro atributo de grupo y el Default Group local; Conectar un servidor LDAP con Sophos Firewall explica estos campos.

Un grupo de tipo Clientless resuelve otra tarea. Asigna una identidad a una dirección IP fija sin que una persona inicie sesión. Está pensado para impresoras u otros sistemas claramente atribuibles y no sustituye la autenticación de usuarios. Configurar Clientless Users en Sophos Firewall describe la comprobación segura de IP, regla y resultado negativo.

Elegir conscientemente el Default Group y el grupo de reserva

En Authentication > Services > Firewall authentication methods, Default group determina qué grupo recibe un usuario externo cuando no existe un grupo local coincidente. Por tanto, un Default Group amplio o heredado históricamente puede asignar políticas inesperadas. Es más seguro utilizar un grupo de reserva deliberadamente restrictivo cuyo comportamiento se haya probado tanto de forma positiva como negativa.

Microsoft Entra ID SSO utiliza su propio Fallback user group en la configuración del servidor Entra. Este ajuste también se aplica cuando el servidor se utiliza en Firewall authentication methods. Por ello, el Default Group general y el grupo de reserva de Entra no deben tratarse como si fueran el mismo ajuste.

Planificar el ejemplo y los requisitos

El siguiente ejemplo separa tres finalidades:

• Local_Contractors: grupo piloto local para unas pocas personas externas;
• SFOS_Internet_Standard: grupo de AD importado para el acceso normal a Internet;
• SFOS_SSLVPN: grupo de AD importado para una política SSL VPN;
• auth-pilot@example.com: cuenta de prueba creada expresamente;
• LAN-Users-to-WAN: regla de firewall con registro para la prueba de Internet.

example.com es un dominio reservado para documentación. Los nombres de grupos, el usuario y el nombre de la regla se sustituyen por la convención de nombres propia. Un buen nombre de grupo describe la función y no solo un departamento. Por ejemplo, SFOS_SSLVPN sigue siendo comprensible aunque la estructura de la organización cambie más adelante.

Antes del primer cambio se documentan:

• el orden actual en Authentication > Groups;
• el Default Group y, para Entra ID, el grupo de reserva;
• las políticas de grupo y las excepciones específicas de usuario;
• los servicios de autenticación y las políticas de Remote Access afectados;
• un acceso de administrador probado y una ruta de gestión independiente;
• un usuario piloto con el comportamiento positivo y negativo esperado.

Crear un grupo de usuarios local

En Authentication > Groups > Add se crea la base común:

1. En Name, introducir Local_Contractors.
2. En Group type, seleccionar Normal.
3. Configurar Surfing quota, Access time, Network traffic y Traffic shaping solo si el grupo necesita realmente estas funciones de forma común.
4. Activar campos de Remote Access como SSL VPN policy o IPsec remote access únicamente para el acceso planificado.
5. Limitar Sign-in restriction a las direcciones de origen o al rango previsto que sean realmente necesarios, si el modelo de autenticación lo permite.
6. Activar Quarantine digest y MAC binding solo de forma consciente.
7. Guardar con Save.

Los nombres de los campos son especificaciones del producto. Las políticas seleccionadas dependen del entorno. Un grupo normal de Internet no necesita automáticamente VPN, Quota o MAC Binding. Cuantas menos tareas combine un grupo, más fácil será comprender su efecto y deshacerlo.

Asignar usuarios sin crear excepciones ocultas

Crear y gestionar usuarios locales normales explica por completo el nombre de usuario, la contraseña, la herencia del grupo, el método de autenticación y la validación. Se pueden asignar a un grupo en Authentication > Users. En la edición del grupo, Show group members muestra los miembros y Add member(s) permite incorporar usuarios locales adecuados. Para identidades gestionadas externamente, el directorio sigue siendo el origen de la pertenencia. Una asignación local manual no sustituye una configuración correcta de AD, LDAP o Entra.

Las políticas específicas de usuario tienen prioridad sobre las políticas de grupo. Una excepción puede resultar útil para un caso documentado o un piloto, pero puede hacer que un cambio posterior del grupo parezca ineficaz. Por ello, para cada usuario diferente se documenta qué campo se ha sobrescrito, por qué existe la excepción y cómo volver al valor del grupo.

La creación y validación completas de políticas de Access Time, cuotas de Surfing y Network Traffic y MFA para Sophos Firewall se mantienen en los respectivos artículos especializados. En el objeto de grupo solo se asigna la política ya planificada.

Operar grupos de AD importados de forma controlada

Los grupos de AD se importan al firewall en Authentication > Servers > Import. En un clúster HA, la importación se realiza en el dispositivo Primary. El asistente importa únicamente los grupos seleccionados. Por ello, un grupo creado posteriormente en AD no aparece automáticamente en el firewall y debe volver a importarse o crearse de forma deliberadamente coincidente.

Los grupos de AD anidados no se evalúan. Si se va a utilizar un subgrupo para una regla de firewall, una política VPN u otra función, debe importarse exactamente ese subgrupo. El grupo principal de AD de un usuario tampoco se importa como pertenencia normal. Por tanto, para las políticas son más adecuadas las agrupaciones de seguridad explícitas que el grupo predeterminado de AD Domain Users.

Después de modificar pertenencias de AD, grupos importados o el orden de los grupos, se genera un nuevo inicio de sesión. Solo entonces el firewall vuelve a evaluar los grupos y actualiza el objeto de usuario.

Entender el grupo principal y el orden de los grupos

Para un usuario de AD, Authentication > Users muestra dos niveles distintos:

• Group: el primer grupo coincidente de la lista del firewall y, por tanto, el grupo principal;
• Other group memberships: los demás grupos importados del usuario.

El orden se cambia en Authentication > Groups > Reorder. Si auth-pilot@example.com pertenece a SFOS_Internet_Standard y SFOS_SSLVPN, el grupo coincidente situado más arriba en la lista se convierte en el grupo principal en el siguiente inicio de sesión.

Este orden no se modifica espontáneamente para resolver una incidencia aislada. Primero se comprueba qué función concreta está afectada y si admite otros grupos. De lo contrario, un cambio puede reparar un caso de VPN y modificar al mismo tiempo MFA, Quota o Access Time para otros usuarios.

Los grupos múltiples se evalúan de forma distinta según la función

El siguiente límite se aplica expresamente a pertenencias a grupos de Active Directory. No se transfiere sin comprobar a LDAP, RADIUS o Microsoft Entra ID.

Se pueden tener en cuenta varios grupos de AD para:

• Firewall rules y SSL/TLS inspection rules;
• SD-WAN routes;
• Web policies;
• IPS y Application control policies;
• Policy test;
• Remote access SSL VPN;
• Clientless SSL VPN.

En Remote access SSL VPN se combinan los permisos de las políticas de usuario y grupo coincidentes. En cuanto interviene una política Full Tunnel coincidente, el resultado es un Full Tunnel. Por ello, esta combinación debe comprobarse con un cliente real y no solo comparando los nombres de los grupos.

Solo se tiene en cuenta el grupo principal o una asignación explícita de usuario para:

• WAF rules, My policy overrides y Hotspots;
• Remote access IPsec VPN, L2TP y PPTP;
• Surfing quota, Access time, Network traffic y Traffic shaping;
• Quarantine digest, MAC binding y Sign-in restriction;
• MFA.

En las funciones compatibles con grupos múltiples sigue siendo relevante el orden de la regla o política correspondiente. Por ejemplo, una regla de firewall puede coincidir mediante SFOS_SSLVPN aunque SFOS_Internet_Standard sea el grupo principal. Esto no significa que MFA o Quota también utilicen SFOS_SSLVPN.

Probar el efecto del grupo con un usuario real

Un grupo guardado y un usuario visible todavía no demuestran el éxito. Para el piloto se utiliza el mismo procedimiento que se aplicará después en producción:

1. Finalizar la sesión existente del usuario piloto y generar un nuevo inicio de sesión.
2. En Authentication > Users, documentar el estado, Group, Other group memberships y las posibles excepciones de usuario.
3. En Current activities > Live users, comprobar el nombre de usuario, la IP de origen y Client Type.
4. Para una regla de firewall basada en usuarios, generar el flujo previsto y comprobar la Firewall Rule ID en Log Viewer.
5. Para Access Time, Quota, MFA o Remote Access, probar por separado el servicio afectado.
6. Ejecutar el mismo flujo como prueba negativa con un usuario que no pertenezca al grupo piloto.
7. Registrar el resultado, la hora, el orden de los grupos y la política efectiva.

Comprobar reglas de firewall con Log Viewer, Policy Test y Packet Capture muestra la prueba completa de tráfico. Si ya no está claro si falla la selección del servicio, la identidad, el grupo principal o la regla posterior, Resolver sistemáticamente errores de autenticación de Sophos Firewall guía por toda la cadena de comprobación.

Cambios, reversión y operación

Los cambios de grupos se tratan como cambios de políticas:

1. Documentar el estado inicial y los usuarios afectados.
2. Cambiar solo un grupo, una política o una posición cada vez.
3. Volver a autenticar al usuario piloto.
4. Comprobar de nuevo el grupo principal, las demás pertenencias y la función concreta.
5. Si el efecto es inesperado, restaurar el orden de grupos y la asignación de políticas anteriores.
6. Generar otro inicio de sesión nuevo y repetir las pruebas positiva y negativa.

Un grupo de AD se depura primero en el directorio y después en el firewall. Un usuario que siga existiendo en AD puede volver a crearse localmente durante un inicio de sesión posterior. Por tanto, Purge AD users no es un botón de sincronización ni un paso habitual después de cambiar un grupo.

Los usuarios y los grupos comparten el rango interno de ID hasta 65535. Una cantidad visible elevada de objetos no demuestra por sí sola un problema de límite. Si un usuario muestra una User ID superior a 65535 y no se convierte en Live User, corresponde seguir el procedimiento independiente sobre el límite de ID de usuario de Sophos Firewall.

Acotar errores por síntoma

El nuevo grupo de AD no aparece en el firewall

Los grupos nuevos no se sincronizan automáticamente. Volver a ejecutar el asistente de importación y, en HA, hacerlo en el Primary. Después, comprobar en Authentication > Groups que existe exactamente el grupo necesario. No crear un grupo sustituto amplio solo para que funcione un inicio de sesión.

El usuario tiene el grupo principal incorrecto

Primero se documentan las pertenencias de AD, los grupos importados y el orden actual. Después se comprueba si el grupo esperado existe realmente en el firewall. Un cambio planificado en Reorder solo se evalúa después de un nuevo inicio de sesión y debe probarse con varios usuarios representativos.

La regla de firewall coincide, pero no se aplica MFA o Quota

Las reglas de firewall admiten otros grupos de AD, mientras que MFA y las cuotas no. En el objeto de usuario se comprueba qué grupo aparece en Group como grupo principal. Después se revisan las excepciones específicas de usuario y la asignación real de la política. Que una regla coincida no demuestra que MFA o Quota evalúen los grupos de la misma forma.

El cambio de grupo solo afecta incorrectamente a un usuario

Comparar los campos de políticas específicos del usuario en Authentication > Users. Una excepción individual tiene prioridad sobre la política de grupo. El valor no se cambia a ciegas, sino que primero se compara con la excepción documentada y el estado de herencia deseado.

El usuario termina en el Default Group

En AD u otro servidor de autenticación clásico, probablemente falta un grupo local coincidente o una asignación de grupo. Comprobar la importación, el nombre del grupo, la base de búsqueda y los atributos devueltos. Para Microsoft Entra ID SSO, comprobar en su lugar el Fallback user group del servidor Entra. El Default Group no se amplía de forma general para ocultar el verdadero error de asignación.

El grupo de AD anidado no se aplica

Importar el subgrupo necesario y añadir directamente al usuario. Después, generar un nuevo inicio de sesión y comprobar Group y Other group memberships. Importar solo el grupo superior no es suficiente.

Lista de comprobación operativa

• La finalidad del grupo y el origen de usuarios responsable están documentados.
• Los grupos locales, importados y Clientless no se mezclan.
• El Default Group o grupo de reserva de Entra se ha elegido de forma deliberada y restrictiva.
• El orden de los grupos y los grupos principales esperados están documentados.
• Las excepciones de usuario están justificadas o eliminadas.
• La función concreta admite la pertenencia a grupo utilizada.
• El usuario piloto se ha vuelto a autenticar y se ha comprobado en Authentication > Users.
• Las pruebas positiva y negativa confirman la política o Firewall Rule ID esperada.
• Remote Access, MFA, Access Time y las cuotas se han validado por separado cuando se utilizan.
• Se ha documentado la vía de reversión para el orden de grupos y la asignación de políticas.

Preguntas frecuentes