Configurar Synchronized User ID Authentication en Sophos Firewall

Synchronized User ID Authentication vincula el inicio de sesión de Windows de un endpoint administrado con Sophos Firewall. Sophos Endpoint transmite el usuario de dominio mediante Security Heartbeat, el firewall lo valida en Active Directory y después lo muestra 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 documentación actual de Sophos confirma este procedimiento para Windows 10. No describe Server Protection, los usuarios locales de Windows, otros servicios de directorio ni otras versiones de Windows como opciones con el mismo nivel de compatibilidad. No se deben migrar esos sistemas a este procedimiento sin una aprobación o prueba específica.

Synchronized User ID en ocho pasos

1. Elegir como piloto un cliente de dominio Windows 10 con Sophos Endpoint.
2. Comprobar 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 Central 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. Es adecuado cuando un endpoint Windows 10 administrado pertenece normalmente a un único usuario de AD y Sophos Endpoint ya envía un Security Heartbeat al firewall.

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

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 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 Central, Windows, Active Directory y el firewall asignen de forma inequívoca al mismo usuario.

Preparar los requisitos

Comprobar Sophos Central y Security Heartbeat

El firewall debe estar conectado a Sophos Central 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. El registro y la línea base del heartbeat se explican en Conectar Sophos Firewall con Sophos Central.

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

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

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.

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 Central 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, crear una regla limitada para el grupo piloto o utilizar de forma controlada una regla de usuario existente:

• 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

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 Central y en el firewall.
4. Buscar anna.muster y 10.20.30.101 en Current activities > Live users.
5. Confirmar que el usuario, la dirección IP y Client Type corresponden al método esperado.
6. Generar una prueba de tráfico permitida mediante LAN_User_Internet.
7. Comparar en Log Viewer 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.

Delimitar los errores sistemáticamente

El endpoint no aparece con un heartbeat verde

Comprobar primero el registro en Central, 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

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 una validación correcta en AD.

Usuario o grupo incorrecto

Comparar el dominio UPN, el ámbito de búsqueda de AD, el grupo importado, Main Group y los objetos de usuario locales. No eliminar objetos de usuario antes de comprobar las dependencias de VPN, portales, 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 este procedimiento. La ayuda actual de Sophos menciona expresamente Windows 10. No se debe deducir la compatibilidad en producción para otras versiones de Windows o tipos de endpoint desconocidos a partir de un único piloto correcto.

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 Central. 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.

Sophos utiliza este archivo 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. Para la variante persistente, eliminar /content/no_userid de forma controlada y reiniciar access_server. Según Sophos, la variante temporal solo termina con el siguiente reinicio del firewall.
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

• El piloto es un cliente de dominio Windows 10 compatible con Sophos Endpoint.
• El firewall, el endpoint y Security Heartbeat son visibles en Sophos Central.
• 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