Sophos Firewall: AD SSO falla tras actualizar a SFOS 22

Tras actualizar desde SFOS 21.5 o anterior a SFOS 22.0 GA, Active Directory Single Sign-On con Kerberos y NTLM puede fallar de inmediato. El firewall sigue reenviando tráfico, pero deja de reconocer a los usuarios de dominio afectados. Por eso las reglas de firewall basadas en usuarios no coinciden como deberían.

⚠️ El cleanup solo debe utilizarse en la Advanced Shell y cuando coincidan la ruta de actualización y los síntomas. No se debe ejecutar el comando de forma genérica si el firewall ya usa MR1 Build 490 o posterior, el problema existía antes de la actualización o hay un clúster HA afectado.

Si el firewall sigue ejecutando SFOS 22.0 GA y nasm.log contiene un error unknown option del momento del fallo, NASM puede reconstruirse de forma específica. Las siguientes comprobaciones evitan utilizar el cleanup para un problema habitual de DNS, SPN o domain join.

Sophos corrigió el error de actualización subyacente en SFOS 22.0 MR1 Build 490. Por tanto, el cleanup es una reparación específica para el caso de actualización GA descrito aquí, no una solución general para cualquier problema de AD SSO.

Cuándo encaja este procedimiento

Este procedimiento está pensado para el siguiente caso:

• actualización desde SFOS 21.5 o anterior a SFOS 22.0 GA
• AD SSO con Kerberos y NTLM funcionaba antes de la actualización
• después, los usuarios de dominio ya no pueden autenticarse mediante AD SSO
• las reglas basadas en identidad dejan de reconocer a los usuarios
• otras funciones del firewall y los inicios de sesión que no dependen de AD siguen funcionando

Un Test connection correcto en Authentication > Servers no descarta este error. El test confirma la conexión con el domain controller y las credenciales, pero no el flujo completo de AD SSO.

Si ya falla Test connection, la causa probable es la conectividad, DNS, el puerto, el certificado o la cuenta de servicio. Estos fundamentos se explican en Conectar Active Directory con Sophos Firewall.

Revisar el error en nasm.log

Iniciar sesión en el firewall mediante SSH y abrir 5. Device Management > 3. Advanced Shell. El acceso SSH a Sophos Firewall se explica por separado.

Después, buscar el mensaje documentado por Sophos:

grep "unknown option" /log/nasm.log

Una coincidencia confirma el estado defectuoso de Samba/NASM. El timestamp debe corresponder con la actualización y el fallo; una entrada antigua no demuestra un problema actual.

Una salida vacía no descarta el error con certeza. Sin la ruta de actualización adecuada y los síntomas descritos, el cleanup no debe ejecutarse por precaución. Primero hay que revisar DNS, SPN, domain join, Redirection Location, confianza del navegador y la configuración normal de Kerberos/NTLM.

Limpiar NASM de forma específica

Durante un cambio de firmware, SFOS vuelve a crear los directorios NASM para la versión de Samba utilizada. En la actualización afectada, este paso puede quedar incompleto. El nuevo NASM carga entonces componentes Samba antiguos e incompatibles y AD SSO deja de funcionar.

Antes del cambio, se documentan la versión actual del firmware, la hora del fallo y la salida de nasm.log. Debe existir un acceso de administrador local o alternativo por si la autenticación no está disponible durante el trabajo.

Ejecutar en la Advanced Shell:

opcode -ds nosync nasm_cleanup

El comando limpia la estructura NASM afectada y la vuelve a crear para Samba 4.22.1. Según Sophos, normalmente no es necesario reiniciar. No hay un mensaje de éxito concreto documentado; por eso el resultado se comprueba con un nuevo inicio de sesión AD SSO y no con una única respuesta de la shell.

Comprobar AD SSO con tráfico de usuario real

Después del cleanup, repetir Test connection no es suficiente. La comprobación se realiza con un usuario de dominio y una regla realmente basada en usuarios:

1. En un cliente de dominio, abrir una nueva conexión del navegador que utilice AD SSO y una regla de firewall basada en usuarios.
2. En Current activities > Live users, comprobar que el usuario de dominio vuelve a aparecer.
3. En Log viewer > Authentication, confirmar que Kerberos o NTLM se utiliza correctamente y que no aparecen nuevos errores NASM coincidentes.
4. En el log del firewall, comprobar que usuario, grupo y Firewall Rule ID corresponden con la regla prevista.
5. Probar la aplicación o el destino que no estaba disponible antes del cleanup.

El error solo está resuelto cuando son correctos tanto la identidad del usuario como el match de la regla. Si vuelve a aparecer únicamente el inicio de sesión del Captive Portal o el usuario sigue sin mostrarse, también deben revisarse SPN, resolución DNS, Redirection Location y confianza del navegador. Los archivos de autenticación relevantes se enumeran en Servicios y logs de Sophos Firewall.

Solución permanente y alternativa sin Advanced Shell

Actualizar a una versión SFOS corregida

La solución permanente es actualizar a SFOS 22.0 MR1 Build 490 o posterior. Antes de otro cambio de firmware, deben revisarse ruta de actualización, backup, almacenamiento, HA y vía de reversión con el check de actualización a SFOS 22.

Si el mismo síntoma aparece por primera vez en MR1 Build 490 o en una versión posterior, el error de actualización GA descrito aquí ya no encaja claramente. En ese caso no se repite el cleanup: se realiza el diagnóstico normal de AD SSO y se recurre a Sophos Support si es necesario.

Si Advanced Shell no está disponible

Sophos indica como alternativa otro cambio de firmware:

• Si el firewall ya ha vuelto a arrancar en SFOS 21.5, se inicia de nuevo en SFOS 22.0 GA.
• Si el firewall funciona con SFOS 22.0 GA, primero se inicia en el slot de firmware SFOS 21.5 disponible y después se vuelve a SFOS 22.0 GA.

Este recorrido vuelve a iniciar la creación de los directorios NASM. Provoca una interrupción y no equivale a un reinicio normal. Por eso son obligatorios un backup actual, un slot de firmware disponible y arrancable, acceso por consola, una ventana de mantenimiento y una vía de reversión comprobada. Si faltan estos requisitos, es más seguro actualizar directamente a una versión corregida o coordinar el procedimiento con Sophos Support.

Cuándo el cleanup no es la solución adecuada

nasm_cleanup no se utiliza como comando de reparación general. Hace falta otro diagnóstico cuando:

• el firewall ya ejecuta SFOS 22.0 MR1 Build 490 o posterior
• el problema existía antes de la actualización
• falla Test connection con el servidor AD
• solo están afectados usuarios, grupos o navegadores concretos
• están afectados STAS, Microsoft Entra ID SSO, RADIUS o un inicio de sesión LDAP normal
• DNS, SPN, domain join, certificados o confianza del navegador no funcionan correctamente
• la ruta de actualización o el momento del fallo no encajan con el error descrito
• hay un clúster HA afectado y no existe un procedimiento aprobado por Sophos para ambos nodos

En estos casos, un cleanup no corrige una configuración errónea y puede ocultar la causa real. Primero hay que acotar la ruta de autenticación afectada. Sophos Support es el punto de escalado adecuado cuando el comportamiento no está claro o difiere de este caso.