Sophos Firewall : AD SSO échoue après la mise à niveau SFOS 22

Après une mise à niveau de SFOS 21.5 ou antérieur vers SFOS 22.0 GA, Active Directory Single Sign-On avec Kerberos et NTLM peut cesser immédiatement de fonctionner. Le pare-feu continue de transmettre le trafic, mais ne reconnaît plus les utilisateurs de domaine concernés. Les règles firewall basées sur les utilisateurs ne s’appliquent alors plus comme prévu.

⚠️ Le nettoyage doit être utilisé uniquement dans l’Advanced Shell et seulement si le chemin de mise à niveau et les symptômes correspondent. Ne pas exécuter la commande de manière générale si le pare-feu utilise déjà MR1 Build 490 ou ultérieur, si le problème existait avant la mise à niveau ou si un cluster HA est concerné.

Si le pare-feu fonctionne encore sous SFOS 22.0 GA et que nasm.log contient une erreur unknown option correspondant au moment de la panne, NASM peut être reconstruit de manière ciblée. Les contrôles suivants évitent d’utiliser le nettoyage pour un problème ordinaire de DNS, SPN ou jonction au domaine.

Sophos a corrigé l’erreur de mise à niveau sous-jacente dans SFOS 22.0 MR1 Build 490. Le nettoyage est donc une réparation ciblée pour le cas de mise à niveau GA décrit ici, pas une solution générale à tous les problèmes AD SSO.

Quand cette procédure s’applique

Cette procédure est prévue pour le cas suivant :

• mise à niveau de SFOS 21.5 ou antérieur vers SFOS 22.0 GA
• AD SSO avec Kerberos et NTLM fonctionnait avant la mise à niveau
• les utilisateurs de domaine ne peuvent ensuite plus s’authentifier via AD SSO
• les règles basées sur l’identité ne reconnaissent plus les utilisateurs
• les autres fonctions du pare-feu et les connexions indépendantes d’AD continuent de fonctionner

Un Test connection réussi sous Authentication > Servers n’exclut pas cette erreur. Le test confirme la connexion au Domain Controller et les identifiants, mais pas le déroulement AD SSO complet.

Si Test connection échoue déjà, la cause probable se trouve dans la joignabilité, DNS, le port, le certificat ou le compte de service. Ces bases sont expliquées dans Connecter Active Directory à Sophos Firewall.

Vérifier l’erreur dans nasm.log

Se connecter au pare-feu par SSH et ouvrir 5. Device Management > 3. Advanced Shell. L’accès SSH à Sophos Firewall est expliqué séparément.

Rechercher ensuite le message documenté par Sophos :

grep "unknown option" /log/nasm.log

Une correspondance confirme l’état défectueux de Samba/NASM. Le timestamp doit coïncider avec la mise à niveau et la panne ; une ancienne entrée ne prouve pas un problème actuel.

Une sortie vide n’exclut pas l’erreur avec certitude. Sans le chemin de mise à niveau correspondant et les symptômes décrits, le nettoyage ne doit toutefois pas être exécuté à l’aveugle. Il faut d’abord vérifier DNS, SPN, la jonction au domaine, Redirection Location, la confiance du navigateur et la configuration Kerberos/NTLM normale.

Nettoyer NASM de manière ciblée

Lors d’un changement de firmware, SFOS recrée les répertoires NASM pour la version de Samba utilisée. Pendant la mise à niveau concernée, cette étape peut rester incomplète. Le nouveau NASM charge alors d’anciens composants Samba incompatibles et AD SSO échoue.

Avant la modification, documenter la version actuelle du firmware, l’heure de la panne et la sortie de nasm.log. Un accès administrateur local ou alternatif doit être disponible si l’authentification devient indisponible pendant l’intervention.

Exécuter dans l’Advanced Shell :

opcode -ds nosync nasm_cleanup

La commande nettoie la structure NASM concernée et la recrée pour Samba 4.22.1. Selon Sophos, aucun redémarrage n’est normalement nécessaire. Aucun message de réussite précis n’est documenté ; il faut donc vérifier le résultat avec une nouvelle connexion AD SSO plutôt qu’avec une seule sortie du shell.

Vérifier AD SSO avec un véritable trafic utilisateur

Après le nettoyage, un nouveau Test connection ne suffit pas. La vérification se fait avec un utilisateur de domaine et une véritable règle basée sur les utilisateurs :

1. Sur un client du domaine, ouvrir une nouvelle connexion navigateur qui utilise AD SSO et une règle firewall basée sur les utilisateurs.
2. Sous Current activities > Live users, vérifier que l’utilisateur du domaine apparaît de nouveau.
3. Sous Log viewer > Authentication, confirmer que Kerberos ou NTLM est utilisé avec succès et qu’aucune nouvelle erreur NASM correspondante n’apparaît.
4. Dans le log firewall, vérifier que l’utilisateur, le groupe et la Firewall Rule ID correspondent à la règle prévue.
5. Tester l’application ou la destination qui n’était pas accessible avant le nettoyage.

Le problème est résolu seulement lorsque l’identité utilisateur et l’application de la règle sont correctes. Si seule une connexion au Captive Portal apparaît de nouveau ou si l’utilisateur reste absent, il faut également vérifier SPN, la résolution DNS, Redirection Location et la confiance du navigateur. Les fichiers d’authentification concernés sont répertoriés sous Services et logs de Sophos Firewall.

Solution durable et alternative sans Advanced Shell

Mettre à niveau vers une version SFOS corrigée

La solution durable est une mise à niveau vers SFOS 22.0 MR1 Build 490 ou ultérieur. Avant un autre changement de firmware, vérifier le chemin de mise à niveau, la sauvegarde, le stockage, HA et le retour arrière avec le contrôle de mise à niveau SFOS 22.

Si le même symptôme apparaît pour la première fois sous MR1 Build 490 ou une version ultérieure, l’erreur de mise à niveau GA décrite ici ne correspond plus clairement. Ne pas répéter le nettoyage : effectuer le diagnostic AD SSO normal et faire appel à Sophos Support si nécessaire.

Si l’Advanced Shell n’est pas disponible

Sophos indique un nouveau changement de firmware comme alternative :

• Si le pare-feu a déjà redémarré sous SFOS 21.5, le redémarrer de nouveau sous SFOS 22.0 GA.
• Si le pare-feu fonctionne sous SFOS 22.0 GA, démarrer d’abord dans le slot de firmware SFOS 21.5 disponible, puis revenir à SFOS 22.0 GA.

Cet aller-retour déclenche de nouveau la création des répertoires NASM. Il entraîne une interruption et n’est pas équivalent à un redémarrage normal. Une sauvegarde actuelle, un slot de firmware disponible et amorçable, un accès console, une fenêtre de maintenance et un retour arrière vérifié sont donc obligatoires. Si ces conditions ne sont pas réunies, il est plus sûr de passer directement à une version corrigée ou de coordonner la procédure avec Sophos Support.

Quand le nettoyage n’est pas la bonne solution

nasm_cleanup n’est pas une commande de réparation générale. Une autre méthode de diagnostic est nécessaire lorsque :

• le pare-feu fonctionne déjà sous SFOS 22.0 MR1 Build 490 ou ultérieur
• le problème existait avant la mise à niveau
• Test connection vers le serveur AD échoue
• seuls certains utilisateurs, groupes ou navigateurs sont concernés
• STAS, Microsoft Entra ID SSO, RADIUS ou une connexion LDAP normale est concerné
• DNS, SPN, la jonction au domaine, les certificats ou la confiance du navigateur ne fonctionnent pas correctement
• le chemin de mise à niveau ou le moment de la panne ne correspond pas à l’erreur décrite
• un cluster HA est concerné et aucune procédure approuvée par Sophos n’existe pour les deux nœuds

Dans ces cas, un nettoyage ne corrige pas une mauvaise configuration et peut masquer la véritable cause. Il faut d’abord identifier précisément le chemin d’authentification concerné. Sophos Support est le bon point d’escalade lorsque le comportement n’est pas clair ou diffère de ce cas.