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.

Para este fallo se documentan dos identificadores distintos: NC-176853 y NC-176039. La propia KBA-000048429 no proporciona ningún identificador NC. Este artículo recoge directamente el estado concreto de la versión: ambos registros señalan SFOS 22.0 MR1 Build 490 como versión corregida; la KBA la denomina SFOS v22.0.1 MR-1. Por tanto, ninguno de los dos identificadores se considera el único canónico. Antes de efectuar cambios, se verifican los datos dinámicos sobre builds autorizadas, la maintenance release actual y la ruta de actualización con el check de actualización a SFOS 22. 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 la señal de confirmación específica de este problema:

grep "unknown option" /log/nasm.log

Esta coincidencia solo confirma el error de actualización descrito si el timestamp corresponde con la actualización y el fallo; una entrada antigua no demuestra un problema actual.

Si el comando no devuelve ninguna salida, falta la señal de confirmación necesaria. El cleanup no debe ejecutarse por sospecha. Primero deben comprobarse DNS, SPN, domain join, Redirection Location, confianza del navegador y la configuración normal de Kerberos/NTLM; si la ruta de actualización y los síntomas siguen coincidiendo, hay que recurrir a Sophos Support.

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.

Sophos identifica el cleanup como la solución preferida para un firewall que actualmente ejecuta SFOS 22.0 GA. Ejecutar en la Advanced Shell:

opcode -ds nosync nasm_cleanup

El comando fuerza el cleanup y la regeneración del entorno NASM de acuerdo con Samba 4.22.1; normalmente no es necesario reiniciar después. Sophos no especifica ningún mensaje de éxito concreto ni un comando para deshacer la operación. Por eso el resultado se comprueba con un nuevo inicio de sesión AD SSO y no con una única respuesta de la shell. Si el resultado es inesperado, no se debe repetir el comando; hay que facilitar a Sophos Support la información registrada antes de la intervención e indicar la referencia KBA-000048429.

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. Abrir Log viewer en la esquina superior derecha, elegir Authentication en el selector de módulos y consultar Log Comp para ver si se usa Kerberos o NTLM. Kerberos authentication initialized successfully y NTLM authentication channel established successfully confirman una inicialización correcta.
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 el log Authentication muestra Cannot initialize Kerberos authentication o Cannot establish NTLM authentication channel, el canal de AD aún no funciona. 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 KBA identifica SFOS v22.0.1 MR-1 como versión corregida; pese a la discrepancia entre los identificadores NC-176853 y NC-176039, ambos registros actuales señalan SFOS 22.0 MR1 Build 490 como destino con la corrección. A fecha de 4 de septiembre de 2026, SFOS 22.0 MR2 Build 546 es la versión 22.0 actual. Antes de efectuar cambios, hay que volver a comprobar este estado dinámico con el check de actualización a SFOS 22. Conviene instalar la maintenance release más reciente autorizada para el modelo y la ruta de actualización propios, en vez de elegir deliberadamente una versión intermedia ya superada. El mismo check también cubre la ruta de actualización, el backup, el almacenamiento, HA y la vía de reversión antes del cambio de firmware.

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

Si Advanced Shell no está disponible, otro cambio de firmware puede volver a crear los directorios NASM:

• 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. En WebAdmin, hay que ir a Backup and firmware > Firmware y elegir Boot firmware image para el slot inactivo. Las dos particiones conservan configuraciones separadas. Mientras se ejecuta SFOS 21.5 está activa la configuración anterior; al volver a la partición 22.0 se activa de nuevo su configuración correspondiente. No se deben realizar cambios de configuración de producción durante el recorrido porque las particiones no los comparten.

Antes de empezar, hay que planificar una ventana de mantenimiento, guardar externamente un backup actual y confirmar que el firmware inactivo sea compatible y esté disponible. El acceso por consola es una precaución recomendable. Después de cada arranque, hay que confirmar en Control Center qué versión está activa. No hay una secuencia específica establecida para los nodos HA; en un clúster HA, cualquiera de las dos soluciones debe coordinarse con Sophos Support. 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; no hay una secuencia específica establecida para los nodos HA

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.