Crear y gestionar usuarios locales en Sophos Firewall

Un usuario local se guarda directamente en Sophos Firewall y se autentica con la base de datos local de usuarios. Es adecuado para entornos pequeños, cuentas piloto y colaboradores externos concretos. Una cuenta local solo resulta apropiada como alternativa a un servicio de directorio si se han probado, para ese servicio, el orden de los servidores, un nombre de usuario distinto, el acceso al portal y el comportamiento cuando falla la fuente externa. La ayuda de SFOS documenta el orden de los servidores, pero no garantiza la conmutación para todos los tipos de error.

Este artículo se aplica a la interfaz WebAdmin de SFOS 22. La mera creación de un usuario no le concede acceso. El grupo, el método de autenticación, el portal o cliente y la política de firewall o VPN deben configurarse de forma coherente.

Flujo de trabajo rápido:

1. Definir el caso de uso, los usuarios destinatarios y el servicio necesario.
2. Preparar un grupo restrictivo de tipo Normal en Authentication > Groups.
3. En Authentication > Users > Add, introducir un nombre de usuario permanente y seleccionar User type: User.
4. Asignar una contraseña individual y robusta, así como el grupo correcto.
5. Dejar sin cambios los campos de política del usuario si deben aplicarse los valores del grupo.
6. Limitar conscientemente Simultaneous sign-ins y Sign-in restriction.
7. En Authentication > Services, comprobar que Local esté seleccionado para el servicio utilizado.
8. Configurar por separado y con el menor alcance posible el portal, la regla de usuario o la política de acceso remoto.
9. Probar con una cuenta piloto un inicio de sesión positivo, uno negativo y tráfico real.
10. Solo entonces activar MFA, crear más usuarios y documentar la baja.

⚠️ El nombre de usuario no se puede cambiar posteriormente. Defina el esquema de nombres, el tipo de cuenta y el responsable antes de guardar. SFOS convierte en minúsculas las letras mayúsculas del nombre de usuario. Una cuenta de sustitución tiene una identidad nueva; por tanto, vuelva a comprobar sus reglas, cuotas, asignaciones VPN y trazas de auditoría.

Cuándo es adecuado un usuario local

Los usuarios locales no requieren Active Directory ni un servidor RADIUS o LDAP externo. Esto simplifica la puesta en marcha, pero traslada por completo al firewall la gestión de contraseñas, MFA, grupos, desactivación y revisiones. Resulta práctico para unas pocas cuentas administradas cuidadosamente. Para muchos empleados o altas y bajas frecuentes, un directorio central suele ser más fácil de mantener.

Un usuario local normal es adecuado, por ejemplo, para:

• una cuenta piloto para Captive Portal, User Portal o Remote Access;
• un entorno pequeño sin servicio de directorio;
• un proveedor externo concreto con una duración y una responsabilidad claras;
• una alternativa de emergencia probada, con un nombre de usuario distinto, cuando una fuente de autenticación externa no está disponible temporalmente.

No utilice una cuenta local para varias personas. Las credenciales compartidas dificultan los cambios de contraseña, el uso de MFA, la gestión de cuotas, la auditoría y una baja ordenada.

No mezclar los tipos de usuario

SFOS ofrece varios tipos de usuario similares que resuelven tareas diferentes:

• Un usuario local normal inicia sesión con nombre de usuario y contraseña y recibe políticas mediante un grupo normal o mediante excepciones deliberadas a nivel de usuario.
• Un usuario invitado tiene una duración limitada, utiliza la configuración de Guest User y se usa normalmente mediante Captive Portal.
• Un Clientless User se identifica por una dirección IP y no realiza un inicio de sesión interactivo.
• Un administrador local recibe User type: Administrator y un perfil de Device Access para permisos de WebAdmin.
• Un usuario de AD, LDAP, RADIUS o Entra se autentica mediante una fuente externa. Según el método, su registro local no se crea hasta el primer inicio de sesión correcto.

Para una persona que deba iniciar sesión en Captive Portal o en un servicio VPN se utiliza User type: User. Esta cuenta no recibe por ello acceso a WebAdmin ni a SSH.

Ejemplo y requisitos

El siguiente ejemplo utiliza:

• nombre de usuario pilotuser01;
• nombre visible Local Pilot User;
• dirección de correo pilotuser01@example.com;
• grupo Local_Pilot_Users;
• regla de firewall Local-Pilot-to-WAN;
• origen de inicio de sesión permitido desde 10.20.30.10 hasta 10.20.30.50.

example.com es un dominio reservado para documentación; el intervalo de direcciones pertenece a una red privada utilizada como ejemplo. Sustituya el nombre de usuario, la dirección de correo electrónico, el grupo, la regla y las direcciones por los valores de su entorno. El nombre de usuario, deliberadamente neutro respecto a la función, no contiene ninguna dirección de correo electrónico y, por tanto, sigue siendo válido si esta cambia. El esquema de nombres debe ser coherente con los procesos del servicio de asistencia y de baja, así como con los nombres ya utilizados en el directorio.

Antes de crear la cuenta se aclara lo siguiente:

• ¿Qué servicio autentica al usuario: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec u otro acceso compatible?
• ¿Qué grupo normal contiene la configuración común?
• ¿Qué política de firewall o Remote Access permite el acceso posterior?
• ¿Desde qué direcciones IPv4 puede iniciar sesión la cuenta?
• ¿Cuántos inicios de sesión simultáneos se necesitan realmente?
• ¿Se exige MFA local y mediante qué portal se hará el registro inicial?
• ¿Quién desactiva la cuenta y comprueba las sesiones existentes al darla de baja?

Gestionar grupos de usuarios y el Main Group en Sophos Firewall explica la lógica común de grupos. Para usuarios locales normales se utiliza un grupo de tipo Normal. Un grupo de tipo Clientless pertenece al modelo basado en IP y no es la base adecuada para este proceso de inicio de sesión.

Crear el usuario local

La cuenta se crea en Authentication > Users > Add:

1. Introduzca pilotuser01 en Username. SFOS almacena el valor en minúsculas y este no se puede modificar posteriormente.
2. Introducir Local Pilot User en Name.
3. Establecer User type en User.
4. Introducir y confirmar una contraseña larga e individual procedente del proceso de contraseñas previsto.
5. Para Email, introduzca pilotuser01@example.com o el buzón de correo de esta persona. Para una cuenta técnica, utilice una dirección monitorizada con un responsable claramente designado.
6. En Group, seleccionar Local_Pilot_Users.
7. Cambiar Quarantine digest, los campos de políticas y los campos de Remote Access únicamente cuando se necesite la función correspondiente o una excepción de usuario documentada.
8. Definir de forma adecuada Simultaneous sign-ins y Sign-in restriction.
9. Guardar con Save.

SFOS rechaza las contraseñas de uso común y las palabras detectadas por su comprobación de diccionario. Utilice para cada cuenta una contraseña larga y única generada conforme a su proceso de gestión de contraseñas. Una contraseña de ejemplo que pudiera copiarse directamente se convertiría de inmediato en un secreto conocido y, por tanto, no sería un modelo seguro.

La misma vista de usuarios también muestra registros autenticados externamente. Para los usuarios importados de Active Directory, el firewall sobrescribe el valor de Email introducido localmente con la dirección de AD durante la autenticación. Por tanto, una corrección local no es permanente; el administrador responsable de AD debe corregir el valor en origen.

Para los usuarios de AD que pertenecen a varios grupos, Group muestra el Main Group y Other group memberships muestra los demás grupos de AD. Other group memberships aparece deshabilitado y es de solo lectura para los usuarios sincronizados mediante un servidor de autenticación externo como AD o RADIUS. Las pertenencias se comprueban y modifican en la fuente responsable, sin eludirlas mediante un grupo local de sustitución. El artículo sobre grupos enlazado anteriormente explica qué funciones utilizan los grupos adicionales de AD; esta compatibilidad no se aplica automáticamente a RADIUS.

Valores del grupo o excepciones de usuario

En el usuario se pueden definir Surfing quota, Access time, Network traffic y Traffic shaping, además de varios campos de Remote Access. Las guías del fabricante describen la prioridad de forma distinta: la guía de creación da prioridad general a los valores del usuario, mientras que la vista de usuarios también tiene en cuenta la selección de usuarios y grupos en reglas y políticas. La comprobación de excepciones de usuario y selección de reglas explica este límite; no debe suponerse que una política específica del usuario sea efectiva de forma incondicional. Si el grupo debe seguir siendo la base fácil de mantener, estos campos no se sobrescriben de forma preventiva.

Una excepción de usuario es adecuada para un caso claramente documentado, por ejemplo un Access Time más restrictivo durante una intervención temporal. Se registra:

• qué campo difiere del valor del grupo;
• por qué es necesaria la excepción;
• cuándo se revisará o eliminará;
• cómo volverá a aplicarse el valor original del grupo.

Access Time para usuarios y cuotas de Surfing y Network Traffic explican por completo cada política. En el objeto de usuario solo debe asignarse una política cuyo funcionamiento ya se conozca.

Limitar el número y el origen de los inicios de sesión

Simultaneous sign-ins limita las sesiones paralelas. Global setting adopta el valor para nuevos usuarios definido en Authentication > Services. También se puede establecer un valor propio o elegir Unlimited. Las sesiones ilimitadas rara vez son necesarias para una cuenta individual estándar y dificultan detectar credenciales compartidas.

Sign-in restriction limita las direcciones IPv4 desde las que el usuario puede iniciar sesión:

• Any node: permitir el inicio de sesión desde cualquier origen accesible;
• User group nodes: heredar el valor del grupo;
• Selected nodes: indicar direcciones IPv4 concretas previstas;
• Node range: permitir un intervalo IPv4 contiguo.

Para este ejemplo, seleccione Node range e introduzca 10.20.30.10 como dirección inicial y 10.20.30.50 como dirección final. Sustituya ambos valores por el intervalo contiguo más pequeño desde el que el usuario inicia sesión realmente. Si necesita direcciones IPv4 individuales no contiguas, utilice Selected nodes. Una selección demasiado restrictiva bloquea inicios de sesión legítimos; Any node no sustituye una regla de firewall, una ACL del portal ni la MFA.

No se activa MAC binding en este procedimiento básico. Es compatible con la autenticación basada en cliente, pero no con Remote Access VPN ni Captive Portal. Si se activa sin indicar una dirección MAC, SFOS vincula automáticamente la primera dirección MAC detectada en el primer inicio de sesión. En dispositivos móviles, tras un cambio de Wi-Fi o con clientes compartidos, esto puede convertirse rápidamente en una dependencia inesperada.

API XML: separar los límites de usuarios y administradores

Para las automatizaciones, la referencia de la API XML para SFOS 22 y 23 distingue los mismos ámbitos al añadir y actualizar User. Las siguientes rutas permiten localizar los elementos en la documentación; no constituyen una solicitud completa y ejecutable:

• Tipo de cuenta y permisos: User/UserType permite User o Administrator; la tabla de parámetros indica User como valor predeterminado y señala que el campo es opcional. User/Profile aparece marcado con Mandatory: Yes, pero, según una nota explícita, solo se aplica a Administrator. Esto no implica que los usuarios normales deban tener un perfil. Para los administradores sigue siendo necesario un perfil de Device Access deliberadamente restrictivo.
• Origen del inicio de sesión del usuario normal: Para User/LoginRestriction, el ejemplo enumera los valores AnyNode, UserGroupNode, SelectedNodes y NodeRange. Con SelectedNodes, las direcciones IPv4 se encuentran en User/NodeList/IPAddress; con NodeRange, User/FromIP y User/ToIP definen los límites. La indicación Mandatory: Yes de estos campos en la tabla está expresamente condicionada a que se seleccione un intervalo. No hace que estos campos sean obligatorios para todos los tipos de restricción.
• Origen del inicio de sesión del administrador: User/LoginRestrictionForAppliance se refiere al inicio de sesión del administrador en el dispositivo, no al inicio de sesión de un usuario normal. La tabla permite AnyNode, SelectedNodes y NodeRange, e indica AnyNode como valor predeterminado. Según el ejemplo, las direcciones IPv4 individuales se incluyen en User/AdminAccessNodeList/IPAddress, y los límites del intervalo en User/AdminAccessFromIP y User/AdminAccessToIP. Los campos del administrador no deben intercambiarse con los del usuario normal; una indicación Yes en la tabla no debe interpretarse como una obligación general al margen del tipo de cuenta y de la restricción seleccionada. Un valor predeterminado documentado no constituye una recomendación de acceso sin restricciones para los administradores.
• Horario de acceso del administrador: User/ScheduleForApplianceAccess selecciona el horario de acceso al dispositivo y, según la nota de la tabla, solo se aplica a administradores. El ejemplo muestra All The Time, pero la columna de valor predeterminado está vacía. Por tanto, el valor del ejemplo no es un valor predeterminado confirmado y este campo no sustituye la política de Access Time de un usuario normal.
• Direcciones estáticas de SSL VPN: User/SSLVPNIPv4Address y User/SSLVPNIPv6Address son opcionales. Ambos campos remiten al rango estático reservado en SSL VPN global settings, no a direcciones LAN arbitrarias. La activación que se explica más abajo y la selección de una dirección libre del rango IPv4 o IPv6 correspondiente también se aplican a esta asignación.

⚠️ El ejemplo XML muestra, para LoginRestrictionForAppliance, el valor truncado AnyNode/. No constituye una lista completa de valores ni un modelo para copiar; la tabla enumera los tres valores indicados anteriormente. Si la referencia de la versión utilizada, una exportación existente y la asignación prevista difieren entre sí, se detiene el proceso antes de escribir y se aclaran el tipo de cuenta, el campo y el valor permitido consultando la referencia correspondiente o al soporte de Sophos. No se completa el valor truncado por conjetura ni se relaja ninguna restricción de acceso para conseguir que se acepte una solicitud.

Conectar el método de autenticación y el acceso

Un usuario guardado solo puede iniciar sesión en un servicio que consulte la base de datos local. En Authentication > Services, active el método Local en la lista correspondiente al servicio utilizado.

Las áreas están separadas:

• Firewall authentication methods para tráfico de firewall y Captive Portal;
• User portal authentication methods para User Portal;
• VPN portal authentication methods para VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods para estos métodos VPN;
• SSL VPN authentication methods para Remote Access SSL VPN.

Cuando hay varias fuentes, se consultan en el orden mostrado. Por tanto, una prueba correcta en User Portal no demuestra automáticamente que el mismo usuario esté configurado correctamente para SSL VPN o IPsec.

Puede seleccionar hasta 20 servidores por método de autenticación. Para User Portal y VPN Portal, la opción de herencia es Set authentication methods same as firewall. Para SSL VPN, SFOS muestra Same as VPN o Same as firewall, según la referencia seleccionada. Compruebe esta opción y el orden resultante antes de añadir o mover Local.

Configurar el acceso por separado

La identidad local no abre una ruta de red. Captive Portal requiere además Device Access, Web Authentication y una regla de usuario adecuada. El procedimiento completo se explica en Configurar y probar Captive Portal en Sophos Firewall.

User Portal y VPN Portal también son servicios independientes. El modelo de portales de Sophos Firewall explica puertos, finalidad, Device Access y límites WAN. Las políticas de Remote Access se mantienen en las guías VPN correspondientes y no se consideran terminadas solo porque haya un campo definido en el objeto de usuario.

Interpretar correctamente los campos de Remote Access

En los métodos de Remote Access distintos de SSL VPN, los valores de política específicos del usuario prevalecen sobre el grupo. SSL VPN sigue otra lógica: El usuario recibe los recursos de todas las políticas Full y Split Tunnel en las que figure directamente o mediante uno de sus grupos compatibles. Por tanto, el campo SSL VPN policy no sustituye de forma simple las políticas de grupo.

Dos campos adicionales de grupos solo son visibles bajo determinadas condiciones:

• Group SSL VPN policies muestra las políticas de SSL VPN de acceso remoto de los grupos únicamente si el usuario pertenece a varios grupos de AD y al menos dos de esos grupos están incluidos en políticas de SSL VPN de acceso remoto.
• Group clientless SSL VPN policies muestra las políticas de Clientless SSL VPN de los grupos únicamente si el usuario pertenece a varios grupos de AD y al menos dos de esos grupos están incluidos en políticas de Clientless SSL VPN.

Si falta alguno de estos campos, compruebe primero ambas condiciones para ese tipo concreto de VPN. La visualización no es un control independiente para conceder acceso; los recursos, los marcadores, la validación y la reversión siguen tratándose en las guías VPN correspondientes.

SSL VPN IP address solo aparece cuando las direcciones estáticas están activadas en SSL VPN global settings. La dirección IPv4 o IPv6 debe estar libre y pertenecer al rango estático creado automáticamente en esa sección. Si un servidor RADIUS asigna direcciones, su asignación tiene prioridad. IPsec remote access, en cambio, activa el acceso mediante Sophos Connect y puede recibir una dirección propia asignada.

L2TP y PPTP son métodos heredados. Cada uno de estos campos del objeto de usuario habilita su respectivo tipo de acceso remoto y permite introducir una dirección IP que se asignará mediante arrendamiento al usuario remoto. Se trata de una asignación de IP mediante arrendamiento específica del usuario, no de una configuración completa del túnel ni de un motivo para habilitar un nuevo acceso heredado. Tras la asignación, el usuario debe iniciar sesión primero en VPN Portal y crear una contraseña antes de poder conectarse. La valoración actual y la ruta de migración de L2TP se explican en L2TP Remote Access; PPTP ya no se contempla para nuevos accesos. Clientless SSL VPN policy solo abre los marcadores de navegador asignados y no proporciona un túnel completo. El procedimiento independiente se describe en Clientless Access.

Para una regla de firewall basada en usuarios, se definen con el menor alcance posible el origen, el destino, el servicio y el usuario o grupo. Log firewall traffic permanece activo durante la validación. Los fundamentos se explican en Comprender y configurar de forma segura las reglas de Sophos Firewall.

Validar con pruebas positivas y negativas

Una cuenta visible con estado Active todavía no demuestra que todo funcione. El piloto se prueba mediante el mismo servicio que se utilizará después:

1. Iniciar sesión con pilotuser01 en una ventana privada del navegador o desde un cliente de prueba limpio.
2. En Current activities > Live users, comprobar el nombre de usuario, la IP de origen y el Client Type.
3. En Log Viewer > Authentication, comprobar el inicio de sesión correcto, la autenticación local y la hora.
4. Generar el tráfico previsto y comprobar en el registro del firewall o de la VPN que Local-Pilot-to-WAN, o su Firewall Rule ID, corresponde a la regla aplicada.
5. Utilizar como prueba negativa un origen o una función expresamente no permitidos.
6. Si hay una cuota o un Access Time activo, probar su efecto por separado dentro y fuera del límite.
7. Documentar el resultado, el grupo utilizado, las excepciones de usuario y el método de autenticación.

Una prueba negativa no debería fallar únicamente porque se haya utilizado a propósito una contraseña incorrecta. También se comprueba que un origen no autorizado, un usuario sin el grupo adecuado o una función no prevista no obtengan acceso. Así se separa la validación de la contraseña del efecto de las políticas y reglas.

Si no está claro si el error se debe al estado del usuario, al método de autenticación, al grupo o a la regla de acceso, Solucionar sistemáticamente los errores de autenticación de Sophos Firewall describe la secuencia de comprobaciones. Para un análisis detallado, /log/access_server.log contiene eventos de autenticación, autorización y contabilización; Log Viewer sigue siendo el primer paso.

Administrar contraseñas, MFA y el uso

Para cambiar como administrador la contraseña de una cuenta local existente en SFOS 22 y 23, se abre el usuario correspondiente en Authentication > Users y se hace clic en Change password. Antes se comprueban la cuenta y su responsable, y se prepara una contraseña nueva, larga y única mediante el proceso de contraseñas aprobado. Se introduce la nueva contraseña, se guarda el cambio y se entrega el secreto de forma segura a la persona autorizada. Después se prueba un nuevo inicio de sesión con la nueva contraseña en el servicio que se utiliza realmente. Esta operación de WebAdmin es distinta del autoservicio en User Portal; las cuentas autenticadas externamente siguen gestionándose en su fuente de usuarios correspondiente. Esto no garantiza que las sesiones existentes finalicen automáticamente.

Un usuario local puede cambiar su contraseña en User Portal > Personal > Change Password. Esto se aplica a la base de datos local, no a cuentas de AD, LDAP o RADIUS autenticadas externamente. En Personal > Personal Details, el usuario también puede cambiar su nombre visible. El nombre de usuario y la dirección de correo permanecen allí en modo de solo lectura. El administrador mantiene la dirección de correo en el objeto de usuario; el nombre de usuario tampoco se puede modificar allí. User Portal solo se hace accesible desde las zonas necesarias y no se abre de forma general a WAN solo para este mantenimiento.

Para obtener una protección adicional, seleccione la cuenta en Authentication > Multi-factor authentication. Con Generate OTP token with next sign-in, el usuario registra el token mediante User Portal o VPN Portal. MFA para Sophos Firewall explica el algoritmo de hash, el acceso al portal, la recuperación y el despliegue piloto. Active MFA únicamente después de probar el inicio de sesión normal y el procedimiento de recuperación.

En Authentication > Users > > View usage se muestran las cuotas asignadas, el tiempo de Surfing y el consumo de datos. Para ello, el tráfico debe coincidir con una regla de firewall basada en usuarios que tenga Log firewall traffic. Reset user accounting pone a cero los contadores de Surfing y Network Traffic y, por tanto, no se utiliza como solución general para problemas de inicio de sesión.

Revertir el cambio y eliminar la cuenta

Antes de la fase piloto, documente el orden existente en Authentication > Services y todos los ajustes modificados de grupos, portales, reglas y VPN. De este modo, la reversión no dependerá de valores predeterminados supuestos. Cuando una persona cause baja, falle el piloto o deje de ser necesaria la cuenta, proceda en orden inverso:

1. Comprobar dependencias en reglas, grupos, políticas de Remote Access, cuotas, MFA y documentación.
2. En Authentication > Users, seleccionar al usuario y establecer Change status en Inactive.
3. Intentar un nuevo inicio de sesión como prueba negativa.
4. En Current activities > Live users, comprobar las sesiones existentes y usar Disconnect para un usuario normal cuando sea necesario.
5. Eliminar al usuario de reglas de cortafuegos y políticas de acceso remoto, o restaurar la selección previa documentada.
6. Restaurar exactamente el estado anterior documentado de los ajustes modificados de grupos, portales y servicios de autenticación.
7. Comprobar los registros del firewall, de la VPN y de configuración para detectar nuevos intentos, tráfico residual y las modificaciones realizadas.
8. Eliminar la cuenta únicamente después de resolver las dependencias, o mantenerla inactiva conforme al proceso de conservación.

API XML: comprobar por separado la cuenta que se va a eliminar y el resultado. La referencia de la operación Delete para SFOS 22 y 23 exige el Username exacto guardado. El fragmento de la descripción <Name><username></Name> se refiere a ese nombre de usuario, no al nombre visible Name del formulario Add ni a un supuesto identificador interno. No constituye una solicitud completa y ejecutable. El procedimiento anterior se refiere a usuarios normales; los administradores y la cuenta que tiene la sesión iniciada deben tratarse por separado. Antes de cualquier eliminación, se mantiene un acceso de administración independiente y operativo.

Las filas de estado de esta operación asocian 200 con Message.UserDeleteSuccess, 204 con Message.UserAdminOrCurrentUserNotDeleted, 205 con Message.AuthorizerExists, 206 con Message.UserForeignKeyExists, 210 con Message.UserIMRuleExists y 500 con Message.UserDeleteFailed. Son identificadores literales, no textos de mensajes garantizados en tiempo de ejecución. En particular, los identificadores de no eliminación y de dependencias correspondientes a 204, 205, 206 y 210 no indican de forma general que la eliminación se haya realizado correctamente; esta tabla de operaciones no es una clasificación de estados HTTP. De estos identificadores no se deduce una eliminación automática en cascada ni pasos de limpieza para Authorizer, claves externas o reglas IM; el identificador IM no confirma ninguna función actualmente compatible en la interfaz gráfica.

Si el resultado no está claro o se interrumpe una operación de escritura, antes de volver a intentarlo se comprueban en Authentication > Users el nombre de usuario exacto guardado y su estado actual. Para una eliminación autorizada y compatible, se utiliza la interfaz compatible o, antes de realizar escrituras mediante la API sobre las que haya dudas, se aclara con el soporte de Sophos el contrato de solicitud y resultado de la compilación instalada. Después se comprueba que la cuenta concreta prevista ya no exista y que las demás cuentas necesarias y el acceso de administración sigan funcionando sin cambios. Las dependencias y los requisitos de conservación deben aclararse previamente; la desactivación y la desconexión de sesiones no sustituyen esta comprobación de la eliminación.

La ayuda de SFOS no confirma que la desactivación finalice todas las conexiones existentes. Compruebe y desconecte por separado las sesiones y los túneles. Después de una reactivación, repita las pruebas positivas y negativas.

Antes de una eliminación arriesgada, puede exportar el objeto de configuración User con Include dependent entity en Backup and firmware > Import export. La exportación contiene datos confidenciales, incluidas contraseñas, y debe cifrarse y almacenarse en una ubicación con acceso controlado. La Secure Storage Master Key correcta también debe estar disponible para una importación posterior. Una importación actualiza la configuración existente y aplica los valores importados cuando hay elementos que se solapan. Por tanto, también pueden sobrescribirse las dependencias compartidas exportadas junto con el objeto. Revise el contenido y las consecuencias antes de importar, preferiblemente en un entorno de prueba adecuado.

Una copia de seguridad completa no permite revertir rápidamente un solo usuario: una restauración sustituye toda la configuración, reinicia el firewall y descarta los cambios posteriores. El proceso se explica en Copia de seguridad y restauración en Sophos Firewall.

En un clúster HA, realice el cambio en el nodo principal y compruebe después el estado de sincronización. Los registros y los informes no se sincronizan entre los nodos y deben examinarse por separado durante el diagnóstico.

Los usuarios y grupos comparten identificadores internos. Una gran cantidad de objetos por sí sola no demuestra un problema. Sin embargo, si un usuario muestra una User ID superior a 65535 y no se autentica, se utiliza el procedimiento específico para el límite de User ID de Sophos Firewall, en lugar de cambiar contraseñas o reglas sin pruebas.

Delimitar errores según el síntoma

Se rechazan el nombre de usuario y la contraseña

En Authentication > Users, comprobar que la cuenta sea local, esté activa y tenga el nombre de usuario esperado. Después, en Authentication > Services, comprobar para el servicio concreto si está seleccionado Local. Un inicio de sesión correcto en otro portal no demuestra esta selección de servicio.

El inicio de sesión funciona, pero la regla de usuario no coincide

En Current activities > Live users, comprobar la identidad, la IP de origen y el Client Type. A continuación, revisar en Log Viewer la posición de la regla, Source Zone, usuario o grupo y Firewall Rule ID. Una regla de red situada por encima de la regla de usuario puede coincidir ya con el tráfico.

Un cambio de grupo no tiene efecto

Buscar en el usuario valores específicos de cuota, Access Time, Traffic Shaping o Remote Access. Estas excepciones pueden sustituir los valores del grupo; para Quota, Access Time y Traffic Shaping también se comprueba la selección efectiva de usuario o grupo en la regla o política afectada. Para Remote Access se aplican los límites específicos de cada método descritos anteriormente. Restablecer la herencia del grupo solo después de comparar el valor con la excepción documentada.

El usuario puede iniciar sesión desde un origen inesperado

Comprobar Sign-in restriction tanto en el usuario como en el grupo. Revisar también el servicio utilizado, Device Access y la regla de red. MFA o una regla de firewall restrictiva no compensan automáticamente una configuración Any node.

View usage permanece vacío

Comprobar que el usuario se reconoce como Live User y que el tráfico coincide con una regla basada en usuarios con Log firewall traffic. Después, revisar el periodo, la asignación de cuotas y el tráfico real de prueba. Reset user accounting no genera logs que faltan ni corrige una regla errónea.

Lista de comprobación operativa

• Live users muestra pilotuser01, la dirección IP de origen prevista y el Client Type esperado.
• El registro de autenticación confirma el inicio de sesión local; Local-Pilot-to-WAN o su Firewall Rule ID coincide con el tráfico de prueba.
• Una contraseña incorrecta, fuente no autorizada y función no autorizada proporcionan las pruebas negativas esperadas.
• Las excepciones específicas del usuario, Simultaneous sign-ins, Sign-in restriction y cualquier fecha de vencimiento están documentadas.
• El registro de MFA y el proceso de recuperación se han probado si se utiliza MFA.
• El estado anterior, el responsable, la desactivación, la desconexión de las sesiones y la posterior eliminación están documentados.

Preguntas frecuentes