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

Los grupos de usuarios agrupan políticas comunes para los usuarios autenticados. Antes de cambiar un grupo, hay que aclarar dos aspectos: de dónde proviene la identidad y si la función afectada evalúa solo el Main Group o también otros grupos de AD. Solo entonces se puede determinar si es necesario cambiar el orden de los grupos, la asignación de una política o la propia regla de firewall o VPN.

Procedimiento rápido:

Establecer la fuente de usuarios y el propósito del grupo.
Crear un grupo local o importar específicamente el grupo de directorio necesario.
En Authentication > Services, comprobar el Default group efectivo o, en el servidor Entra, el Fallback user group.
En AD, documentar el orden en Authentication > Groups > Reorder y el grupo principal esperado.
Cerrar sesión con el usuario piloto y volver a iniciar sesión. Después, comprobar los campos Group y Other group memberships en Authentication > Users > usuario > Policies.
Probar la función afectada con un usuario autorizado y uno no autorizado. En caso de tráfico de red, comprobar además el Firewall Rule ID esperado.

⚠️ Reorder no es una simple función de ordenación inofensiva. En los usuarios de AD, un cambio de posición puede modificar el grupo principal y, por tanto, MFA, las cuotas, los horarios de acceso, el acceso remoto y otras políticas para muchos usuarios. Anota previamente el orden, las políticas de grupo y el procedimiento de reversión.

Entender el modelo de grupos

Un grupo define políticas y ajustes comunes. No sustituye la autenticación ni una regla de firewall. Por tanto, un usuario puede estar en el grupo correcto y aun así no obtener acceso si falta la regla esperada, la política de VPN, la zona, la ruta o el camino de retorno.

Para diagnosticar un error, plantea cuatro preguntas por separado:

¿Proviene la identidad de la base de datos local, Active Directory, LDAP, RADIUS, Microsoft Entra ID o de una asignación sin cliente?
¿Qué grupo es el grupo principal?
¿La función afectada admite otras pertenencias a grupos de AD?
¿Qué regla o política procesa el tráfico real?

Diferenciar entre grupos locales, importados y sin cliente

Normal y Clientless son tipos de grupo. Importado, en cambio, describe el origen de un grupo y no es un Group type propio.

Un grupo local del tipo Normal es adecuado para usuarios que inician sesión. Los usuarios locales obtienen su grupo en el objeto de usuario. Con una fuente de usuarios externa, los registros de usuarios locales normalmente solo se crean en el primer inicio de sesión correcto.

Los usuarios invitados siguen un ciclo propio y de duración limitada. Crear y gestionar de forma segura usuarios invitados en Sophos Firewall explica el grupo predeterminado, la validez, el portal cautivo y la limpieza.

Los grupos AD y Entra se importan a través del asistente del servidor correspondiente. El directorio sigue siendo la fuente de las pertenencias. Para AD, Sophos también documenta como alternativa la creación manual del grupo tanto en AD como en el firewall. También en este caso deben comprobarse la asignación de grupo y los permisos después de un nuevo inicio de sesión. El procedimiento completo de AD, LDAPS e importación está disponible en Conectar Active Directory con Sophos Firewall.

Con LDAP genérico, Base DN, Authentication attribute, Group name attribute, el orden de los servidores y Default group deben ser coherentes entre sí. Sophos recomienda memberOf como atributo de grupo. Conectar servidores LDAP con Sophos Firewall explica esta configuración paso a paso.

Un grupo del tipo Clientless agrupa a usuarios sin cliente y sus ajustes comunes. Estos usuarios no inician sesión a través de un cliente; el firewall controla su acceso en función de la dirección IP. La dirección IP fija se almacena en cada usuario sin cliente, no en el objeto del grupo. Configurar usuarios sin cliente en Sophos Firewall describe la asignación de IP, la regla y la prueba negativa.

No confundir el grupo predeterminado con el grupo de reserva de Entra

En Authentication > Services > Firewall authentication methods, Default group define qué grupo recibe un usuario de un servidor de autenticación externo cuando ninguno de sus grupos de directorio está presente como grupo local. El valor de fábrica es Open group. Comprueba el valor actual en lugar de dar por sentado el predeterminado. Para entornos de producción, Avanet recomienda un grupo de reserva específico y restrictivo, sin permisos de VPN, cuotas o inicio de sesión no deseados.

Descripciones contradictorias de AD sobre el primer inicio de sesión: La guía de configuración de AD describe la incorporación automática a Default group en el primer inicio de sesión; en cambio, las preguntas frecuentes de AD mencionan Default group únicamente cuando ninguno de los grupos de AD del usuario está presente en el firewall. La descripción general de los servidores de AD indica expresamente Open group para los usuarios que pertenecen solo a una OU y a ningún grupo de directorio, mientras que la descripción general de los grupos y las preguntas frecuentes remiten a Default group, según su configuración actual. Estas descripciones son contradictorias y no demuestran que exista un grupo especial de aplicación universal para el primer inicio de sesión ni que dicho grupo tenga prioridad. Debe distinguirse entre Default group, según su configuración actual, y el valor de fábrica Open group.

Antes del despliegue, comprueba el valor real de Default group y sus permisos heredados. Comprueba el primer inicio de sesión por separado con dos cuentas piloto nuevas destinadas a este fin: una con un grupo de AD ya importado en el firewall y otra cuyos grupos de AD no estén importados en él. Para ambas, comprueba en Policies los campos Group y Other group memberships, así como los accesos permitidos y los que se hayan denegado deliberadamente. Si la asignación es inesperada, detén el despliegue y aclara la causa. No elimines grupos de producción ni amplíes los permisos de reserva para realizar estas comprobaciones.

Microsoft Entra ID SSO utiliza el Fallback user group separado en la configuración del servidor Entra. También se aplica si el servidor Entra está seleccionado en Firewall authentication methods. El grupo predeterminado general no se aplica en este caso.

El orden de los servidores de autenticación también es relevante. Sophos Firewall permite como máximo 20 servidores por método de autenticación y reenvía las solicitudes en el orden mostrado. No cambies este orden para sortear un problema de grupos sin haber verificado antes el servidor correspondiente y su asignación.

Planificar el ejemplo y documentar el estado inicial

El ejemplo utiliza tres grupos con funciones distintas:

Local_Contractors: grupo piloto local para unos pocos colaboradores externos;
SFOS_Internet_Standard: grupo AD importado para acceso normal a Internet;
SFOS_SSLVPN: grupo AD importado para una política SSL-VPN.

auth-pilot@example.com sirve como cuenta de prueba y la regla con registro activado LAN-Users-to-WAN como prueba de tráfico. example.com es un dominio reservado para documentación. Sustituye los nombres y usuarios por los de tu propia convención de nombres. Un nombre relacionado con la función como SFOS_SSLVPN sigue siendo comprensible incluso después de una reorganización.

Anota antes del cambio:

el orden actual de los grupos;
Default group y, si corresponde, Fallback user group;
las políticas de grupo y las anulaciones específicas de usuario;
los servicios de autenticación afectados y las políticas de VPN;
un acceso de administrador verificado y una segunda vía de gestión, en caso de que se vean afectados el grupo principal, MFA o las restricciones de inicio de sesión;
los usuarios piloto, el grupo principal esperado y las pruebas positivas y negativas.

Crear un grupo de usuarios local

Ve a Authentication > Groups y haz clic en Add:

Introduce Local_Contractors como nombre del grupo.
En Group type, selecciona Normal.
Selecciona únicamente las políticas comunes necesarias:
- Surfing quota limita el tiempo de uso según el período y el ciclo.
- Access time permite o deniega períodos recurrentes.
- Network traffic limita la cantidad de datos transferidos.
- Traffic shaping asigna una política QoS con prioridad y límites de ancho de banda.
Configura SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP y IPsec remote access solo para el acceso realmente planificado. PPTP no es adecuado para nuevos diseños; L2TP sigue siendo una opción de compatibilidad limitada, como se explica en Acceso remoto L2TP en Sophos Firewall.
Limita Sign-in restriction, si es posible, con Selected nodes o Node range a los orígenes necesarios. Selected nodes permite únicamente las direcciones IP especificadas; Node range permite las direcciones dentro del intervalo de IP especificado. Any node permite el inicio de sesión desde cualquier red.
Activa Quarantine digest y MAC binding únicamente si el grupo necesita estas funciones. Quarantine digest envía al buzón del usuario un resumen de los correos electrónicos retenidos en cuarentena. MAC binding restringe el inicio de sesión a los dispositivos previstos.
Haz clic en Save para guardar.

Los nombres de los campos y su efecto los determina el producto; la selección depende del entorno. Un grupo de acceso a Internet no necesita automáticamente VPN, cuotas ni vinculación MAC. Los grupos con funciones bien delimitadas son más fáciles de probar y de revertir.

Asignar usuarios locales y reconocer anulaciones

Crear y administrar usuarios locales normales describe en detalle el nombre de usuario, la contraseña, la herencia de grupos y la validación. Los usuarios locales se pueden asignar a un grupo en Authentication > Users. En la edición de grupos, Show group members muestra los miembros; a través de Add member(s) se agregan los usuarios locales adecuados. En el caso de identidades administradas externamente, en cambio, el directorio sigue siendo la fuente de la pertenencia.

Que una regla o política utilice los ajustes del usuario o del grupo depende de la selección real de usuarios y grupos. Comprueba en el usuario, en Policies, si se ha seleccionado un valor propio en lugar del ajuste del grupo. Si se desea que la política de grupo vuelva a aplicarse, restaura específicamente el estado de herencia previamente documentado y vuelve a probar únicamente la función afectada. Una anulación sigue siendo útil si se documenta explícitamente una excepción justificada.

Sophos distingue dos casos para la selección en la regla o política afectada:

Solo el grupo seleccionado: El firewall utiliza los ajustes del grupo, no automáticamente la anulación del usuario.
El usuario y su grupo seleccionados: El firewall utiliza los ajustes del usuario.

Una prueba piloto limitada permite ver la diferencia: para auth-pilot@example.com en Local_Contractors, documenta un valor de grupo A y un valor de usuario diferente B para el mismo ajuste admitido. A y B son marcadores de posición para dos valores de prueba planificados deliberadamente en tu entorno. En una regla o política de prueba aislada con selección de usuarios y grupos, comprueba primero la selección real: solo Local_Contractors implica A; auth-pilot@example.com junto con Local_Contractors implica B. Prueba el servicio o la ruta de datos afectados con un nuevo inicio de sesión en cada caso; para el tráfico de firewall, comprueba también el Firewall Rule ID. Después, restaura la selección previamente anotada y ambos ajustes y vuelve a probar. No amplíes una regla de producción ni cambies el orden de los grupos para esta prueba.

Esta selección no es el orden del Main Group. Siguen aplicándose las limitaciones de la compatibilidad con varios grupos y la combinación de políticas SSL-VPN coincidentes descritas más abajo; esto no establece una prioridad universal de las políticas de usuario para todos los servicios.

La creación completa de políticas de horarios de acceso, cuotas de navegación y tráfico de red, así como de MFA para Sophos Firewall, se explica en los respectivos artículos especializados. En el objeto de grupo solo se asigna una política ya planificada.

Interpretar los campos de grupo en la API XML

Quien gestione grupos de forma automatizada encontrará en el modelo XML UserGroup como objeto de grupo, GroupDetail como cuerpo de configuración y GroupMembers con GroupName y UserName como datos de pertenencia. Esto no es una importación de pertenencias de AD; para los usuarios de directorio, el directorio sigue siendo la fuente de referencia. Usar la API XML de forma segura explica la autenticación, las envolturas explícitas de las operaciones y la evaluación de la respuesta XML.

El siguiente fragmento muestra únicamente la estructura documentada para los ejemplos piloto existentes. No es una solicitud Add/Edit completa; en particular, faltan la envoltura de la operación y otros campos de configuración necesarios. La omisión de campos no implica que un cambio conserve los valores existentes.

<UserGroup>
  <GroupDetail>
    <Name>Local_Contractors</Name>
    <LoginRestriction>SelectedNodes</LoginRestriction>
    <NodeList>
      <IPAddress>192.0.2.10</IPAddress>
    </NodeList>
  </GroupDetail>
  <GroupMembers>
    <GroupName>Local_Contractors</GroupName>
    <UserName>auth-pilot@example.com</UserName>
  </GroupMembers>
</UserGroup>

El nombre del grupo y el usuario deben sustituirse por los del destino local planificado con precisión. 192.0.2.10 es una dirección IPv4 reservada para documentación y debe sustituirse por un origen de inicio de sesión permitido que sea realmente necesario. Los nombres de los campos XML no se modifican. La correspondencia con los campos de la interfaz es la siguiente:

SurfingQuotaPolicy: Surfing quota; AccessTimePolicy: Access time.
DataTransferPolicy: Network traffic; QoSPolicy: Traffic shaping.
SSLVPNPolicy: SSL VPN policy; ClientlessPolicy: Clientless SSL VPN policy, no el tipo de grupo Clientless.
SophosConnectClient: IPsec remote access a través de Sophos Connect Client.

Para LoginRestriction, el ejemplo de referencia distingue entre AnyNode, SelectedNodes y NodeRange. AnyNode corresponde a Any node y no limita el origen de inicio de sesión; no es un valor predeterminado para resolver problemas. SelectedNodes utiliza NodeList con las entradas individuales de IPAddress. NodeRange utiliza, en cambio, FromIP y ToIP, por ejemplo, de 192.0.2.10 a 192.0.2.20. Ambos límites del intervalo también son valores de documentación y deben sustituirse por el intervalo IPv4 mínimo necesario, sin ampliar las restricciones existentes. Aunque la tabla marca FromIP y ToIP como campos obligatorios, su descripción los limita a Node range; de ello no se deriva una obligación general para las otras variantes.

La referencia de la API indica Enable o Disable para cada uno de los campos QuarantineDigest, MACBinding, L2TP, PPTP y SophosConnectClient, y documenta Disable como valor predeterminado. Esta es información de referencia, no una prueba del estado del grupo guardado actualmente. Cuando QuarantineDigest está activo, el resumen de cuarentena se envía diariamente por correo electrónico. PPTP sigue excluido de los nuevos diseños; L2TP continúa siendo únicamente la opción de compatibilidad limitada descrita anteriormente.

Limitaciones del ejemplo de referencia: Separa los ajustes de los grupos Normal de una rama Clientless que muestra QoSPolicy. Sin embargo, presenta una contradicción en GroupType: el modelo contiene Normal/Clienless, la descripción menciona Normal o Clientless y especifica INTEGER como tipo de datos. Además, el modelo contiene marcadores de posición con dos puntos en lugar de contenido XML completo. De ello no debe deducirse ni una codificación corregida de Clientless ni una correspondencia numérica. Para una operación de escritura, utiliza un valor leído o exportado de la versión instalada cuya correspondencia ya esté establecida; de lo contrario, utiliza el procedimiento seguro de la interfaz. Las alternativas separadas por una barra, como Enable/Disable, no son valores individuales que se puedan copiar tal cual.

El modelo también muestra After con un Name anidado como indicación de posición. La segunda fila de la tabla para Name menciona moveto, pero no demuestra que exista una operación ejecutable de forma independiente. Un cambio de posición debe tratarse como Reorder: puede modificar el Main Group. Antes, guarda el orden, las pertenencias, el estado actual y previsto de las políticas y el procedimiento de reversión; después, comprueba el resultado con el usuario piloto y, si se produce un efecto inesperado, restaura el orden guardado. El modelo no demuestra ni el comportamiento de sustitución o combinación de GroupMembers ni la semántica de actualización de After o de los campos omitidos.

Antes de una operación de escritura Add/Edit de alcance estrictamente limitado, documenta el nombre de destino y el estado deseado. Después, evalúa el resultado real de la operación XML, vuelve a leer exactamente el grupo indicado por su nombre y realiza las pruebas positivas y negativas descritas anteriormente en el servicio afectado. Para Add y Edit, la referencia asigna 502 a la clave UserGroupRecordExists y 503 a la clave UserGroupDuplicateIPInLoginRestriction. Si se obtiene uno de estos resultados, comprueba primero el nombre del grupo existente previsto o las direcciones duplicadas en SelectedNodes, respectivamente. No vuelvas a enviar la solicitud a ciegas ni amplíes LoginRestriction. Estas correspondencias son claves de referencia; el texto renderizado del mensaje puede ser distinto.

Importar grupos de directorio de forma controlada

Grupos de Active Directory

Ve a Authentication > Servers y ejecuta el asistente de importación para el servidor AD configurado. En un clúster HA, la importación debe realizarse en Primary. El asistente solo importa los grupos seleccionados. Por lo tanto, un grupo creado posteriormente en AD no aparecerá automáticamente y deberá importarse de nuevo.

Antes de importar, la consulta a AD debe funcionar: el servidor necesita los valores correctos de NetBIOS domain y Domain name, un ADS username con permisos para buscar, leer y consultar pertenencias a grupos, y su Password. No se necesita una cuenta de administrador de dominio para importar grupos. Connection security ofrece SSL/TLS como opción predeterminada y STARTTLS como alternativa cifrada; Plaintext transmite las credenciales sin cifrar y no es una solución segura para producción. El Port debe corresponder al tipo de conexión seleccionado. Para Validate server certificate, el certificado del servidor AD se carga en Certificates > Certificates > Add > Upload certificate; Server IP/domain debe utilizar el CNAME indicado en el certificado. Si el firewall no puede resolver ese nombre, hay que comprobar la resolución DNS interna o Network > DNS > DNS host entry. La configuración completa del servidor se explica en el artículo sobre AD enlazado anteriormente.

Las Search queries limitan el conjunto de usuarios incluidos. Por ejemplo, OU=VPN_Users,DC=example,DC=com busca en la OU VPN_Users del dominio de documentación example.com; la OU y los componentes del dominio deben sustituirse por el nombre distinguido real. Una base de búsqueda más restringida mantiene el conjunto de usuarios manejable, pero no debe excluir a los usuarios previstos. Solo los usuarios incluidos pueden aparecer como Live Users a través de este servidor. Test connection comprueba la conexión y las credenciales, pero aún no demuestra que un usuario normal esté asignado al grupo correcto. No se admite la imposición estricta de LDAP Channel Binding y LDAP Signing; cualquier requisito de seguridad de AD de este tipo debe aclararse antes de la integración, no eludirse como si fuera un error de grupos.

La importación propiamente dicha se realiza así:

En el servidor AD previsto, haz clic en Import y comienza con Start en el Import group wizard.
Selecciona la Base DN adecuada para la búsqueda de grupos. Debe incluir los grupos necesarios y debe distinguirse de la base de búsqueda de usuarios.
Marca únicamente los grupos AD previstos, por ejemplo, SFOS_Internet_Standard y SFOS_SSLVPN.
Selecciona las políticas comunes de los grupos; después, comprueba la selección y los resultados.
En Authentication > Groups, comprueba ambos grupos y sus políticas. El asistente importa grupos, no todos los registros de usuarios ni sus pertenencias de forma inmediata.
En Authentication > Services > Firewall authentication methods, comprueba que el servidor AD esté seleccionado para el servicio previsto. Si en este procedimiento de configuración se debe consultar primero AD, mueve el servidor a la primera posición y haz clic en Apply. En un entorno existente, conserva el orden de servidores previamente planificado en lugar de cambiarlo de forma generalizada.

Los grupos AD anidados no se evalúan. Si un subgrupo debe aplicarse a una regla de firewall o a una política de VPN, debe importarse exactamente ese subgrupo. El grupo primario de AD de un usuario tampoco se incorpora como una pertenencia normal. Por lo tanto, para las políticas conviene utilizar grupos de seguridad explícitos en lugar del grupo predeterminado de AD Domain Users.

Esto no se limita a Domain Users: si, por ejemplo, SFOS_Internet_Standard pasa a ser el grupo primario de AD del usuario, precisamente esa pertenencia no se incorpora como una pertenencia normal de AD. Como consecuencia, el siguiente grupo importado que coincida puede convertirse en el grupo principal del firewall. El grupo principal del firewall se determina a partir de su propia lista de grupos y no es el grupo primario de AD.

Después de cambiar las pertenencias a grupos de AD, los grupos importados o el orden de los grupos, el usuario debe volver a iniciar sesión. Solo entonces el firewall vuelve a evaluar los grupos y actualiza el objeto de usuario.

Si STAS y Synchronized User ID están configurados simultáneamente, el servidor de autenticación utiliza el mecanismo del que recibe primero la solicitud de inicio de sesión. Por eso, si las pruebas piloto arrojan resultados diferentes, comprueba también Client Type en lugar de reordenar inmediatamente los grupos o los servidores.

Grupos Entra

Para importar grupos Entra, el registro de la aplicación en Microsoft Graph necesita el permiso de aplicación Group.Read.All con consentimiento del administrador. Los relojes del firewall y de Microsoft Entra ID deben estar sincronizados; de lo contrario, la conexión puede fallar.

Después, ve a Authentication > Servers y haz clic en el asistente de importación de grupos del servidor Microsoft Entra ID. Puedes importar todos los grupos o solo aquellos cuyo Display name o Description coincida con un filtro. Surfing quota, Access time, Network traffic y Traffic shaping se pueden asignar a todos los grupos importados o a grupos individuales. Los grupos recién importados también deben incorporarse a las políticas de acceso remoto IPsec o SSL VPN utilizadas; la importación por sí sola no otorga acceso VPN.

Evaluar correctamente el grupo principal y la pertenencia a varios grupos

Abre el usuario en Authentication > Users y desplázate a Policies:

Group muestra el primer grupo coincidente en la lista del firewall y, por tanto, el grupo principal.
Other group memberships muestra otros grupos de AD importados a los que pertenece el usuario.

En Policies aparecen otros dos campos solo si se cumplen ambas condiciones para cada uno:

Group SSL VPN policies: El usuario pertenece a varios grupos de AD y al menos dos de esos grupos están incluidos en políticas SSL VPN de acceso remoto.
Group clientless SSL VPN policies: El usuario pertenece a varios grupos de AD y al menos dos de esos grupos están incluidos en políticas SSL VPN sin cliente.

Por tanto, si falta uno de estos campos, comprueba primero las pertenencias a grupos de AD, los grupos importados y su inclusión en la política de VPN correspondiente. La pertenencia a varios grupos de AD por sí sola no basta para que se muestre el campo. No amplíes los permisos de VPN en producción para hacer visible el campo. Además, que el campo se muestre no constituye una prueba de acceso; la combinación real de los permisos se explica más abajo.

En Authentication > Groups > Reorder puedes cambiar el orden arrastrando y soltando. Haz clic en Close para cerrar el cuadro de diálogo. Si auth-pilot@example.com pertenece a SFOS_Internet_Standard y SFOS_SSLVPN, el grupo coincidente situado más arriba se convertirá en el grupo principal en el próximo inicio de sesión.

Este orden no solo se aplica al caso de error actual. Antes de realizar un cambio, comprueba si la función afectada admite otros grupos. De lo contrario, un cambio de posición podría resolver un caso de VPN y, al mismo tiempo, modificar la MFA, la cuota o el horario de acceso de otros usuarios.

Funciones compatibles con varios grupos de AD

La siguiente matriz se aplica expresamente a Active Directory. No debe extrapolarse a LDAP, RADIUS o Microsoft Entra ID sin comprobarlo antes.

Se pueden tener en cuenta varios grupos de AD en:

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. Si interviene alguna política de túnel completo aplicable, el resultado es un túnel completo. Comprueba esta combinación mediante una prueba con un cliente real.

En Clientless SSL VPN se tienen en cuenta los permisos de todas las políticas a las que pertenece alguno de los grupos de AD del usuario. Por eso, comprueba no solo la política esperada, sino también los marcadores o recursos adicionales autorizados a través de otros grupos.

Hotspots tiene en cuenta exclusivamente el grupo principal.

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

WAF rules, My policy overrides;
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 WAF, L2TP, PPTP y Remote access IPsec, la política del usuario puede mostrar Enable aunque la autorización proceda únicamente de Other group memberships y, por tanto, no se permita el acceso. Evalúa estos servicios según el grupo principal o una asignación directa al usuario, no solo según lo que muestre la interfaz.

En las funciones compatibles con varios grupos, el orden de la regla o política correspondiente sigue siendo determinante. Una regla de firewall puede aplicarse a través de SFOS_SSLVPN aunque SFOS_Internet_Standard sea el grupo principal. Esto no significa que la MFA o la cuota también utilicen SFOS_SSLVPN.

En Web policies hay dos decisiones independientes: primero, la regla de firewall coincidente determina la política web. Dentro de ella se aplica la primera regla que coincida tanto con el usuario como con el sitio web. Si el usuario piloto pertenece a ambos grupos del ejemplo y la primera regla web bloquea los sitios de deportes para SFOS_SSLVPN, un sitio de deportes quedará bloqueado aunque SFOS_Internet_Standard sea su grupo principal y una regla posterior permita los sitios de noticias para ese grupo. En cambio, IPS y Application control utilizan la política de la regla de firewall coincidente; el orden de los grupos no genera una combinación adicional de estas políticas.

Para MFA, en lugar de seleccionar un grupo, se puede incluir explícitamente al usuario o aplicar MFA a todos los usuarios. Una autorización únicamente a través de Other group memberships no basta. Los hotspots del User Portal dependen exclusivamente del grupo principal; pertenecer a otro grupo de AD no amplía esa lista.

Comprobar el efecto del grupo

Un grupo guardado y un usuario visible todavía no demuestran que la configuración funcione:

Finaliza la sesión existente del usuario piloto y vuelve a iniciar sesión.
En Authentication > Users > usuario > Policies, anota el estado, Group, Other group memberships y las posibles anulaciones.
En Current activities > Live users, comprueba el nombre de usuario, la IP de origen y Client Type.
En una regla de firewall basada en el usuario, genera el tráfico previsto y comprueba el Firewall Rule ID en Log Viewer.
Prueba el horario de acceso, la cuota, la MFA y el acceso remoto a través del servicio realmente afectado en cada caso.
Repite el mismo intento con un usuario que no pertenezca al grupo piloto como prueba negativa.

Para comprobar la cuota, abre Authentication > Users > usuario > View usage. Los datos de uso solo están disponibles si una regla de firewall basada en el usuario procesa el tráfico y Log firewall traffic está activado.

Comprobar reglas de firewall con Log Viewer, Policy Test y Packet Capture muestra la prueba completa de tráfico. Si no están claros la selección del servicio, la identidad o el grupo principal, Resolver sistemáticamente errores de autenticación en Sophos Firewall recorre toda la cadena de comprobación.

Revertir cambios y limpiar grupos

Cambia solo una política de grupo o una posición cada vez. Si la prueba piloto muestra un efecto inesperado, restaura el orden y la asignación de políticas anotados, vuelve a iniciar sesión con el usuario y repite las pruebas positiva y negativa.

Los grupos de AD se eliminan primero en el directorio y después, por separado, en Authentication > Groups en el firewall. Purge AD users no elimina grupos.

Para los usuarios de AD:

Elimina primero al usuario en AD. Mientras siga existiendo allí, el firewall puede volver a crearlo en un inicio de sesión posterior.
En Authentication > Users, haz clic en Purge AD users. No es necesario seleccionar previamente a los usuarios; el firewall comprueba el servidor AD y solo elimina los usuarios que ya se hayan eliminado allí.
En HA, inicia el proceso en Primary. Los registros se eliminan en Primary y Auxiliary. La limpieza no interrumpe el inicio de sesión, el cierre de sesión ni la contabilidad de usuarios.

Una exportación de configuración contiene los grupos de AD importados y los creados localmente, pero no los usuarios de servidores de autenticación externos. En cambio, una copia de seguridad completa incluye todos los usuarios y grupos. Ten en cuenta esta limitación si la reversión no se limita a un único cambio de política.

Eliminar de forma segura un grupo identificado por su nombre mediante la API

Antes de cualquier eliminación, define el Name exacto del grupo de destino y guarda las políticas, el orden, los miembros y los usos. Que la tabla antigua de la API marque Name como no obligatorio no autoriza a eliminar un grupo sin indicar su nombre: la descripción exige un nombre para identificar el objeto. Comprueba previamente los usuarios reales del grupo, las asignaciones de VPN, incluidas L2TP/IPsec, la selección para la autenticación externa, las referencias en reglas de firewall y su uso como grupo predeterminado para invitados. Si el grupo sigue siendo necesario, realiza una migración expresamente planificada y de alcance estrictamente limitado, o detén el proceso. No fuerces la eliminación, no limpies usuarios ni relajes los accesos solo para conseguir que se elimine el grupo. Se mantienen el orden de AD descrito anteriormente y la separación respecto a Purge AD users.

La referencia de eliminación vincula filas de resultados con claves de mensajes JavaScript relativas a estas dependencias. Las categorías no determinan por sí solas el texto renderizado del mensaje ni la causa de un error. Para la construcción de la solicitud y el tratamiento del resultado XML, se aplica Usar la API XML de forma segura; la referencia de eliminación de grupos no proporciona un ejemplo de payload, por lo que no permite construir una solicitud Delete completa. Si se rechaza la operación, conserva el grupo y comprueba específicamente la referencia indicada en el resultado. Incluso después de un resultado satisfactorio, vuelve a leer exactamente el destino, comprueba su ausencia y repite las pruebas de servicio y acceso previstas.

Los usuarios y los grupos comparten el rango de ID interno hasta 65535. Un número elevado de objetos visibles no demuestra por sí solo un problema con el límite. Si un usuario muestra un User ID superior a 65535 y no aparece como usuario activo, el comportamiento encaja con el límite de ID de usuario de Sophos Firewall.

Acotar los errores según el síntoma

Después de cada corrección, vuelve a iniciar sesión con el usuario afectado y comprueba Group y Other group memberships. A continuación, basta con un siguiente paso específico para cada síntoma.

No aparece un nuevo grupo de AD

Vuelve a iniciar el asistente de importación del servidor AD y, en HA, ejecútalo en Primary. Después, comprueba en Authentication > Groups que esté presente exactamente el grupo necesario. No crees un grupo de sustitución con un alcance amplio solo para que funcione un inicio de sesión.

El usuario LDAP termina en el grupo predeterminado

Comprueba Base DN, Authentication attribute y Group name attribute en el servidor LDAP; después, revisa el orden de los servidores y Default group en Authentication > Services. Ejecuta Test connection para el servidor LDAP. El asistente de importación de AD no se encarga de esta asignación.

El usuario Entra termina en el grupo de reserva

Comprueba si se ha importado el grupo Entra y si el token proporciona el grupo esperado. Después, revisa Fallback user group directamente en el servidor Entra. El Default group general de Authentication > Services no se utiliza para esta asignación.

El usuario tiene un grupo principal incorrecto

Compara las pertenencias a grupos de AD, los grupos importados y el orden actual. Comprueba el nuevo orden solo después del siguiente inicio de sesión y con varios usuarios representativos.

La regla de firewall se aplica, pero la MFA o la cuota no

Las reglas de firewall admiten otros grupos de AD, pero la MFA y las cuotas no. Comprueba el grupo principal, las posibles anulaciones y la asignación real de la política en Authentication > Users > usuario > Policies. Que la regla se aplique no demuestra que la MFA o la cuota evalúen el mismo grupo.

El cambio de grupo no surte efecto para un solo usuario

Compara los campos de política específicos del usuario y la selección real de usuarios y grupos en la regla o política afectada: si solo se selecciona el grupo, se utilizan los valores del grupo; si se seleccionan el usuario y su grupo, se utilizan los valores del usuario. Comprueba también las limitaciones de la función respecto al grupo principal y la pertenencia a varios grupos. Restablece el valor del grupo únicamente si la excepción documentada ya no es necesaria.

Un grupo AD anidado no se aplica

Importa el propio subgrupo necesario y añade al usuario directamente a él. No basta con importar solo el grupo superior.