Configurer Synchronized User ID Authentication sur Sophos Firewall

Synchronized User ID Authentication relie la connexion Windows d’un endpoint administré à Sophos Firewall. Sophos Endpoint transmet l’utilisateur du domaine via Security Heartbeat, le pare-feu le valide dans Active Directory, puis l’affiche 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.

⚠️ La documentation Sophos actuelle confirme ce processus pour Windows 10. Elle ne décrit pas Server Protection, les utilisateurs Windows locaux, les autres services d’annuaire ou les autres versions de Windows comme bénéficiant d’une prise en charge équivalente. Ne pas migrer ces systèmes vers ce processus sans validation ou test spécifique.

Synchronized User ID en huit étapes

1. Choisir comme pilote un client de domaine Windows 10 équipé de Sophos Endpoint.
2. Vérifier 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 Central 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. Il convient lorsqu’un endpoint Windows 10 administré appartient normalement à un seul utilisateur AD et que Sophos Endpoint envoie déjà un Security Heartbeat au pare-feu.

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

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 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 Central, Windows, Active Directory et le pare-feu doivent associer sans ambiguïté le même utilisateur.

Préparer les prérequis

Vérifier Sophos Central et Security Heartbeat

Le pare-feu doit être connecté à Sophos Central et disposer d’une souscription Network Protection valide. Le pilote nécessite Sophos Central Endpoint Protection avec une licence d’évaluation ou complète. L’enregistrement et la référence du heartbeat sont décrits dans Connecter Sophos Firewall à Sophos Central.

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

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

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.

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 Central 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, 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 :

• 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

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 Central 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 correspondent à la méthode attendue.
6. Déclencher un test de trafic autorisé via LAN_User_Internet.
7. Comparer dans Log Viewer 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.

Délimiter systématiquement les erreurs

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

Vérifier d’abord l’enregistrement Central, 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

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 la réussite de la validation AD.

Utilisateur ou groupe incorrect

Comparer le domaine UPN, le périmètre de recherche AD, le groupe importé, Main Group et les objets utilisateur locaux. 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 pas pris en charge pour ce processus. L’aide Sophos actuelle cite explicitement Windows 10. Ne pas déduire la prise en charge en production d’autres versions de Windows ou de types d’endpoint inconnus à partir d’un seul pilote concluant.

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 Central. 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.

Sophos utilise ce fichier 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. Pour la variante persistante, supprimer /content/no_userid de manière contrôlée et redémarrer access_server. Selon Sophos, la variante temporaire prend fin uniquement au prochain redémarrage du pare-feu.
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

• 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 Central.
• 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