Configurer Synchronized User ID Authentication sur Sophos Firewall

Synchronized User ID Authentication relie la connexion d’un endpoint administré à Sophos Firewall. Sophos Endpoint transmet l’identité via Security Heartbeat. Dans le processus AD pour SFOS 22, le pare-feu valide l’utilisateur du domaine via Active Directory ; l’aide SFOS 23 décrit également Microsoft Entra ID avec résolution de l’UPN et interrogation des groupes. Les utilisateurs correctement associés apparaissent sous Current activities > Live users.

Cette approche convient aux postes de travail administrés sur lesquels Sophos Endpoint et Security Heartbeat fonctionnent déjà. Elle ne nécessite aucun agent d’authentification supplémentaire sur le client ou le serveur. Sophos Endpoint reste toutefois indispensable.

⚠️ L’aide SFOS 22 confirme l’ancien processus AD pour Windows 10 et exclut les autres services d’annuaire. Cette affirmation ne s’applique pas de manière générale à SFOS 23 : un processus Entra ID distinct y est documenté. Les utilisateurs locaux et les appareils équipés de Server Protection restent exclus. La page SFOS 23 ne précise aucune version de système d’exploitation ; ne pas en déduire, ni déduire d’un pilote concluant, une prise en charge supplémentaire de systèmes d’exploitation.

SFOS 23 : identité Entra via Security Heartbeat

Cette branche décrit la connexion sur l’endpoint, et non la connexion SSO interactive au VPN Portal ou à WebAdmin. L’intégration Entra doit déjà être correctement configurée. La configuration de base commune d’Entra explique l’application, les autorisations, le serveur d’authentification et l’importation des groupes ; la connexion VPN elle-même n’est pas un prérequis pour ce pilote heartbeat. Pour l’accès administrateur, consulter séparément Entra ID pour WebAdmin.

Prérequis minimaux et résolution de l’identité

Vérifier ces prérequis avant le pilote :

• Le pare-feu utilise le build SFOS 23 prévu, est connecté à Sophos Central ou Sophos Fusion et dispose d’un Security Heartbeat fonctionnel. Les indications de licence conservées ci-dessous proviennent explicitement de l’aide SFOS 22 ; elles ne démontrent aucune exigence de licence nouvelle ou modifiée pour SFOS 23. Vérifier séparément les droits d’utilisation pour la version effectivement déployée.
• Sophos Endpoint 2025.1 ou version ultérieure est installé sur l’endpoint pilote administré. L’aide SFOS 23 exige Endpoint sur des appareils joints à un domaine ; ne pas en déduire une prise en charge supplémentaire de modèles de jonction ou de systèmes d’exploitation quelconques.
• Le compte utilisateur utilise la même adresse e-mail dans Sophos Central/Fusion, sur le pare-feu et dans l’annuaire configuré. L’utilisateur Entra connecté doit pouvoir être associé sans ambiguïté.
• Microsoft Entra ID est correctement configuré comme serveur d’authentification sur le pare-feu. Sous Authentication > Servers, vérifier le serveur Entra et Test connection ; contrôler la synchronisation de l’heure, l’accessibilité, les autorisations de l’application et l’importation des groupes conformément à la configuration de base liée.
• Endpoint transmet via heartbeat l’UPN valide de l’utilisateur Entra connecté. À partir d’Endpoint 2025.1, le nom de connexion, le nom de domaine et l’UPN sont transmis ; les versions antérieures n’envoient pas d’UPN. Sans UPN, le pare-feu ne peut associer le heartbeat à aucun utilisateur Entra. Un heartbeat vert ne suffit donc pas à lui seul.

⚠️ Ne pas synchroniser simultanément les utilisateurs d’un même domaine via AD et Entra ID. Les prérequis Entra excluent cette combinaison. Ne pas considérer un chemin AD existant comme une migration automatique : clarifier d’abord l’annuaire responsable et le retour arrière ; arrêter le pilote si une double association reste non résolue.

Le processus Entra comporte cinq étapes :

1. L’utilisateur se connecte avec son compte Entra ID à l’appareil protégé par Sophos Endpoint.
2. Endpoint envoie les informations d’identité au pare-feu via Security Heartbeat.
3. Le pare-feu résout l’utilisateur Entra à partir de son UPN. Contrairement à la branche AD, sAMAccountName ne sert pas ici de clé d’association Entra.
4. Le pare-feu récupère les appartenances aux groupes Entra et active l’utilisateur avec les politiques utilisateur et de groupe appropriées, ainsi que les politiques Synchronized Security correspondantes.
5. L’utilisateur apparaît sous Current activities > Live users. Le pare-feu n’utilise ni ne partage de mots de passe dans ce processus.

Valider le pilote Entra et l’autorisation

Les exemples de documentation sont anna.muster@example.com, l’IP client 10.20.30.101, le groupe pilote Entra SFOS-Internet-Users et la règle LAN_User_Internet. Remplacer l’UPN, l’IP et le groupe par les valeurs de votre propre pilote. Limiter délibérément le groupe aux utilisateurs de test nécessaires ; son nom seul ne prouve ni l’appartenance ni l’autorisation.

1. Documenter l’état initial de l’association à l’annuaire, des objets utilisateur et de groupe, des règles et des nœuds HA, ainsi qu’un accès administrateur indépendant. Utiliser un client de test approuvé et des comptes de test ; ne pas bloquer ni supprimer de comptes de production.
2. Importer le groupe Entra nécessaire conformément à la configuration de base et le sélectionner dans une règle strictement limitée et journalisée sous Rules and policies > Firewall rules, avec Match known users et Users or groups. Limiter la source, la destination et les services au pilote ; la règle pilote décrite plus bas présente les champs.
3. Fermer complètement la session sur le pilote et ouvrir une nouvelle session avec le compte Entra. Vérifier ensemble le heartbeat et Current activities > Live users : l’utilisateur attendu, l’IP client et Client Type: Heartbeat doivent correspondre à la connexion de test. Documenter l’identité réellement affichée sans présumer d’un nom d’affichage particulier.
4. Générer un nouveau flux de test autorisé et comparer dans Log viewer l’utilisateur, la source, la destination, le service, l’action, l’heure et Firewall Rule ID. Seul le bon flux prouve l’effet de la règle ; une entrée dans Live users ne prouve pas à elle seule l’autorisation par groupe.
5. Vérifier le même chemin de destination avec un compte de test distinct, extérieur au groupe pilote. Celui-ci ne doit pas être autorisé par la règle du groupe pilote. Une autre règle légitime peut toujours s’appliquer : documenter sa Rule ID plutôt que d’attendre un blocage global.
6. Valider comme cas de test négatifs un UPN absent ou invalide, un compte de test Entra inexistant ou inactif et une absence de connectivité du pare-feu vers Entra. Ne provoquer des perturbations que dans un environnement de test isolé et approuvé, et non par des blocages à l’échelle du tenant ou du réseau entier. Sans un tel environnement, documenter ces cas comme restant à vérifier, et non comme testés avec succès. En l’absence d’UPN, ne pas attendre d’association Entra ; pour les erreurs de compte ou de connectivité, ne promettre aucun message d’erreur précis ni aucune déconnexion immédiate des sessions existantes.
7. Tester de manière contrôlée la perte du heartbeat et la mise en veille ou reprise. En l’absence de heartbeat, l’utilisateur synchronisé est déconnecté ; d’autres méthodes d’authentification peuvent continuer à s’appliquer et le trafic peut être interrompu jusqu’à la prochaine connexion. La séquence de vérification du heartbeat qui suit s’applique également ici.

L’utilisateur Entra est absent ou appartient au mauvais groupe

Si le heartbeat est vert mais qu’aucune identité correspondante n’apparaît, vérifier d’abord la version d’Endpoint et l’UPN réellement transmis. Contrôler ensuite que le compte Entra existe et est actif, que les services du pare-feu peuvent joindre Entra et que la configuration Entra a été menée à bien. Sous Authentication > Servers, exécuter à nouveau Test connection. Un test de connexion réussi ne prouve à lui seul ni l’UPN de l’endpoint ni l’autorisation par groupe.

Si l’identité est visible mais que le groupe ou la règle est incorrect, comparer l’appartenance Entra, le groupe importé sur le pare-feu, l’association utilisateur et l’ordre des règles. Conserver les informations du flux concerné avec la Rule ID et l’heure. Ne pas élargir les règles, supprimer des objets utilisateur ni redémarrer des services par précaution. Pour une escalade, conserver le build SFOS, la version d’Endpoint, l’UPN anonymisé, l’état du heartbeat, l’IP client, la fenêtre temporelle et le nœud HA assurant le traitement, avec les journaux mentionnés ci-dessous.

HA et retour arrière pour le pilote Entra

L’aide SFOS 23 décrit également Synchronized User ID comme activé par défaut et exige son activation ou sa désactivation sur les deux appareils HA. La modification de l’état n’est pas enregistrée dans la sauvegarde. Les commandes shell conservées plus bas sont aussi documentées dans SFOS 23 ; elles modifient l’état de la fonction entière, et pas seulement d’Entra. Un tel redémarrage de service n’est donc pas un retour arrière anodin du pilote.

Tester le basculement uniquement dans une fenêtre de maintenance approuvée, avec un accès administrateur indépendant. Sur le nœud qui assure ensuite le traitement, valider à nouveau le heartbeat, une nouvelle connexion Entra, Live users, la règle de groupe et un nouveau flux de test. Ne pas présumer d’une reprise sans interruption de l’état utilisateur ou des sessions ; les correctifs SFOS 22 cités ci-dessous ne constituent pas une nouvelle garantie de basculement pour SFOS 23.

Pour le retour arrière, rétablir d’abord l’état initial documenté de la règle pilote et des associations pilotes, puis vérifier le chemin d’authentification antérieur avec une nouvelle connexion et du trafic réel. Ne pas supprimer ni désactiver globalement, pour nettoyer le test, l’application Entra, les serveurs, les autorisations et les groupes partagés avec le VPN, le portail ou WebAdmin. Si l’état global de Synchronized User ID a également été modifié pendant la fenêtre de maintenance, rétablir explicitement l’état souhaité sur les deux nœuds et le vérifier séparément après une restauration. Ne réactiver un chemin de retour AD qu’une fois la synchronisation Entra du même domaine arrêtée de manière contrôlée.

Les étapes et exemples AD qui suivent sont conservés comme un chemin distinct et plus ancien pour SFOS 22. La résolution de l’identité AD est également décrite dans l’aide SFOS 23, mais elle n’y remplace pas la vérification Entra.

SFOS 22 avec AD : Synchronized User ID en huit étapes

1. Choisir comme pilote un client de domaine Windows 10 équipé de Sophos Endpoint.
2. Vérifier Sophos Fusion (anciennement Sophos Central), Security Heartbeat et la licence du pare-feu.
3. Connecter Active Directory comme serveur d’authentification du pare-feu.
4. Comparer le domaine UPN, sAMAccountName, l’adresse e-mail et le profil utilisateur entre AD, Sophos Fusion et le pare-feu.
5. Préparer une règle utilisateur journalisée et strictement limitée pour un groupe pilote.
6. Ouvrir une nouvelle session Windows sur le pilote et confirmer un heartbeat vert.
7. Vérifier l’utilisateur, l’adresse IP et Client Type sous Current activities > Live users, ainsi que le trafic réel dans Log Viewer.
8. Tester la perte du heartbeat, le comportement HA et une procédure de retour contrôlée avant d’ajouter d’autres endpoints.

Quand utiliser Synchronized User ID

Synchronized User ID ne remplace pas de manière générale toutes les méthodes d’authentification Sophos. Le chemin AD pour SFOS 22 conservé ici convient lorsqu’un endpoint Windows 10 administré appartient normalement à un seul utilisateur AD et que Sophos Endpoint envoie déjà un Security Heartbeat. Pour les utilisateurs Entra sous SFOS 23, les prérequis et la validation de la branche distincte ci-dessus s’appliquent.

D’autres modèles d’exploitation nécessitent d’autres méthodes :

• STAS sur Sophos Firewall associe à une IP client les connexions Windows provenant des contrôleurs de domaine, de STA Agent et de Collector.
• SATC pour Remote Desktop Services distingue plusieurs sessions derrière une même IP RDS ou Citrix.
• Per-Connection AD SSO distingue les connexions HTTP et HTTPS de plusieurs utilisateurs via Direct Web Proxy.
• Captive Portal ou Client Authentication Agent conviennent lorsqu’une connexion interactive est nécessaire.

Ne pas imposer Synchronized User ID à un scénario de serveur ou de serveur de terminaux. Sophos indique explicitement que Server Protection n’est pas pris en charge. Si plusieurs utilisateurs partagent la même IP ou si les connexions non web doivent être associées par session, SATC est plus approprié.

Si Synchronized User ID et STAS sont configurés simultanément, Sophos indique que le serveur d’authentification utilise le mécanisme dont la demande de connexion arrive en premier. Ne pas considérer cette coexistence comme une priorité fixe. Délimiter clairement le pilote et vérifier Client Type lors de chaque validation.

Fonctionnement de l’association AD

Le processus comprend quatre niveaux distincts :

1. L’utilisateur ouvre une session sur le client de domaine Windows.
2. Sophos Endpoint transmet l’utilisateur du domaine au pare-feu via Security Heartbeat.
3. Le pare-feu extrait le domaine de l’UPN et le nom d’utilisateur de sAMAccountName.
4. Le pare-feu valide l’utilisateur via le serveur Active Directory correspondant et l’active pour les règles basées sur les utilisateurs.

La fonction n’authentifie pas les utilisateurs Windows locaux et ne remplace pas une connexion AD. Si le domaine UPN, le serveur d’annuaire ou le profil utilisateur ne correspondent pas, un endpoint vert peut rester dépourvu d’une identité utilisateur exploitable.

Sophos Firewall ne partage et n’utilise aucune information de mot de passe dans ce processus. Le heartbeat transporte les données de domaine et d’utilisateur nécessaires à l’association, tandis que la validation s’effectue sur le serveur AD configuré.

Exemple AD et valeurs à remplacer

Le processus utilise les valeurs de documentation suivantes :

• Pare-feu : fw01.example.com
• Domaine AD et suffixe UPN : example.com
• Client Windows : WS-101
• IP du client : 10.20.30.101
• Nom d’utilisateur : anna.muster
• UPN : anna.muster@example.com
• sAMAccountName : anna.muster
• Groupe AD : SFOS-Internet-Users
• Règle pilote : LAN_User_Internet

example.com, WS-101, 10.20.30.101, l’utilisateur et le groupe sont des exemples qui doivent être remplacés par les valeurs réelles. Le nom de l’objet n’est pas le point décisif. Sophos Fusion, Windows, Active Directory et le pare-feu doivent associer sans ambiguïté le même utilisateur.

Préparer les prérequis

Vérifier Sophos Fusion et Security Heartbeat

Le pare-feu doit être connecté à Sophos Fusion et disposer d’une souscription Network Protection valide. Le pilote nécessite Sophos Central Endpoint Protection avec une licence d’évaluation ou complète. Ces exigences de licence proviennent de l’aide SFOS 22 sur Security Heartbeat ; l’enregistrement et la référence du heartbeat sont décrits dans Connecter Sophos Firewall à Sophos Fusion.

Sous System > Sophos Fusion, l’enregistrement et Security Heartbeat doivent être actifs. Le pilote doit apparaître avec un état cohérent dans Control Center et Sophos Fusion. Établir d’abord cette référence, puis vérifier l’association d’identité.

Selon l’aide SFOS 22 sur Security Heartbeat, l’endpoint et le pare-feu échangent les données de heartbeat via une connexion TLS chiffrée vers 52.5.76.173 sur TCP 8347. Un état vert signifie que la protection Sophos fonctionne correctement et qu’aucun malware actif ou inactif ni aucune PUA n’a été détecté. Il ne prouve pas encore qu’AD a validé l’utilisateur. En cas de problème de connexion, vérifier séparément le transport, le tenant Fusion et le certificat de l’endpoint, puis l’association de l’utilisateur.

Synchronized User ID est activé par défaut. Il n’existe donc aucun commutateur WebAdmin normal à activer au préalable pour le pilote. Les commandes shell décrites plus loin servent uniquement à une désactivation ou réactivation contrôlée.

Comparer Active Directory et les attributs utilisateur (chemin AD)

Un serveur Active Directory approprié doit exister et être accessible sous Authentication > Servers. Connecter Active Directory à Sophos Firewall explique LDAPS, la base de recherche, l’importation de groupes et l’ordre des serveurs.

Aller ensuite sous Authentication > Services > Firewall authentication methods et déplacer le serveur AD vers Selected authentication server. L’aide SFOS 22 sur Authentication Services confirme qu’au moins un serveur doit être sélectionné ; s’il y en a plusieurs, le pare-feu les traite dans l’ordre affiché. La seule création du serveur sous Servers ne suffit pas pour l’authentification du pare-feu.

Au minimum, les valeurs suivantes doivent correspondre pour le pilote :

• Le domaine de l’UPN correspond au domaine du serveur AD utilisé par le pare-feu.
• sAMAccountName est unique dans Active Directory et peut être trouvé par le pare-feu.
• Le profil utilisateur et l’adresse e-mail correspondent entre AD, Sophos Fusion et l’enregistrement utilisateur local du pare-feu.
• Le groupe AD requis est importé et associé au profil utilisateur correct du pare-feu.

Un suffixe UPN différent, des valeurs sAMAccountName dupliquées dans des périmètres de recherche inadaptés ou un serveur AD incorrect sont des signaux d’arrêt. Ne pas les compenser par une règle utilisateur plus large.

Préparer la règle pilote

Sous Rules and policies > Firewall rules, cliquer sur Add firewall rule > New firewall rule et créer une règle strictement limitée pour le groupe pilote, ou utiliser de manière contrôlée une règle utilisateur existante. Dans la section de l’identité utilisateur, activer Match known users avant de sélectionner Users or groups :

• Source zones : zone client réelle
• Source networks and devices : réseau pilote ou plage source plus restreinte
• Users or groups : SFOS-Internet-Users
• Destination zones : uniquement le chemin de destination nécessaire
• Services : uniquement les services nécessaires au test
• Log firewall traffic : activé

L’ordre des règles, la journalisation et le test négatif sont plus importants qu’une règle d’autorisation large. Créer correctement des règles Sophos Firewall explique la configuration.

Connecter et valider le pilote AD

1. Fermer complètement la session de l’utilisateur existant sur le client pilote.
2. Ouvrir une nouvelle session Windows en tant que anna.muster@example.com.
3. Vérifier un heartbeat vert dans Sophos Fusion et sur le pare-feu.
4. Rechercher anna.muster et 10.20.30.101 sous Current activities > Live users.
5. Confirmer que l’utilisateur, l’adresse IP et Client Type: Heartbeat sont affichés.
6. Déclencher un test de trafic autorisé via LAN_User_Internet.
7. Ouvrir Log viewer en haut à droite, sélectionner le module du pare-feu et comparer le nom d’utilisateur, la source, la destination, le service, Firewall Rule ID, l’action et l’heure.
8. Effectuer un test négatif avec un utilisateur extérieur au groupe pilote.

Une entrée sous Live users prouve uniquement l’association d’identité. Seul le flux de test journalisé prouve que la bonne règle utilisateur s’applique également. Si le journal de trafic affiche uniquement l’adresse IP ou si le flux atteint une autre Rule ID, ne pas élargir la règle. Vérifier l’association et l’ordre.

Tester volontairement la perte du heartbeat

Si Security Heartbeat manque ou disparaît lors d’une mise en veille ou d’une reprise, le pare-feu déconnecte l’utilisateur détecté par Synchronized User ID. D’autres méthodes d’authentification configurées peuvent continuer à s’appliquer, mais le trafic basé sur les utilisateurs peut être interrompu jusqu’à la prochaine connexion.

Pour un test contrôlé :

1. Documenter d’abord l’utilisateur actif, l’IP, l’état du heartbeat et la règle.
2. Mettre le pilote en veille, puis le réactiver.
3. Vérifier à nouveau l’état du heartbeat et Live users.
4. Déclencher un nouveau test de trafic et confirmer l’utilisateur et la Rule ID réellement utilisés.
5. En cas d’écart, vérifier l’endpoint, le chemin et les journaux au lieu de désactiver globalement Synchronized User ID par précaution.

Un Missing Heartbeat ne signifie pas automatiquement qu’un malware est présent. Analyser systématiquement les alertes Missing Heartbeat décrit le diagnostic complet.

Interpréter les Release Notes de SFOS 22 et les limites connues

La validation doit tenir compte du Maintenance Release installé, et pas seulement de « SFOS 22 ». Le présent article Synchronized User ID documente lui-même les deux affirmations NC concrètes. La vérification avant la mise à niveau vers SFOS 22 couvre ici uniquement le contrôle de la version et du build, le chemin de mise à niveau approuvé et la préparation du changement. Les correctifs produit sont : MR1 Build 490 corrige le retard de l’accès à Internet après un basculement HA déclenché manuellement avec l’authentification heartbeat (NC-165361) ; MR2 Build 546 corrige les faux signalements Missing Heartbeat lorsque deux endpoints partagent la même station d’accueil ou interface USB (NC-176012). Si l’un de ces symptômes apparaît sur un build 22.0 antérieur, relever d’abord le build exact et évaluer un chemin de mise à jour approuvé.

Le runbook de diagnostic des alertes Missing Heartbeat traite aussi NC-147863 : avec le split tunneling SSL VPN vers un pare-feu externe, un nouvel adaptateur VPN peut interrompre la connexion heartbeat. L’utilisateur perd alors son authentification heartbeat et peut entrer dans une boucle de connexion et de déconnexion. Si le pilote comprend ce scénario, le tester spécifiquement. Comme solution de contournement, Sophos indique de désactiver Match known users dans la règle VPN du pare-feu local ou d’utiliser Captive Portal pour l’authentification. Limiter d’abord cette modification à la règle VPN concernée et documenter son impact ainsi que le retour arrière.

Délimiter systématiquement les erreurs

L’endpoint n’apparaît pas avec un heartbeat vert

Vérifier d’abord l’enregistrement Fusion, la licence de l’endpoint, la licence Network Protection, l’association du pare-feu, le DNS, l’heure et le chemin réseau. Sans Security Heartbeat fonctionnel, Synchronized User ID ne peut transmettre aucune identité.

L’utilisateur est absent de Live users

Pour le chemin AD, vérifier ensemble la connexion Windows, l’UPN, sAMAccountName, le serveur AD, le périmètre de recherche et le profil utilisateur. Un heartbeat vert confirme la connexion de l’endpoint, pas automatiquement la réussite de la validation AD. Sous SFOS 23, pour les utilisateurs Entra, utiliser plutôt les vérifications de l’UPN, du compte et de la connectivité décrites dans la branche Entra.

Utilisateur ou groupe incorrect

Pour AD, comparer le domaine UPN, le périmètre de recherche AD, le groupe importé, Main Group et les objets utilisateur locaux. Pour Entra sous SFOS 23, l’appartenance Entra et l’association UPN décrites dans la branche distincte s’appliquent également. Ne pas supprimer d’objets utilisateur avant d’avoir vérifié leurs dépendances aux VPN, portails, règles, quotas et rapports.

L’utilisateur est visible, mais la règle ne s’applique pas

Vérifier la zone et le réseau source, l’utilisateur ou le groupe, le service, la destination et l’ordre des règles. Dans Log Viewer, le flux réel doit afficher la Firewall Rule ID attendue. Une identité visible ne confirme pas à elle seule l’autorisation.

Serveur ou version de Windows non confirmée

Server Protection n’est pris en charge dans aucun des deux chemins. L’aide SFOS 22 cite explicitement Windows 10 pour AD ; la page SFOS 23 ne précise aucune version de système d’exploitation. Pour d’autres systèmes d’exploitation, modèles de jonction ou types d’endpoint inconnus, ne pas déduire une prise en charge en production de la disponibilité de la documentation ou du comportement d’un seul pilote.

Lire les journaux pertinents

Ces vérifications en lecture seule sont utiles dans Advanced Shell :

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log affiche les événements heartbeat, access_server.log aide pour l’authentification et l’autorisation, et hbtrust.log pour la relation de confiance avec Sophos Fusion. Un seul journal ne constitue pas une preuve complète. Conserver ensemble la fenêtre temporelle, l’utilisateur, l’endpoint, l’IP, la Rule ID et le nœud HA concerné. Fichiers journaux et services Sophos Firewall décrit d’autres chemins.

S’il reste difficile de déterminer si l’échec vient de l’annuaire, de la méthode, de l’enregistrement utilisateur local ou de la règle, Résoudre systématiquement les erreurs d’authentification fournit une séquence de diagnostic commune aux différentes méthodes.

Désactiver la fonction de manière contrôlée

⚠️ Les commandes suivantes modifient l’état de l’authentification et redémarrent access_server. Documenter d’abord les utilisateurs actifs, les règles concernées, un autre mode d’accès et la procédure de retour. En HA, les deux nœuds doivent être traités délibérément.

Les instructions officielles de SFOS 22 et SFOS 23 indiquent ces commandes pour une désactivation persistante :

touch /content/no_userid
service access_server:restart -ds nosync

Cette variante désactive la fonction uniquement jusqu’au prochain redémarrage du pare-feu :

touch /tmp/no_userid
service access_server:restart -ds nosync

Pour réactiver la fonction, supprimer le fichier persistant et redémarrer le service :

rm /content/no_userid
service access_server:restart -ds nosync

Après chaque modification, vérifier une nouvelle connexion Windows, Live users, le trafic réel et les journaux. L’état désactivé n’est pas stocké dans les sauvegardes de configuration. Après une restauration, contrôler à nouveau l’état souhaité et le définir sur les deux nœuds HA si nécessaire.

HA, sauvegardes et exploitation

Dans un cluster HA, Synchronized User ID est activé ou désactivé sur les deux appareils. Chaque nœud stocke uniquement les journaux du trafic et des événements qu’il traite. Pour un incident, vérifier le nœud qui était actif ou traitait le trafic au moment concerné.

Un test HA contrôlé nécessite une nouvelle connexion Windows et un nouveau flux de trafic. Ne pas supposer que l’état utilisateur ou les sessions actives se poursuivent sans interruption. Après un basculement, valider à nouveau au minimum le heartbeat, Live users, la règle utilisateur et les journaux.

L’état de /content/no_userid n’est pas inclus dans une sauvegarde. Cette exception doit être documentée explicitement dans les procédures d’exploitation, les tests de restauration et le processus RMA.

Retour arrière

1. Documenter l’état actuel du heartbeat, de l’utilisateur, de la règle et de la HA.
2. Désactiver la règle pilote ou rétablir son état antérieur documenté.
3. Uniquement si l’état global de la fonction a été modifié pendant le test, rétablir de manière contrôlée l’état initial documenté. Pour une réactivation souhaitée après une désactivation persistante, supprimer /content/no_userid et redémarrer access_server ; ne pas activer systématiquement une fonction auparavant désactivée. Selon Sophos, la variante temporaire prend fin au prochain redémarrage du pare-feu. Ne pas déclencher un redémarrage uniquement pour nettoyer le test en dehors d’une fenêtre de maintenance approuvée.
4. Établir le même état souhaité sur les deux nœuds HA.
5. Ouvrir une nouvelle session Windows sur le pilote et vérifier le heartbeat ainsi que Live users.
6. Tester à nouveau la règle utilisateur et le chemin d’authentification alternatif avec du trafic réel.
7. Supprimer seulement ensuite les objets de test temporaires ou les associations pilotes.

Liste de contrôle pour le chemin AD de SFOS 22

• Le pilote est un client de domaine Windows 10 pris en charge avec Sophos Endpoint.
• Le pare-feu, l’endpoint et Security Heartbeat sont visibles dans Sophos Fusion.
• Les licences Network Protection et endpoint sont valides.
• Le serveur AD, le domaine UPN, sAMAccountName, l’adresse e-mail et le profil utilisateur correspondent.
• Le groupe pilote est importé et la règle utilisateur est limitée et journalisée.
• Live users affiche l’utilisateur attendu et la bonne IP client.
• Le trafic réel atteint la Firewall Rule ID attendue.
• La perte du heartbeat et la mise en veille ou reprise ont été testées de manière contrôlée.
• Les nœuds HA, les journaux, la limite de restauration et la procédure de retour sont documentés.
• Synchronized User ID n’a pas été utilisé abusivement comme substitut de SATC, STAS ou d’autres services d’annuaire.

Questions fréquentes