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.

Deux identifiants différents sont documentés pour cette défaillance : NC-176853 et NC-176039. La KBA-000048429 elle-même ne donne aucun identifiant NC. Cet article consigne directement l’état concret de la version : les deux registres indiquent SFOS 22.0 MR1 Build 490 comme version corrigée ; la KBA la nomme SFOS v22.0.1 MR-1. Aucun des deux identifiants n’est donc présenté comme la référence unique. Avant toute modification, vérifier les données dynamiques sur les builds autorisées, la maintenance release actuelle et le chemin de mise à niveau avec le contrôle de mise à niveau SFOS 22. Le nettoyage est 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 signal de confirmation propre à ce problème :

grep "unknown option" /log/nasm.log

Cette correspondance ne confirme l’erreur de mise à niveau décrite que si son timestamp coïncide avec la mise à niveau et la panne ; une ancienne entrée ne prouve pas un problème actuel.

Si la commande ne renvoie rien, le signal de confirmation requis est absent. Ne pas lancer le nettoyage par simple supposition. Vérifier d’abord DNS, SPN, la jonction au domaine, Redirection Location, la confiance du navigateur et la configuration Kerberos/NTLM normale ; si le chemin de mise à niveau et les symptômes correspondent toujours, faire appel à Sophos Support.

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.

Sophos présente le nettoyage comme la solution privilégiée pour un pare-feu qui exécute actuellement SFOS 22.0 GA. Exécuter dans l’Advanced Shell :

opcode -ds nosync nasm_cleanup

La commande force le nettoyage et la régénération de l’environnement NASM conformément à Samba 4.22.1 ; aucun redémarrage n’est normalement nécessaire ensuite. Sophos ne précise ni message de réussite particulier ni commande d’annulation. Il faut donc vérifier le résultat avec une nouvelle connexion AD SSO plutôt qu’avec une seule sortie du shell. Si le résultat est inattendu, ne pas répéter la commande et transmettre à Sophos Support les informations relevées avant l’intervention en mentionnant la KBA-000048429.

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. Ouvrir Log viewer en haut à droite, choisir Authentication dans le sélecteur de module et consulter Log Comp pour savoir si Kerberos ou NTLM est utilisé. Kerberos authentication initialized successfully et NTLM authentication channel established successfully signalent une initialisation réussie.
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 le log Authentication affiche au contraire Cannot initialize Kerberos authentication ou Cannot establish NTLM authentication channel, le canal AD n’est pas encore opérationnel. 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 KBA désigne SFOS v22.0.1 MR-1 comme version corrigée ; malgré l’écart entre les identifiants NC-176853 et NC-176039, les deux registres actuels indiquent SFOS 22.0 MR1 Build 490 comme destination corrective. Au 4 septembre 2026, SFOS 22.0 MR2 Build 546 est la version 22.0 actuelle. Avant toute modification, revérifier cet état dynamique avec le contrôle de mise à niveau SFOS 22. Il convient d’installer la dernière maintenance release autorisée pour le modèle et le chemin de mise à niveau concernés, plutôt que de viser délibérément une version intermédiaire désormais dépassée. Ce même contrôle couvre aussi le chemin de mise à niveau, la sauvegarde, le stockage, HA et le retour arrière avant le changement de firmware.

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

Si l’Advanced Shell n’est pas disponible, un nouveau changement de firmware peut recréer les répertoires NASM :

• 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. Dans WebAdmin, ouvrir Backup and firmware > Firmware, puis choisir Boot firmware image pour le slot inactif. Les deux partitions conservent des configurations distinctes. L’ancienne configuration est active sous SFOS 21.5 ; au retour sur la partition 22.0, la configuration correspondante redevient active. Ne pas modifier la configuration de production pendant ce détour, car les partitions ne partagent pas ces changements.

Avant de commencer, planifier une fenêtre de maintenance, conserver une sauvegarde actuelle hors du pare-feu et vérifier que le firmware inactif est compatible et disponible. Un accès console constitue une précaution utile. Après chaque démarrage, contrôler la version active dans le Control Center. Aucune séquence propre aux nœuds HA n’est définie ; pour un cluster HA, coordonner l’une ou l’autre solution avec Sophos Support. 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é ; aucune séquence propre aux nœuds HA n’est définie

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.