Gérer correctement les groupes d’utilisateurs et le groupe principal sur Sophos Firewall
Les groupes d’utilisateurs appliquent des stratégies communes aux utilisateurs authentifiés. Avant de modifier un groupe, clarifiez deux points : d’où provient l’identité et la fonction concernée évalue-t-elle uniquement le Main Group ou également d’autres groupes AD ? Vous pourrez alors déterminer s’il faut modifier l’ordre des groupes, l’attribution d’une stratégie ou la règle de pare-feu ou de VPN elle-même.
Procédure rapide :
- Définir la source de l’utilisateur et le but du groupe.
- Créer un groupe local ou importer spécifiquement le groupe d’annuaire requis.
- Vérifier sous Authentication > Services le Default group effectif ou, sur le serveur Entra, le Fallback user group.
- Pour AD, documenter l’ordre sous Authentication > Groups > Reorder et le groupe principal attendu.
- Déconnecter l’utilisateur pilote, puis le reconnecter. Ensuite, vérifier sous Authentication > Users > utilisateur > Policies les champs Group et Other group memberships.
- Tester la fonction concernée avec un utilisateur autorisé et un utilisateur non autorisé. En cas de trafic réseau, contrôler en plus le Firewall Rule ID attendu.
⚠️ Reorder n’est pas une simple fonction de tri. Pour les utilisateurs AD, un déplacement peut modifier le groupe principal et, par conséquent, la MFA, les quotas, les plages d’accès, l’accès à distance et d’autres stratégies pour de nombreux utilisateurs. Consignez au préalable l’ordre, les stratégies de groupe et la procédure de retour arrière.
Comprendre le modèle de groupe
Un groupe définit des stratégies et des paramètres communs. Il ne remplace ni l’authentification ni une règle de pare-feu. Un utilisateur peut donc être dans le bon groupe et ne pas obtenir l’accès si la règle, la politique VPN, la zone, la route ou le chemin de retour attendu fait défaut.
En cas d’erreur, examinez quatre questions distinctes :
- L’identité provient-elle de la base de données locale, Active Directory, LDAP, RADIUS, Microsoft Entra ID ou d’une affectation sans client ?
- Quel groupe est le groupe principal ?
- La fonction concernée prend-elle en charge les autres appartenances à des groupes AD ?
- Quelle règle ou politique traite le trafic réel ?
Différencier les groupes locaux, importés et sans client
Normal et Clientless sont des types de groupes. Importé décrit en revanche l’origine d’un groupe et n’est pas un Group type à part entière.
Un groupe local du type Normal convient aux utilisateurs qui se connectent. Le groupe des utilisateurs locaux est défini dans l’objet utilisateur. Avec une source d’utilisateurs externe, les enregistrements locaux ne sont généralement créés qu’à la première connexion réussie.
Les utilisateurs invités suivent un cycle distinct, limité dans le temps. Créer et utiliser en toute sécurité un utilisateur invité sur Sophos Firewall explique le groupe par défaut, la validité, le portail captif et le nettoyage.
Les groupes AD et Entra sont importés à l’aide de l’assistant du serveur concerné. L’annuaire reste la source des appartenances ; un groupe local portant le même nom ne remplace pas une importation correcte. La procédure complète de connexion AD, LDAPS et d’importation est décrite dans Connecter Active Directory avec Sophos Firewall.
Pour le LDAP générique, Base DN, Authentication attribute, Group name attribute, l’ordre des serveurs et Default group doivent être configurés de manière cohérente. Sophos recommande memberOf comme attribut de groupe. Connecter un serveur LDAP avec Sophos Firewall vous guide dans cette configuration.
Un groupe de type Clientless regroupe les utilisateurs sans client et leurs paramètres communs. Ces utilisateurs ne se connectent pas via un client ; le pare-feu contrôle leur accès en fonction de l’adresse IP. L’adresse IP fixe est enregistrée pour chaque utilisateur sans client, et non dans l’objet du groupe. Configurer les utilisateurs sans client sur Sophos Firewall décrit l’attribution des IP, la règle et le test négatif.
Ne pas assimiler le groupe par défaut et le groupe de secours Entra
Sous Authentication > Services > Firewall authentication methods, Default group définit quel groupe un utilisateur reçoit d’un serveur d’authentification externe si aucun de ses groupes d’annuaire n’existe en tant que groupe local. À la livraison, il s’agit de Open group. Vérifiez la valeur actuelle au lieu de présumer que la valeur par défaut est toujours utilisée. En production, Avanet recommande un groupe de secours dédié et restrictif, sans autorisations VPN, de quota ou de connexion involontaires.
Microsoft Entra ID SSO utilise le Fallback user group séparé dans la configuration du serveur Entra. Il s’applique également si le serveur Entra est sélectionné sous Firewall authentication methods. Le groupe par défaut général ne s’applique pas dans ce cas.
L’ordre des serveurs d’authentification est également pertinent. Sophos Firewall permet au maximum 20 serveurs par méthode d’authentification et transmet les requêtes dans l’ordre affiché. N’utilisez pas cet ordre pour contourner un problème de groupe avant d’avoir vérifié le serveur concerné et son mappage.
Planifier un exemple et l’état initial
L’exemple utilise trois tâches de groupe distinctes :
Local_Contractors: groupe pilote local pour quelques collaborateurs externes ;SFOS_Internet_Standard: groupe AD importé pour un accès Internet normal ;SFOS_SSLVPN: groupe AD importé pour une politique SSL-VPN.
auth-pilot@example.com sert de compte de test et la règle journalisée LAN-Users-to-WAN de test de trafic. example.com est un domaine de documentation réservé. Remplacez les noms et utilisateurs par votre propre convention de nommage. Un nom lié à la fonction comme SFOS_SSLVPN reste compréhensible même après une réorganisation.
Notez avant la modification :
- ordre actuel des groupes ;
- Default group et éventuellement Fallback user group ;
- stratégies de groupe et dérogations propres à l’utilisateur ;
- services d’authentification concernés et politiques VPN ;
- un accès administrateur vérifié et un second moyen d’administration, si le groupe principal, MFA ou les restrictions de connexion sont concernés ;
- utilisateurs pilotes, groupe principal attendu ainsi que tests positifs et négatifs.
Créer un groupe d’utilisateurs local
Allez à Authentication > Groups et cliquez sur Add :
- Saisissez
Local_Contractorscomme nom de groupe. - Sélectionnez Normal pour Group type.
- Sélectionnez uniquement les politiques communes nécessaires :
- Surfing quota limite le temps d’utilisation selon la période et le cycle.
- Access time permet ou refuse les périodes récurrentes.
- Network traffic limite la quantité de données transférées.
- Traffic shaping assigne une politique de QoS avec priorité et limites de bande passante.
- Définissez SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP et IPsec remote access uniquement pour l’accès réellement prévu. PPTP ne convient pas aux nouvelles architectures ; L2TP reste une option de compatibilité limitée, comme l’explique Accès à distance L2TP sur Sophos Firewall.
- Limitez Sign-in restriction autant que possible aux sources nécessaires avec Selected nodes ou Node range. Any node permet la connexion depuis n’importe quel réseau.
- Activez Quarantine digest et MAC binding uniquement si le groupe a besoin de ces fonctions.
- Cliquez sur Save.
Les noms des champs et leur effet sont déterminés par le produit ; le choix dépend de l’environnement. Un groupe d’accès à Internet n’a pas automatiquement besoin d’un VPN, d’un quota ou d’une liaison MAC. Les groupes ayant une fonction clairement délimitée sont plus faciles à tester et à restaurer.
Associer des utilisateurs locaux et repérer les dérogations
Créer et gérer des utilisateurs locaux normaux décrit en détail le nom d’utilisateur, le mot de passe, l’héritage de groupe et la validation. Les utilisateurs locaux peuvent être affectés à un groupe sous Authentication > Users. Dans l’écran de modification du groupe, Show group members affiche les membres ; Add member(s) permet d’ajouter les utilisateurs locaux appropriés. Pour les identités gérées de manière externe, le répertoire reste toutefois la source de l’appartenance.
Les stratégies propres à l’utilisateur ont priorité sur les stratégies de groupe. Sous Policies, vérifiez si une valeur propre à l’utilisateur a été sélectionnée à la place du paramètre de groupe. Si la stratégie de groupe doit de nouveau s’appliquer, rétablissez précisément l’état d’héritage précédemment consigné, puis testez uniquement la fonction concernée. Une dérogation reste pertinente lorsqu’une exception justifiée est expressément documentée.
La configuration complète des politiques de temps d’accès, quotas de surf et de trafic réseau ainsi que MFA pour Sophos Firewall est expliquée dans les articles spécialisés correspondants. Dans l’objet de groupe, attribuez uniquement une stratégie déjà planifiée.
Importer les groupes de répertoires de manière contrôlée
Groupes Active Directory
Allez sur Authentication > Servers et lancez l’assistant d’importation pour le serveur AD configuré. Dans un cluster HA, l’importation doit être effectuée sur Primary. L’assistant importe uniquement les groupes sélectionnés. Un groupe créé ultérieurement dans l’AD n’apparaît donc pas automatiquement et doit être importé à nouveau.
Les groupes AD imbriqués ne sont pas évalués. Si un sous-groupe doit s’appliquer à une règle de pare-feu ou une politique VPN, ce sous-groupe spécifique doit être importé. Le groupe AD principal d’un utilisateur n’est pas non plus importé comme appartenance ordinaire. Pour les politiques, il est donc préférable d’utiliser des groupes de sécurité explicites plutôt que le groupe standard AD Domain Users.
Après des modifications des adhésions AD, des groupes importés ou de l’ordre des groupes, l’utilisateur doit se reconnecter. Ce n’est qu’alors que le pare-feu réévaluera les groupes et mettra à jour l’objet utilisateur.
Groupes Entra
Pour l’importation de groupes Entra, l’enregistrement d’application dans Microsoft Graph nécessite l’autorisation d’application Group.Read.All avec Admin Consent. Les horloges du pare-feu et de Microsoft Entra ID doivent être synchronisées ; sinon la connexion peut échouer.
Allez ensuite à Authentication > Servers et ouvrez l’assistant d’importation de groupes du serveur Microsoft Entra-ID. Il est possible d’importer tous les groupes ou seulement ceux dont le Display name ou Description correspond à un filtre. Surfing quota, Access time, Network traffic et Traffic shaping peuvent être attribués à tous les groupes importés ou à certains groupes seulement. Les groupes nouvellement importés doivent également être ajoutés aux stratégies Remote Access IPsec ou SSL VPN utilisées ; l’importation seule ne donne pas accès au VPN.
Évaluer correctement les groupes principaux et les groupes multiples
Ouvrez l’utilisateur sous Authentication > Users et faites défiler jusqu’à Policies :
- Group affiche le premier groupe correspondant dans la liste du pare-feu et donc le groupe principal.
- Other group memberships affiche d’autres groupes AD importés de l’utilisateur.
Sous Authentication > Groups > Reorder, il est possible de modifier l’ordre par glisser-déposer. Cliquez sur Close pour fermer la boîte de dialogue. Si auth-pilot@example.com appartient à SFOS_Internet_Standard et SFOS_SSLVPN, le groupe approprié situé plus haut deviendra le groupe principal lors de la prochaine connexion.
Cet ordre ne concerne pas uniquement l’incident en cours. Avant toute modification, vérifiez si la fonction concernée prend en charge d’autres groupes. Sinon, un déplacement peut résoudre un problème de VPN tout en modifiant la MFA, les quotas ou les plages d’accès d’autres utilisateurs.
Fonctions avec support pour plusieurs groupes AD
La matrice suivante s’applique explicitement à Active Directory. Ne présumez pas qu’elle s’applique également à LDAP, RADIUS ou Microsoft Entra ID.
Plusieurs groupes AD peuvent être pris en compte par :
- 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 utilisateur et groupe correspondantes sont combinées. Dès qu’une stratégie Full-Tunnel correspondante intervient, le résultat est un Full Tunnel. Vérifiez cette combinaison avec un test client réel.
Seul le groupe principal ou une attribution explicite à l’utilisateur est 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 WAF, L2TP, PPTP et l’accès à distance IPsec, la politique utilisateur Enable peut s’afficher, alors que l’autorisation provient uniquement de Other group memberships et que l’accès n’est donc pas autorisé. Évaluez ces services en fonction du groupe principal ou d’une attribution directe à l’utilisateur, et non uniquement en fonction de l’affichage.
Pour les fonctions avec prise en charge de plusieurs groupes, l’ordre de la règle ou de la politique respective continue de déterminer le comportement. Une règle de pare-feu peut s’appliquer via SFOS_SSLVPN, même si SFOS_Internet_Standard est le groupe principal. Cela ne signifie pas que MFA ou Quota utilisent également SFOS_SSLVPN.
Vérifier l’effet du groupe
Un groupe enregistré et un utilisateur visible ne sont pas encore une preuve de succès :
- Fermez la session active de l’utilisateur pilote, puis reconnectez-le.
- Sous Authentication > Users > utilisateur > Policies, notez le statut, Group, Other group memberships et les éventuelles exceptions.
- Sous Current activities > Live users, vérifiez le nom d’utilisateur, l’adresse IP source et Client Type.
- Pour une règle de pare-feu basée sur l’utilisateur, déclenchez le trafic prévu et contrôlez Firewall Rule ID dans Log Viewer.
- Testez Access Time, Quota, MFA et Remote Access au moyen du service réellement concerné.
- Répétez le même test avec un utilisateur en dehors du groupe pilote comme test négatif.
Pour contrôler le quota, ouvrez Authentication > Users > utilisateur > View usage. Les données d’utilisation ne sont disponibles que lorsqu’une règle de pare-feu basée sur l’utilisateur traite le trafic et que Log firewall traffic est activé.
Vérifier les règles de pare-feu avec Log Viewer, Policy Test et Packet Capture montre le test complet du trafic. Si le choix du service, l’identité ou le groupe principal est déjà incertain, Résoudre systématiquement les erreurs d’authentification Sophos Firewall parcourt toute la chaîne de vérification.
Annuler les modifications et nettoyer les groupes
Modifiez à chaque fois une seule stratégie de groupe ou position. Si le test pilote montre un effet inattendu, rétablissez l’ordre et l’attribution de stratégie notés, reconnectez l’utilisateur et répétez le test positif et négatif.
Les groupes AD sont supprimés d’abord dans l’annuaire, puis séparément sous Authentication > Groups sur le pare-feu. Purge AD users ne nettoie aucun groupe.
Pour les utilisateurs AD, procédez comme suit :
- Supprimer d’abord l’utilisateur dans l’AD. Tant qu’il y sera présent, le pare-feu pourra le recréer lors d’une connexion ultérieure.
- Sous Authentication > Users, cliquer sur Purge AD users. Il n’est pas nécessaire de sélectionner les utilisateurs au préalable ; le pare-feu vérifie le serveur AD et ne supprime que les utilisateurs déjà supprimés là-bas.
- Dans HA, lancer la procédure sur Primary. Les enregistrements sont supprimés sur Primary et Auxiliary. Le nettoyage n’interrompt ni la connexion, ni la déconnexion, ni la comptabilité des utilisateurs.
Une exportation de configuration contient des groupes AD importés et créés localement, mais pas les utilisateurs des serveurs d’authentification externes. En revanche, une sauvegarde complète comprend tous les utilisateurs et groupes. Prenez en compte cette limite si la procédure de retour arrière concerne plus qu’un simple changement de politique.
Les utilisateurs et les groupes se partagent l’espace d’ID interne jusqu’à 65535. Un nombre élevé d’objets visibles à lui seul ne prouve pas un problème de limite. Si un utilisateur affiche un User ID au-dessus de 65535 et n’apparaît pas comme Live User, ce comportement correspond à la limite d’ID utilisateur Sophos Firewall.
Cerner les erreurs par symptôme
Reconnectez l’utilisateur concerné après chaque correction et contrôlez Group ainsi que Other group memberships. Ensuite, une étape ciblée suivante suffit pour chaque symptôme.
Le nouveau groupe AD n’apparaît pas
Redémarrez l’assistant d’importation du serveur AD et exécutez-le en HA sur le Primary. Vérifiez ensuite sous Authentication > Groups que le groupe requis est bien présent. Ne créez pas de groupe de remplacement trop permissif dans le seul but de rétablir une connexion.
L’utilisateur LDAP atterrit dans le groupe par défaut
Vérifiez sur le serveur LDAP Base DN, Authentication attribute et Group name attribute, puis sous Authentication > Services l’ordre des serveurs et Default group. Exécutez Test connection pour le serveur LDAP. L’assistant d’importation AD n’est pas responsable de ce mappage.
L’utilisateur Entra atterrit dans le groupe de secours
Vérifiez si le groupe Entra a été importé et si le jeton fournit le groupe attendu. Contrôlez ensuite le Fallback user group directement sur le serveur Entra. Le Default group général sous Authentication > Services n’est pas utilisé pour ce mappage.
L’utilisateur a le mauvais groupe principal
Comparez les adhésions AD, les groupes importés et l’ordre actuel. Vérifiez le nouvel ordre seulement après la prochaine connexion et avec plusieurs utilisateurs représentatifs.
La règle de pare-feu s’applique, mais pas la MFA ou le quota
Les règles de pare-feu prennent en charge d’autres groupes AD, tandis que MFA et les quotas ne le font pas. Vérifiez sous Authentication > Users > utilisateur > Policies le groupe principal, les éventuelles exceptions et l’affectation réelle de la politique. L’effet de la règle ne prouve pas que MFA ou le quota évaluent le même groupe.
Le changement de groupe ne s’applique pas à un seul utilisateur
Comparez les champs de politique spécifiques à l’utilisateur. Une dérogation a priorité sur la stratégie de groupe. Restaurez la valeur de groupe uniquement si l’exception documentée n’est plus nécessaire.
Le groupe AD imbriqué ne fonctionne pas
Importez le sous-groupe requis et ajoutez-y directement l’utilisateur. Importer uniquement le groupe parent ne suffit pas.