Configurar Synchronized User ID Authentication en Sophos Firewall

Synchronized User ID Authentication vincula el inicio de sesión de un endpoint administrado con Sophos Firewall. Sophos Endpoint transmite la identidad mediante Security Heartbeat. En el procedimiento de AD para SFOS 22, el firewall valida al usuario de dominio mediante Active Directory; la ayuda de SFOS 23 describe además Microsoft Entra ID con resolución de UPN y consulta de grupos. Los usuarios asignados correctamente aparecen en Current activities > Live users.

Este enfoque es adecuado para estaciones de trabajo administradas donde Sophos Endpoint y Security Heartbeat ya funcionan. No requiere un agente de autenticación adicional en el cliente ni en el servidor. Sin embargo, Sophos Endpoint sigue siendo un requisito.

⚠️ La ayuda de SFOS 22 confirma el procedimiento anterior de AD para Windows 10 y excluye otros servicios de directorio. Esta afirmación no se aplica de forma general a SFOS 23: allí se documenta un procedimiento específico de Entra ID. Los usuarios locales y los dispositivos con Server Protection siguen excluidos. La página de SFOS 23 no menciona ninguna versión concreta del sistema operativo; ni esto ni un piloto correcto permiten deducir compatibilidad adicional con otros sistemas operativos.

SFOS 23: identidad de Entra mediante Security Heartbeat

Esta rama describe el inicio de sesión en el endpoint, no el inicio de sesión SSO interactivo en VPN Portal o WebAdmin. La integración de Entra ya debe estar configurada correctamente. La configuración básica común de Entra explica la aplicación, los permisos, el servidor de autenticación y la importación de grupos; el propio inicio de sesión VPN no es un requisito para este piloto de heartbeat. Para el acceso de administrador, se aplica por separado Entra ID para WebAdmin.

Requisitos mínimos y resolución de identidad

Antes del piloto, comprobar estos requisitos:

• El firewall ejecuta la build de SFOS 23 prevista, está conectado a Sophos Central o Sophos Fusion y dispone de un Security Heartbeat operativo. Los datos de licencias que se conservan más abajo proceden expresamente de la ayuda de SFOS 22; no demuestran ningún requisito de licencia nuevo o modificado para SFOS 23. Comprobar por separado los derechos de uso de la versión realmente utilizada.
• Sophos Endpoint 2025.1 o posterior está instalado en el equipo piloto administrado. La ayuda de SFOS 23 exige Endpoint en dispositivos unidos al dominio; esto no permite deducir compatibilidad adicional con cualquier modelo de unión o sistema operativo.
• La cuenta de usuario utiliza la misma dirección de correo electrónico en Sophos Central/Fusion, en el firewall y en el directorio configurado. El usuario de Entra que ha iniciado sesión debe poder asignarse de forma inequívoca.
• Microsoft Entra ID está configurado correctamente como servidor de autenticación en el firewall. En Authentication > Servers, comprobar el servidor de Entra y Test connection; revisar la sincronización horaria, la conectividad, los permisos de la aplicación y la importación de grupos conforme a la configuración básica enlazada.
• Endpoint transmite el UPN válido del usuario de Entra que ha iniciado sesión mediante heartbeat. A partir de Endpoint 2025.1 se transmiten el nombre de inicio de sesión, el nombre de dominio y el UPN; las versiones anteriores no envían el UPN. Sin UPN, el firewall no puede asignar el heartbeat a ningún usuario de Entra. Por tanto, un heartbeat verde por sí solo no basta.

⚠️ No sincronizar a los usuarios de un mismo dominio simultáneamente mediante AD y Entra ID. Los requisitos de Entra excluyen esta combinación. No interpretar una ruta de AD existente como una migración automática: aclarar primero qué directorio es responsable y cuál es la vía de recuperación; detener el piloto si no se ha resuelto una asignación duplicada.

El procedimiento de Entra consta de cinco pasos:

1. El usuario inicia sesión con su cuenta de Entra ID en el dispositivo protegido por Sophos Endpoint.
2. Endpoint envía la información de identidad al firewall mediante Security Heartbeat.
3. El firewall resuelve al usuario de Entra a partir de su UPN. A diferencia de la rama de AD, aquí no se utiliza sAMAccountName como clave de asignación de Entra.
4. El firewall consulta las pertenencias a grupos de Entra y activa al usuario con las políticas de usuario y grupo adecuadas, así como con las políticas correspondientes de Synchronized Security.
5. El usuario aparece en Current activities > Live users. El firewall no utiliza ni comparte contraseñas durante este proceso.

Validar el piloto de Entra y la autorización

Como ejemplos de documentación se utilizan anna.muster@example.com, la IP del cliente 10.20.30.101, el grupo piloto de Entra SFOS-Internet-Users y la regla LAN_User_Internet. Sustituir el UPN, la IP y el grupo por los valores del propio piloto. Limitar deliberadamente el grupo a los usuarios de prueba necesarios; el nombre por sí solo no demuestra pertenencia ni autorización.

1. Documentar el estado previo de la asignación de directorio, los objetos de usuario y grupo, las reglas y los nodos HA, así como un acceso administrativo independiente. Utilizar un cliente de prueba autorizado y cuentas de prueba; no bloquear ni eliminar cuentas de producción.
2. Importar el grupo de Entra necesario conforme a la configuración básica y seleccionarlo en una regla limitada y con registro en Rules and policies > Firewall rules, mediante Match known users y Users or groups. Limitar el origen, el destino y los servicios al piloto; la regla piloto descrita más abajo muestra los campos.
3. Cerrar por completo la sesión en el equipo piloto y volver a iniciarla con la cuenta de Entra. Comprobar conjuntamente el heartbeat y Current activities > Live users: el usuario esperado, la IP del cliente y Client Type: Heartbeat deben corresponder al inicio de sesión de prueba. Documentar la identidad que se muestra realmente, sin dar por supuesto un nombre para mostrar concreto.
4. Generar un nuevo flujo de prueba permitido y comparar en Log viewer el usuario, el origen, el destino, el servicio, la acción, la hora y Firewall Rule ID. Solo el flujo correcto demuestra el efecto de la regla; una entrada en Live users por sí sola no demuestra la autorización por grupo.
5. Comprobar la misma ruta de destino con un usuario de prueba independiente que no pertenezca al grupo piloto. Este usuario no debe obtener acceso mediante la regla del grupo piloto. Puede seguir aplicándose otra regla válida: documentar su Rule ID en lugar de esperar un bloqueo total generalizado.
6. Validar como casos de prueba negativos un UPN ausente o inválido, una cuenta de prueba de Entra inexistente o inactiva y la falta de conectividad del firewall con Entra. Provocar fallos únicamente en un entorno de prueba aislado y autorizado, no mediante bloqueos de todo el tenant o bloqueos globales de red. Si no se dispone de ese entorno, documentar los casos de prueba como pendientes, no como probados correctamente. Si falta el UPN, no esperar una asignación de Entra; para los errores de cuenta y conectividad, no garantizar ningún mensaje de error concreto ni el cierre inmediato de las sesiones existentes.
7. Probar de forma controlada la pérdida del heartbeat y la suspensión/reactivación. Si falta el heartbeat, se cierra la sesión del usuario sincronizado; otros métodos de autenticación pueden seguir aplicándose y el tráfico puede interrumpirse hasta el siguiente inicio de sesión. La secuencia de comprobación del heartbeat que figura a continuación también se aplica aquí.

Falta el usuario de Entra o tiene un grupo incorrecto

Si el heartbeat está verde pero no aparece la identidad adecuada, comprobar primero la versión de Endpoint y el UPN comunicado realmente. Después, comprobar si la cuenta de Entra existe y está activa, si los servicios del firewall pueden conectarse a Entra y si la configuración de Entra se ha completado correctamente. Volver a ejecutar Test connection en Authentication > Servers. Una prueba de conexión correcta por sí sola no demuestra ni el UPN del endpoint ni la autorización por grupo.

Si la identidad es visible, pero el grupo o la regla son incorrectos, comparar la pertenencia en Entra, el grupo importado en el firewall, la asignación del usuario y el orden de las reglas. Conservar los datos del flujo afectado, con su Rule ID y hora. No ampliar reglas, eliminar objetos de usuario ni reiniciar servicios por precaución. Para escalar la incidencia, conservar la build de SFOS, la versión de Endpoint, el UPN anonimizado, el estado del heartbeat, la IP del cliente, el intervalo de tiempo y el nodo HA que procesa el tráfico, junto con los registros mencionados más abajo.

HA y vía de recuperación para el piloto de Entra

La ayuda de SFOS 23 también describe Synchronized User ID como activo de forma predeterminada y exige activarlo o desactivarlo en ambos dispositivos HA. El cambio de estado no se guarda en la copia de seguridad. Los comandos de shell que se conservan más abajo también están documentados en SFOS 23; cambian el estado de toda la función, no solo de Entra. Por tanto, ese reinicio del servicio no es una reversión inocua del piloto.

Probar el failover únicamente en una ventana de mantenimiento autorizada y con acceso administrativo independiente. En el nodo que procese el tráfico después, volver a validar el heartbeat, un nuevo inicio de sesión de Entra, Live users, la regla de grupo y un nuevo flujo de prueba. No dar por supuesta una transferencia sin interrupciones del estado de los usuarios o las sesiones; las correcciones de SFOS 22 mencionadas más abajo no constituyen una nueva garantía de failover para SFOS 23.

Para la vía de recuperación, restaurar primero la regla piloto y las asignaciones piloto a su estado previo documentado y comprobar la ruta de autenticación anterior con un nuevo inicio de sesión y tráfico real. No eliminar ni desactivar globalmente la aplicación de Entra, el servidor, los permisos o los grupos utilizados conjuntamente por VPN, Portal o WebAdmin como parte de la limpieza de la prueba. Si también se modificó el estado global de Synchronized User ID durante la ventana de mantenimiento, restablecer expresamente el estado previsto en ambos nodos y comprobarlo por separado después de una restauración. Volver a activar una vía de recuperación mediante AD solo cuando la sincronización de Entra del mismo dominio se haya terminado de forma controlada.

Los siguientes pasos y ejemplos de AD se conservan como una ruta independiente y anterior de SFOS 22. La resolución de identidad de AD también se describe en la ayuda de SFOS 23, pero allí no sustituye la comprobación de Entra.

SFOS 22 con AD: Synchronized User ID en ocho pasos

1. Elegir como piloto un cliente de dominio Windows 10 con Sophos Endpoint.
2. Comprobar Sophos Fusion (antes Sophos Central), Security Heartbeat y la licencia del firewall.
3. Conectar Active Directory como servidor de autenticación del firewall.
4. Comparar el dominio UPN, sAMAccountName, el correo electrónico y el perfil de usuario entre AD, Sophos Fusion y el firewall.
5. Preparar una regla de usuario limitada y con registro para un grupo piloto.
6. Iniciar una nueva sesión de Windows en el piloto y confirmar un heartbeat verde.
7. Comprobar el usuario, la dirección IP y Client Type en Current activities > Live users, además del tráfico real en Log Viewer.
8. Probar la pérdida del heartbeat, el comportamiento de HA y una vía de recuperación controlada antes de añadir más endpoints.

Cuándo conviene Synchronized User ID

Synchronized User ID no sustituye de forma general a todos los métodos de autenticación de Sophos. La ruta de AD de SFOS 22 que se conserva es adecuada cuando un endpoint Windows 10 administrado pertenece normalmente a un único usuario de AD y Sophos Endpoint ya envía un Security Heartbeat. Para los usuarios de Entra en SFOS 23, se aplican los requisitos y la validación de su propia rama, descrita más arriba.

Otros modelos operativos requieren otros métodos:

• STAS en Sophos Firewall asigna los inicios de sesión de Windows procedentes de los controladores de dominio, STA Agent y Collector a una IP de cliente.
• SATC para Remote Desktop Services diferencia varias sesiones detrás de una misma IP de RDS o Citrix.
• Per-Connection AD SSO diferencia las conexiones HTTP y HTTPS de varios usuarios mediante Direct Web Proxy.
• Captive Portal o Client Authentication Agent son adecuados cuando se necesita un inicio de sesión interactivo.

No se debe forzar un escenario de servidor o terminal server con Synchronized User ID. Sophos indica expresamente que Server Protection no es compatible. Si varios usuarios comparten la misma IP o hay que asignar por sesión conexiones que no sean web, SATC es más apropiado.

Si Synchronized User ID y STAS están configurados al mismo tiempo, Sophos indica que el servidor de autenticación utiliza el mecanismo cuya solicitud de inicio de sesión llegue primero. Esta coexistencia no se debe tratar como una prioridad fija. Hay que delimitar inequívocamente el piloto y comprobar Client Type en cada validación.

Cómo funciona la asignación de AD

El procedimiento consta de cuatro niveles separados:

1. El usuario inicia sesión en el cliente de dominio Windows.
2. Sophos Endpoint transmite el usuario de dominio al firewall mediante Security Heartbeat.
3. El firewall obtiene el dominio del UPN y el nombre de usuario de sAMAccountName.
4. El firewall valida el usuario mediante el servidor de Active Directory correspondiente y lo activa para las reglas basadas en usuarios.

La función no autentica usuarios locales de Windows ni sustituye una conexión con AD. Si el dominio UPN, el servidor de directorio o el perfil de usuario no coinciden, un endpoint verde puede seguir sin una identidad de usuario utilizable.

Sophos Firewall no comparte ni utiliza información de contraseñas en este proceso. El heartbeat transporta los datos de dominio y usuario necesarios para la asignación, mientras que la validación se realiza en el servidor de AD configurado.

Ejemplo de AD y valores sustituibles

El procedimiento utiliza estos valores de documentación:

• Firewall: fw01.example.com
• Dominio de AD y sufijo UPN: example.com
• Cliente Windows: WS-101
• IP del cliente: 10.20.30.101
• Nombre de usuario: anna.muster
• UPN: anna.muster@example.com
• sAMAccountName: anna.muster
• Grupo de AD: SFOS-Internet-Users
• Regla piloto: LAN_User_Internet

example.com, WS-101, 10.20.30.101, el usuario y el grupo son ejemplos y deben sustituirse por los valores reales. Lo decisivo no es el nombre del objeto, sino que Sophos Fusion, Windows, Active Directory y el firewall asignen de forma inequívoca al mismo usuario.

Preparar los requisitos

Comprobar Sophos Fusion y Security Heartbeat

El firewall debe estar conectado a Sophos Fusion y disponer de una suscripción válida de Network Protection. El piloto necesita Sophos Central Endpoint Protection con una licencia de prueba o completa. Estos requisitos de licencia proceden de la ayuda de SFOS 22 sobre Security Heartbeat; el registro y la línea base del heartbeat se explican en Conectar Sophos Firewall con Sophos Fusion.

En System > Sophos Fusion, el registro y Security Heartbeat deben estar activos. El piloto debe aparecer con un estado plausible en Control Center y Sophos Fusion. Primero se establece esta línea base y después se comprueba la asignación de identidad.

Según la ayuda de SFOS 22 sobre Security Heartbeat, el endpoint y el firewall intercambian datos de heartbeat mediante una conexión TLS cifrada con 52.5.76.173 por TCP 8347. El estado verde significa que la protección de Sophos funciona correctamente y que no se ha detectado malware activo o inactivo ni PUA. Todavía no demuestra que AD haya validado al usuario. Si hay problemas de conexión, se deben comprobar por separado el transporte, el tenant de Fusion y el certificado del endpoint, y después la asignación del usuario.

Synchronized User ID está activo de forma predeterminada. Por tanto, no hay un interruptor normal en WebAdmin que deba activarse primero para el piloto. Los comandos de shell que se describen más adelante solo sirven para desactivar o reactivar la función de forma controlada.

Comparar Active Directory y los atributos de usuario (ruta de AD)

En Authentication > Servers debe existir un servidor de Active Directory adecuado y accesible. Conectar Active Directory con Sophos Firewall explica LDAPS, la base de búsqueda, la importación de grupos y el orden de los servidores.

Después, ir a Authentication > Services > Firewall authentication methods y mover el servidor de AD a Selected authentication server. La ayuda de SFOS 22 sobre Authentication Services confirma que debe seleccionarse al menos un servidor; si hay varios, el firewall los procesa en el orden mostrado. Añadir el servidor únicamente en Servers no basta para la autenticación del firewall.

Como mínimo, estos valores deben coincidir para el piloto:

• El dominio del UPN coincide con el dominio del servidor de AD utilizado por el firewall.
• sAMAccountName es único en Active Directory y el firewall puede encontrarlo.
• El perfil de usuario y la dirección de correo electrónico coinciden entre AD, Sophos Fusion y el registro de usuario local del firewall.
• El grupo de AD necesario está importado y asignado al perfil de usuario correcto del firewall.

Un sufijo UPN distinto, valores sAMAccountName duplicados en ámbitos de búsqueda inadecuados o un servidor de AD incorrecto son señales para detenerse. No se deben compensar con una regla de usuario más amplia.

Preparar la regla piloto

En Rules and policies > Firewall rules, hacer clic en Add firewall rule > New firewall rule y crear una regla limitada para el grupo piloto, o utilizar de forma controlada una regla de usuario existente. En la sección de identidad de usuario, activar Match known users antes de seleccionar Users or groups:

• Source zones: zona real del cliente
• Source networks and devices: red piloto o un rango de origen más limitado
• Users or groups: SFOS-Internet-Users
• Destination zones: solo la ruta de destino necesaria
• Services: solo los servicios necesarios para la prueba
• Log firewall traffic: activado

El orden de las reglas, el registro y la prueba negativa son más importantes que una regla de permiso amplia. Crear correctamente reglas en Sophos Firewall explica la configuración.

Iniciar sesión y validar el piloto de AD

1. Cerrar por completo la sesión del usuario existente en el cliente piloto.
2. Iniciar una nueva sesión de Windows como anna.muster@example.com.
3. Comprobar un heartbeat verde en Sophos Fusion y en el firewall.
4. Buscar anna.muster y 10.20.30.101 en Current activities > Live users.
5. Confirmar que se muestran el usuario, la dirección IP y Client Type: Heartbeat.
6. Generar una prueba de tráfico permitida mediante LAN_User_Internet.
7. Abrir Log viewer arriba a la derecha, seleccionar el módulo del firewall y comparar el nombre de usuario, el origen, el destino, el servicio, Firewall Rule ID, la acción y la hora.
8. Realizar una prueba negativa con un usuario ajeno al grupo piloto.

Una entrada en Live users solo demuestra la asignación de identidad. Solo el flujo de prueba registrado demuestra que también se aplica la regla de usuario correcta. Si el registro de tráfico solo muestra la dirección IP o el flujo alcanza otra Rule ID, no se debe ampliar la regla. Hay que comprobar la asignación y el orden.

Probar deliberadamente la pérdida del heartbeat

Si falta Security Heartbeat o se pierde durante una transición de suspensión y reactivación, el firewall cierra la sesión del usuario detectado mediante Synchronized User ID. Otros métodos de autenticación configurados pueden seguir aplicándose, pero el tráfico basado en usuarios puede interrumpirse hasta el siguiente inicio de sesión.

Para una prueba controlada:

1. Documentar primero el usuario activo, la IP, el estado del heartbeat y la regla.
2. Poner el piloto en suspensión y reactivarlo.
3. Volver a comprobar el estado del heartbeat y Live users.
4. Generar una nueva prueba de tráfico y confirmar el usuario y la Rule ID utilizados realmente.
5. Si el resultado difiere, comprobar el endpoint, la ruta y los registros en vez de desactivar globalmente Synchronized User ID por precaución.

Un Missing Heartbeat no significa automáticamente malware. Analizar sistemáticamente los avisos Missing Heartbeat explica todo el proceso de diagnóstico.

Interpretar las notas de versión de SFOS 22 y las limitaciones conocidas

La validación debe tener en cuenta el Maintenance Release instalado, no solo «SFOS 22». Este artículo actualizado sobre Synchronized User ID documenta directamente las dos afirmaciones NC concretas. La comprobación previa a la actualización a SFOS 22 solo se ocupa aquí de verificar la versión y la build, la ruta de actualización aprobada y la preparación del cambio. Las correcciones del producto son: MR1 Build 490 corrige el retraso del acceso a Internet después de un failover de HA activado manualmente con autenticación por heartbeat (NC-165361); MR2 Build 546 corrige avisos Missing Heartbeat falsos cuando dos endpoints comparten la misma estación de acoplamiento o interfaz USB (NC-176012). Si alguno de estos síntomas aparece en una build 22.0 anterior, primero se debe registrar la build exacta y evaluar una ruta de actualización aprobada.

El runbook para analizar los avisos Missing Heartbeat también trata NC-147863: con split tunneling de SSL VPN hacia un firewall externo, un nuevo adaptador VPN puede interrumpir la conexión heartbeat. El usuario pierde entonces la autenticación por heartbeat y puede entrar en un bucle de conexión y desconexión. Si el piloto incluye este escenario, se debe probar de forma específica. Como solución alternativa, Sophos indica desactivar Match known users en la regla VPN del firewall local o utilizar Captive Portal para la autenticación. Primero se debe limitar el cambio a la regla VPN afectada y documentar su efecto y la reversión.

Delimitar los errores sistemáticamente

El endpoint no aparece con un heartbeat verde

Comprobar primero el registro en Fusion, la licencia del endpoint, la licencia Network Protection, la asociación del firewall, DNS, la hora y la ruta de red. Sin un Security Heartbeat operativo, Synchronized User ID no puede transmitir una identidad.

El usuario no aparece en Live users

Para la ruta de AD, comprobar conjuntamente el inicio de sesión de Windows, el UPN, sAMAccountName, el servidor de AD, el ámbito de búsqueda y el perfil de usuario. Un heartbeat verde confirma la conexión del endpoint, no automáticamente una validación correcta en AD. En SFOS 23, para los usuarios de Entra, utilizar en su lugar las comprobaciones de UPN, cuenta y conectividad de la rama de Entra.

Usuario o grupo incorrecto

Para AD, comparar el dominio UPN, el ámbito de búsqueda de AD, el grupo importado, Main Group y los objetos de usuario locales. Para Entra en SFOS 23, se aplican además la pertenencia en Entra y la asignación de UPN descritas en su propia rama. No eliminar objetos de usuario antes de comprobar las dependencias de VPN, Portal, reglas, cuotas e informes.

El usuario es visible, pero la regla no se aplica

Comprobar la zona y la red de origen, el usuario o grupo, el servicio, el destino y el orden de las reglas. En Log Viewer, el flujo real debe mostrar la Firewall Rule ID esperada. Una identidad visible no confirma por sí sola la autorización.

Servidor o versión de Windows no confirmada

Server Protection no es compatible con ninguna de las dos rutas. La ayuda de SFOS 22 menciona expresamente Windows 10 para AD; la página de SFOS 23 no establece ninguna versión concreta del sistema operativo. Para otros sistemas operativos, modelos de unión o tipos de endpoint desconocidos, no deducir compatibilidad en producción a partir de la disponibilidad de documentación o del comportamiento de un único piloto.

Leer los registros relevantes

Estas comprobaciones de solo lectura resultan útiles en Advanced Shell:

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log muestra eventos del heartbeat, access_server.log ayuda con la autenticación y autorización, y hbtrust.log con la relación de confianza con Sophos Fusion. Un único registro no constituye una prueba completa. Se deben conservar conjuntamente el intervalo de tiempo, el usuario, el endpoint, la IP, la Rule ID y el nodo HA afectado. Archivos de registro y servicios de Sophos Firewall explica más rutas de registros.

Si sigue sin estar claro si falla el directorio, el método, el registro de usuario local o la regla, Analizar sistemáticamente los errores de autenticación ofrece una secuencia de diagnóstico común a todos los métodos.

Desactivar la función de forma controlada

⚠️ Los siguientes comandos cambian el estado de autenticación y reinician access_server. Primero se deben documentar los usuarios activos, las reglas afectadas, un método de acceso alternativo y la vía de recuperación. En HA, ambos nodos deben tratarse de forma consciente.

Las instrucciones oficiales de SFOS 22 y SFOS 23 indican estos comandos para una desactivación persistente:

touch /content/no_userid
service access_server:restart -ds nosync

Esta variante desactiva la función solo hasta el siguiente reinicio del firewall:

touch /tmp/no_userid
service access_server:restart -ds nosync

Para volver a activar la función, se elimina el archivo persistente y se reinicia el servicio:

rm /content/no_userid
service access_server:restart -ds nosync

Después de cada cambio se deben comprobar un nuevo inicio de sesión de Windows, Live users, el tráfico real y los registros. El estado desactivado no se guarda en las copias de seguridad de configuración. Tras una restauración, hay que volver a comprobar el estado deseado y establecerlo en ambos nodos HA si es necesario.

HA, copias de seguridad y operación

En un clúster HA, Synchronized User ID se activa o desactiva en ambos dispositivos. Cada nodo solo almacena los registros del tráfico y los eventos que procesa. Para una incidencia, se debe revisar el nodo que estaba activo o procesaba el tráfico en ese momento.

Una prueba controlada de HA requiere un nuevo inicio de sesión de Windows y un nuevo flujo de tráfico. No se debe suponer que el estado del usuario o las sesiones activas continúan sin interrupción. Después del failover, hay que volver a validar al menos el heartbeat, Live users, la regla de usuario y los registros.

El estado de /content/no_userid no se incluye en una copia de seguridad. Esta excepción debe constar expresamente en la documentación operativa, las pruebas de restauración y el procedimiento de RMA.

Reversión

1. Documentar el estado actual del heartbeat, el usuario, la regla y HA.
2. Desactivar la regla piloto o restaurar su estado anterior documentado.
3. Solo si se modificó el estado global de la función durante la prueba, restaurar de forma controlada el estado previo documentado. Para una reactivación prevista después de una desactivación persistente, eliminar /content/no_userid y reiniciar access_server; no activar indiscriminadamente una función que antes estaba desactivada. Según Sophos, la variante temporal termina con el siguiente reinicio del firewall. No provocar un reinicio únicamente para limpiar la prueba fuera de una ventana de mantenimiento autorizada.
4. Establecer el mismo estado previsto en ambos nodos HA.
5. Iniciar una nueva sesión de Windows en el piloto y comprobar el heartbeat y Live users.
6. Volver a probar la regla de usuario y la ruta de autenticación alternativa con tráfico real.
7. Solo entonces eliminar los objetos de prueba temporales o las asignaciones piloto.

Lista de comprobación para la ruta de AD de SFOS 22

• El piloto es un cliente de dominio Windows 10 compatible con Sophos Endpoint.
• El firewall, el endpoint y Security Heartbeat son visibles en Sophos Fusion.
• Las licencias Network Protection y del endpoint son válidas.
• El servidor de AD, el dominio UPN, sAMAccountName, el correo electrónico y el perfil de usuario coinciden.
• El grupo piloto está importado y la regla de usuario es limitada y tiene registro.
• Live users muestra el usuario esperado y la IP de cliente correcta.
• El tráfico real alcanza la Firewall Rule ID esperada.
• La pérdida del heartbeat y la suspensión/reactivación se probaron de forma controlada.
• Los nodos HA, los registros, el límite de restauración y la vía de recuperación están documentados.
• Synchronized User ID no se ha extendido indebidamente como sustituto de SATC, STAS u otros servicios de directorio.

Preguntas frecuentes