Gérer correctement les groupes d’utilisateurs et le groupe principal sur Sophos Firewall

Les groupes d’utilisateurs de Sophos Firewall regroupent des stratégies communes pour les utilisateurs authentifiés. Ils permettent d’uniformiser Access Time, les quotas, Traffic Shaping, Remote Access et Sign-in Restrictions. Un groupe n’accorde toutefois aucun accès automatiquement : l’identité détectée, le groupe principal effectif, la stratégie de pare-feu ou VPN concernée et son ordre interviennent également.

La procédure courte et sûre est la suivante :

1. Définir la source des utilisateurs et la tâche que le groupe doit remplir.
2. Utiliser un groupe de type Normal pour les utilisateurs ordinaires ; planifier séparément les identités d’appareils basées sur l’IP en tant que Clientless.
3. Créer ou importer un petit groupe pilote avec une fonction claire et aussi peu de stratégies communes que possible.
4. Sous Authentication > Services, vérifier le Default Group prévu ou le groupe de secours du serveur Entra.
5. Pour Active Directory, documenter l’ordre sous Authentication > Groups > Reorder et définir le groupe principal attendu.
6. Éviter les exceptions propres aux utilisateurs ou les documenter explicitement, car elles remplacent les stratégies du groupe.
7. Déclencher une nouvelle connexion et vérifier Group et Other group memberships sous Authentication > Users.
8. Tester la fonction concernée avec un utilisateur positif et un utilisateur négatif ; pour le trafic, contrôler également la Firewall Rule ID attendue.
9. Ajouter d’autres utilisateurs uniquement après la réussite du pilote, puis contrôler régulièrement l’ordre des groupes, le Default Group et les exceptions.

⚠️ Reorder n’est pas une simple fonction de tri sans conséquence. Pour les utilisateurs AD, le déplacement d’un groupe peut modifier le groupe principal et donc MFA, les quotas, Access Time, Remote Access et d’autres stratégies pour de nombreux utilisateurs. Documenter au préalable l’ordre existant, les stratégies de groupe, les utilisateurs pilotes et le retour arrière.

Comprendre le modèle des groupes en quelques minutes

Sur le pare-feu, un groupe est un support commun de stratégies. Il peut attribuer les mêmes paramètres à plusieurs utilisateurs afin d’éviter la gestion individuelle de chaque compte. Il ne remplace ni l’authentification ni une règle de pare-feu. Un utilisateur peut apparaître dans le bon groupe sans obtenir d’accès si la règle, la stratégie VPN, la zone, la route ou le chemin retour attendu manque.

Quatre questions distinctes facilitent l’exploitation :

1. D’où provient l’identité ? En local, d’Active Directory, de LDAP, de RADIUS, de Microsoft Entra ID ou d’une association Clientless basée sur l’IP.
2. Quel groupe est effectif ? Avec AD, il peut s’agir du groupe principal ou, pour les fonctions compatibles, d’une autre appartenance à un groupe.
3. Quelle stratégie de groupe s’applique ? Access Time, Quota, Remote Access et d’autres champs suivent des règles d’évaluation différentes.
4. Quelle règle autorise le trafic ? Les stratégies de groupe seules n’ouvrent aucun chemin réseau.

Ne pas mélanger les groupes Normal, importés et Clientless

Un groupe local de type Normal convient aux utilisateurs qui s’authentifient au moyen d’un service pris en charge. Un utilisateur local reçoit son groupe dans l’objet utilisateur. Avec une source externe, les enregistrements d’utilisateurs locaux ne sont généralement créés qu’après la première connexion réussie.

Les comptes invités temporaires sont générés à partir des Guest user settings et héritent d’un groupe restrictif choisi délibérément. Créer et exploiter en toute sécurité des utilisateurs invités sur Sophos Firewall couvre la création, la validité, la validation du Captive Portal et l’offboarding.

Les groupes AD sont ajoutés au moyen de l’assistant d’importation. Leurs appartenances sont gérées dans l’annuaire et évaluées lors de la connexion. La procédure complète pour le serveur, LDAPS et l’importation figure dans Connecter Active Directory à Sophos Firewall. Pour un serveur LDAP générique, il faut planifier séparément la base de recherche, memberOf ou un autre attribut de groupe ainsi que le Default Group local ; Connecter un serveur LDAP à Sophos Firewall explique ces champs.

Un groupe de type Clientless répond à un autre besoin. Il associe une identité à une adresse IP fixe sans qu’une personne se connecte. Il est destiné aux imprimantes ou à d’autres systèmes clairement attribuables et ne remplace pas l’authentification des utilisateurs. Configurer les Clientless Users sur Sophos Firewall décrit le test sûr de l’IP, de la règle et du résultat négatif.

Choisir consciemment le Default Group et le groupe de secours

Sous Authentication > Services > Firewall authentication methods, Default group détermine le groupe attribué à un utilisateur externe lorsqu’aucun groupe local correspondant n’existe. Un Default Group trop large ou hérité de l’historique peut ainsi attribuer des stratégies inattendues. Il est plus sûr d’utiliser un groupe de secours volontairement restrictif dont l’effet a été testé positivement et négativement.

Microsoft Entra ID SSO utilise son propre Fallback user group dans la configuration du serveur Entra. Ce paramètre s’applique aussi lorsque le serveur est utilisé sous Firewall authentication methods. Le Default Group général et le groupe de secours Entra ne doivent donc pas être considérés comme un même réglage.

Planifier l’exemple et les prérequis

L’exemple suivant sépare trois objectifs :

• Local_Contractors : groupe pilote local pour quelques collaborateurs externes ;
• SFOS_Internet_Standard : groupe AD importé pour l’accès Internet normal ;
• SFOS_SSLVPN : groupe AD importé pour une stratégie SSL VPN ;
• auth-pilot@example.com : compte de test créé volontairement ;
• LAN-Users-to-WAN : règle de pare-feu journalisée pour le test Internet.

example.com est un domaine réservé à la documentation. Remplacer les noms des groupes, l’utilisateur et le nom de la règle par la convention de nommage de l’environnement. Un bon nom de groupe décrit sa fonction, pas uniquement un service. SFOS_SSLVPN reste par exemple compréhensible si la structure de l’organisation change ultérieurement.

Avant la première modification, consigner :

• l’ordre actuel sous Authentication > Groups ;
• le Default Group et, pour Entra ID, le groupe de secours ;
• les stratégies de groupe et les exceptions propres aux utilisateurs ;
• les services d’authentification et les stratégies Remote Access concernés ;
• un accès administrateur testé et un chemin de gestion indépendant ;
• un utilisateur pilote avec l’effet positif et négatif attendu.

Créer un groupe d’utilisateurs local

Créer la base commune sous Authentication > Groups > Add :

1. Saisir Local_Contractors dans Name.
2. Sélectionner Normal dans Group type.
3. Définir Surfing quota, Access time, Network traffic et Traffic shaping uniquement si le groupe a réellement besoin de ces fonctions en commun.
4. Activer les champs Remote Access tels que SSL VPN policy ou IPsec remote access uniquement pour l’accès prévu.
5. Limiter Sign-in restriction aux adresses sources réellement nécessaires ou à la plage prévue, si le modèle d’authentification le permet.
6. Activer Quarantine digest et MAC binding uniquement de manière délibérée.
7. Enregistrer avec Save.

Les noms des champs sont imposés par le produit. Les stratégies sélectionnées dépendent en revanche de l’environnement. Un groupe Internet ordinaire n’a pas automatiquement besoin d’un VPN, d’un Quota ou de MAC Binding. Moins un groupe mélange de tâches, plus son effet et son retour arrière sont faciles à comprendre.

Affecter les utilisateurs sans créer d’exceptions cachées

Créer et gérer des utilisateurs locaux normaux explique entièrement le nom d’utilisateur, le mot de passe, l’héritage du groupe, la méthode d’authentification et la validation. Ils peuvent être affectés à un groupe sous Authentication > Users. Dans la modification du groupe, Show group members affiche les membres et Add member(s) permet d’ajouter les utilisateurs locaux appropriés. Pour les identités gérées en externe, l’annuaire reste la source de l’appartenance. Une affectation locale manuelle ne remplace pas une configuration AD, LDAP ou Entra correcte.

Les stratégies propres à l’utilisateur ont priorité sur les stratégies de groupe. Une exception peut être utile pour un cas documenté ou un pilote, mais elle peut donner l’impression qu’une modification ultérieure du groupe n’a aucun effet. Pour chaque utilisateur différent, consigner le champ remplacé, la raison de l’exception et la manière de revenir à la valeur du groupe.

La création et la validation complètes des stratégies Access Time, des quotas Surfing et Network Traffic ainsi que de la MFA pour Sophos Firewall restent décrites dans les articles spécialisés correspondants. Dans l’objet du groupe, seule la stratégie déjà planifiée est affectée.

Exploiter les groupes AD importés de manière contrôlée

Les groupes AD sont importés dans le pare-feu sous Authentication > Servers > Import. Dans un cluster HA, l’importation s’effectue sur l’appareil Primary. L’assistant n’importe que les groupes sélectionnés. Un groupe créé ultérieurement dans AD n’apparaît donc pas automatiquement sur le pare-feu et doit être importé de nouveau ou créé volontairement de façon correspondante.

Les groupes AD imbriqués ne sont pas évalués. Si un sous-groupe doit servir à une règle de pare-feu, une stratégie VPN ou une autre fonction, ce sous-groupe précis doit être importé. Le groupe AD principal d’un utilisateur n’est pas non plus importé comme une appartenance ordinaire. Des groupes de sécurité explicites conviennent donc mieux aux stratégies que le groupe AD par défaut Domain Users.

Après une modification des appartenances AD, des groupes importés ou de l’ordre des groupes, déclencher une nouvelle connexion. Ce n’est qu’à ce moment que le pare-feu réévalue les groupes et met à jour l’objet utilisateur.

Comprendre le groupe principal et l’ordre des groupes

Pour un utilisateur AD, Authentication > Users affiche deux niveaux différents :

• Group: le premier groupe correspondant dans la liste du pare-feu, donc le groupe principal ;
• Other group memberships: les autres groupes importés de l’utilisateur.

Modifier l’ordre sous Authentication > Groups > Reorder. Si auth-pilot@example.com appartient à SFOS_Internet_Standard et SFOS_SSLVPN, le groupe correspondant situé le plus haut dans la liste devient le groupe principal lors de la prochaine connexion.

Cet ordre ne doit pas être modifié spontanément pour un incident isolé. Vérifier d’abord la fonction concernée et si elle prend effectivement en charge d’autres groupes. Un déplacement pourrait sinon résoudre un cas VPN tout en modifiant MFA, Quota ou Access Time pour d’autres utilisateurs.

Les groupes multiples sont évalués différemment selon la fonction

La limite suivante s’applique explicitement aux appartenances à des groupes Active Directory. Ne pas la transposer sans vérification à LDAP, RADIUS ou Microsoft Entra ID.

Plusieurs groupes AD peuvent être pris en compte pour :

• Firewall rules et SSL/TLS inspection rules ;
• SD-WAN routes ;
• Web policies ;
• IPS et Application control policies ;
• Policy test ;
• Remote access SSL VPN ;
• Clientless SSL VPN.

Pour Remote access SSL VPN, les autorisations des stratégies d’utilisateur et de groupe correspondantes sont combinées. Dès qu’une stratégie Full Tunnel correspondante intervient, le résultat est un Full Tunnel. Cette combinaison doit donc être vérifiée avec un vrai test client, et pas seulement en comparant les noms des groupes.

Seuls le groupe principal ou une affectation explicite d’utilisateur sont pris en compte pour :

• WAF rules, My policy overrides et Hotspots ;
• Remote access IPsec VPN, L2TP et PPTP ;
• Surfing quota, Access time, Network traffic et Traffic shaping ;
• Quarantine digest, MAC binding et Sign-in restriction ;
• MFA.

Pour les fonctions prenant en charge plusieurs groupes, l’ordre de la règle ou de la stratégie concernée reste déterminant. Une règle de pare-feu peut, par exemple, correspondre via SFOS_SSLVPN alors que SFOS_Internet_Standard est le groupe principal. Cela ne signifie pas que MFA ou Quota utilise également SFOS_SSLVPN.

Tester l’effet du groupe avec un véritable utilisateur

Un groupe enregistré et un utilisateur visible ne constituent pas encore une preuve de réussite. Utiliser pour le pilote la même procédure qui s’appliquera ensuite en production :

1. Fermer la session existante de l’utilisateur pilote et déclencher une nouvelle connexion.
2. Sous Authentication > Users, consigner l’état, Group, Other group memberships et les éventuelles exceptions propres à l’utilisateur.
3. Sous Current activities > Live users, vérifier le nom d’utilisateur, l’adresse IP source et Client Type.
4. Pour une règle de pare-feu basée sur l’utilisateur, générer le flux attendu et contrôler la Firewall Rule ID dans Log Viewer.
5. Pour Access Time, Quota, MFA ou Remote Access, tester séparément le service concerné.
6. Exécuter le même flux comme test négatif avec un utilisateur qui n’appartient pas au groupe pilote.
7. Consigner le résultat, l’heure, l’ordre des groupes et la stratégie effective.

Tester les règles de pare-feu avec Log Viewer, Policy Test et Packet Capture présente le test de trafic complet. Si l’on ne sait déjà pas si l’échec vient du choix du service, de l’identité, du groupe principal ou de la règle ultérieure, Résoudre systématiquement les erreurs d’authentification Sophos Firewall guide à travers toute la chaîne de vérification.

Modifications, retour arrière et exploitation

Traiter les modifications de groupes comme des modifications de stratégies :

1. Documenter l’état initial et les utilisateurs concernés.
2. Ne modifier qu’un groupe, une stratégie ou une position à la fois.
3. Réauthentifier l’utilisateur pilote.
4. Vérifier de nouveau le groupe principal, les autres appartenances et la fonction concernée.
5. En cas d’effet inattendu, restaurer l’ordre des groupes et l’affectation de stratégie précédents.
6. Déclencher une nouvelle connexion et répéter les tests positif et négatif.

Nettoyer un groupe AD d’abord dans l’annuaire, puis sur le pare-feu. Un utilisateur toujours présent dans AD peut être recréé localement lors d’une connexion ultérieure. Purge AD users n’est donc ni un bouton de synchronisation ni une étape habituelle après une modification de groupe.

Les utilisateurs et les groupes partagent la plage d’ID interne jusqu’à 65535. Un nombre élevé d’objets visibles ne prouve pas à lui seul un problème de limite. Si un utilisateur affiche une User ID supérieure à 65535 et ne devient pas Live User, suivre la procédure distincte relative à la limite d’ID utilisateur de Sophos Firewall.

Limiter la recherche d’erreur selon le symptôme

Le nouveau groupe AD n’apparaît pas sur le pare-feu

Les nouveaux groupes ne sont pas synchronisés automatiquement. Relancer l’assistant d’importation et, en HA, l’exécuter sur le Primary. Vérifier ensuite sous Authentication > Groups que le groupe précis requis est présent. Ne pas créer un large groupe de remplacement uniquement pour faire fonctionner une connexion.

L’utilisateur a le mauvais groupe principal

Documenter d’abord les appartenances AD, les groupes importés et l’ordre actuel. Vérifier ensuite si le groupe attendu est réellement présent sur le pare-feu. Une modification planifiée sous Reorder ne doit être évaluée qu’après une nouvelle connexion et doit être testée avec plusieurs utilisateurs représentatifs.

La règle de pare-feu correspond, mais MFA ou Quota ne s’applique pas

Les règles de pare-feu prennent en charge d’autres groupes AD, contrairement à MFA et aux quotas. Dans l’objet utilisateur, vérifier quel groupe apparaît sous Group comme groupe principal. Contrôler ensuite les exceptions propres à l’utilisateur et l’affectation réelle de la stratégie. La correspondance de la règle ne prouve pas que MFA ou Quota évalue les groupes de la même manière.

La modification du groupe n’agit mal que pour un seul utilisateur

Comparer les champs de stratégie propres à l’utilisateur sous Authentication > Users. Une exception individuelle a priorité sur la stratégie de groupe. Ne pas modifier la valeur sans vérification, mais la comparer d’abord à l’exception documentée et à l’état d’héritage souhaité.

L’utilisateur arrive dans le Default Group

Avec AD ou un autre serveur d’authentification classique, un groupe local correspondant ou une association de groupe manque probablement. Vérifier l’importation, le nom du groupe, la base de recherche et les attributs retournés. Pour Microsoft Entra ID SSO, contrôler plutôt le Fallback user group du serveur Entra. Ne pas élargir globalement le Default Group pour masquer l’erreur d’association réelle.

Le groupe AD imbriqué ne s’applique pas

Importer le sous-groupe requis lui-même et y ajouter directement l’utilisateur. Déclencher ensuite une nouvelle connexion et vérifier Group et Other group memberships. L’importation du seul groupe parent ne suffit pas.

Liste de contrôle d’exploitation

• L’objectif du groupe et la source d’utilisateurs responsable sont documentés.
• Les groupes locaux, importés et Clientless ne sont pas mélangés.
• Le Default Group ou le groupe de secours Entra est choisi consciemment et de façon restrictive.
• L’ordre des groupes et les groupes principaux attendus sont documentés.
• Les exceptions propres aux utilisateurs sont justifiées ou supprimées.
• La fonction concernée prend en charge l’appartenance au groupe utilisée.
• L’utilisateur pilote a été réauthentifié et vérifié sous Authentication > Users.
• Les tests positif et négatif confirment la stratégie ou la Firewall Rule ID attendue.
• Remote Access, MFA, Access Time et les quotas ont été validés séparément lorsqu’ils sont utilisés.
• Le retour arrière pour l’ordre des groupes et l’affectation des stratégies est consigné.

Questions fréquentes