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

Les groupes d’utilisateurs centralisent les 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 des utilisateurs et le rôle 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 sans conséquence. 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 stratégie 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, d’Active Directory, de LDAP, de RADIUS, de 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 stratégie 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 de type Normal convient aux utilisateurs qui se connectent. Pour les utilisateurs locaux, le groupe est défini dans l’objet utilisateur. Avec une source d’utilisateurs externe, les enregistrements locaux des utilisateurs 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. Pour AD, Sophos documente également la création manuelle du groupe à la fois dans AD et sur le pare-feu comme alternative. Il faut également vérifier l’affectation au groupe et les autorisations après une nouvelle connexion. La procédure complète de connexion AD, de configuration 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 provenant d’un serveur d’authentification externe reçoit 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 involontaires de VPN, de quota ou de connexion.

Descriptions divergentes de la première connexion dans la documentation AD : Le guide de configuration AD décrit une affectation automatique au Default group lors de la première connexion ; la FAQ AD, en revanche, ne mentionne le Default group que lorsqu’aucun groupe AD de l’utilisateur n’existe sur le pare-feu. La présentation des serveurs AD indique explicitement Open group pour les utilisateurs qui appartiennent uniquement à une OU et à aucun groupe d’annuaire, tandis que la présentation des groupes et la FAQ renvoient au Default group configuré. Ces descriptions présentent des contradictions et ne permettent d’établir ni l’existence d’un groupe particulier qui s’appliquerait universellement à la première connexion, ni sa priorité. Le Default group configuré doit être distingué du réglage d’usine Open group.

Avant le déploiement, vérifiez le Default group effectivement configuré et les autorisations qui en sont héritées. Vérifiez séparément la première connexion avec deux nouveaux comptes pilotes dédiés : l’un dont un groupe AD est déjà importé sur le pare-feu, et l’autre dont aucun groupe AD n’y est importé. Pour chacun des deux comptes, vérifiez sous Policies les champs Group et Other group memberships, ainsi que les accès autorisés et ceux qui ne doivent délibérément pas l’être. En cas d’affectation inattendue, arrêtez le déploiement et clarifiez la cause. Ne supprimez pas de groupes de production et n’élargissez pas les autorisations de secours pour effectuer ces vérifications. Il s’agit d’étapes de vérification limitées avant le déploiement, et non d’un compte rendu de test effectué sur une appliance.

Microsoft Entra ID SSO utilise le Fallback user group distinct défini 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é. Ne modifiez 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 groupes aux rôles distincts :

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 stratégie SSL-VPN.

auth-pilot@example.com sert de compte de test et la règle journalisée LAN-Users-to-WAN sert à tester le trafic. example.com est un domaine réservé à la documentation. Remplacez les noms et utilisateurs par ceux de 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 :

l’ordre actuel des groupes ;
Default group et éventuellement Fallback user group ;
les stratégies de groupe et les dérogations propres à l’utilisateur ;
les services d’authentification concernés et les stratégies VPN ;
un accès administrateur vérifié et un second moyen d’administration, si le groupe principal, la MFA ou les restrictions de connexion sont concernés ;
les utilisateurs pilotes, le groupe principal attendu ainsi que les tests positifs et négatifs.

Créer un groupe d’utilisateurs local

Allez à Authentication > Groups et cliquez sur Add :

Saisissez Local_Contractors comme nom de groupe.
Sélectionnez Normal pour Group type.
Sélectionnez uniquement les stratégies communes nécessaires :
- Surfing quota limite le temps d’utilisation selon la période et le cycle.
- Access time autorise ou interdit l’accès pendant des plages horaires récurrentes.
- Network traffic limite la quantité de données transférées.
- Traffic shaping attribue une stratégie de QoS avec une priorité et des 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. Selected nodes autorise uniquement les adresses IP indiquées ; Node range autorise les adresses comprises dans la plage IP indiquée. 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. Quarantine digest envoie à la boîte aux lettres de l’utilisateur un récapitulatif des e-mails retenus en quarantaine. MAC binding limite la connexion aux appareils prévus.
Cliquez sur Save pour enregistrer.

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 à retirer proprement.

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, l’annuaire reste toutefois la source de l’appartenance.

L’utilisation des paramètres de l’utilisateur ou du groupe par une règle ou une stratégie dépend de la sélection réelle des utilisateurs et des groupes. Sous Policies, vérifiez pour l’utilisateur si une valeur propre à celui-ci 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 à nouveau uniquement la fonction concernée. Une dérogation reste pertinente lorsqu’une exception justifiée est expressément documentée.

Sophos distingue deux cas pour la sélection dans la règle ou la stratégie concernée :

Seul le groupe est sélectionné : le pare-feu utilise les paramètres du groupe, et non automatiquement la dérogation de l’utilisateur.
L’utilisateur et son groupe sont sélectionnés : le pare-feu utilise les paramètres de l’utilisateur.

Un test pilote limité permet de constater la différence : pour auth-pilot@example.com dans Local_Contractors, consignez une valeur de groupe A et une valeur utilisateur différente B pour le même paramètre pris en charge. A et B représentent deux valeurs de test délibérément prévues pour votre environnement. Dans une règle ou une stratégie de test isolée avec sélection des utilisateurs et des groupes, vérifiez d’abord la sélection réelle : uniquement Local_Contractors signifie A ; auth-pilot@example.com avec Local_Contractors signifie B. Testez le service ou le chemin de données concerné avec une nouvelle connexion dans chaque cas ; pour le trafic du pare-feu, contrôlez également le Firewall Rule ID. Rétablissez ensuite la sélection précédemment consignée et les deux paramètres, puis testez à nouveau. N’élargissez pas une règle de production et ne modifiez pas l’ordre des groupes pour ce test.

Cette sélection ne correspond pas à l’ordre du Main Group. Les limites de la prise en charge de plusieurs groupes et la combinaison des stratégies SSL-VPN correspondantes décrites ci-dessous restent applicables ; cela ne signifie pas qu’une stratégie utilisateur a toujours priorité pour tous les services.

La configuration complète des stratégies de plages d’accès, des quotas de navigation et de trafic réseau ainsi que de la 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.

Situer les champs de groupe dans l’API XML

Pour gérer les groupes de manière automatisée, le modèle XML propose UserGroup comme objet de groupe, GroupDetail comme corps de configuration et GroupMembers avec GroupName et UserName comme données d’appartenance. Il ne s’agit pas d’une importation des appartenances AD ; pour les utilisateurs d’annuaire, l’annuaire reste la source de référence. L’authentification, les enveloppes d’opération explicites et l’analyse de la réponse XML sont décrites dans Utiliser l’API XML en toute sécurité.

L’extrait suivant montre uniquement la structure documentée pour les exemples pilotes existants. Il ne constitue pas une requête Add/Edit complète ni testée sur une appliance ; il manque notamment l’enveloppe d’opération et d’autres champs de configuration nécessaires. L’omission de certains champs ne permet pas de conclure qu’une modification conserve les valeurs existantes.

<UserGroup>
  <GroupDetail>
    <Name>Local_Contractors</Name>
    <LoginRestriction>SelectedNodes</LoginRestriction>
    <NodeList>
      <IPAddress>192.0.2.10</IPAddress>
    </NodeList>
  </GroupDetail>
  <GroupMembers>
    <GroupName>Local_Contractors</GroupName>
    <UserName>auth-pilot@example.com</UserName>
  </GroupMembers>
</UserGroup>

Le nom du groupe et l’utilisateur doivent être remplacés par ceux de la cible locale précisément prévue. 192.0.2.10 est une adresse IPv4 réservée à la documentation et doit être remplacée par une source de connexion autorisée réellement nécessaire. Les noms des champs XML restent inchangés. La correspondance avec les champs de l’interface est la suivante :

SurfingQuotaPolicy : Surfing quota ; AccessTimePolicy : Access time.
DataTransferPolicy : Network traffic ; QoSPolicy : Traffic shaping.
SSLVPNPolicy : SSL VPN policy ; ClientlessPolicy : Clientless SSL VPN policy, et non le type de groupe Clientless.
SophosConnectClient : IPsec remote access via le client Sophos Connect.

Pour LoginRestriction, l’exemple de référence distingue AnyNode, SelectedNodes et NodeRange. AnyNode correspond à Any node et ne limite pas la source de connexion ; ce n’est pas une valeur par défaut à utiliser pour le dépannage. SelectedNodes utilise NodeList avec les différentes entrées IPAddress. NodeRange utilise à la place FromIP et ToIP, par exemple de 192.0.2.10 à 192.0.2.20. Les deux bornes de la plage sont également des valeurs de documentation et doivent être remplacées par la plus petite plage IPv4 nécessaire, sans élargir les restrictions existantes. Bien que le tableau indique que FromIP et ToIP sont obligatoires, leur description les limite à Node range ; cela ne les rend pas obligatoires de manière générale pour les autres variantes.

La référence de l’API indique pour QuarantineDigest, MACBinding, L2TP, PPTP et SophosConnectClient les valeurs Enable ou Disable et documente Disable comme valeur par défaut. Il s’agit d’une information de référence, et non d’une preuve de l’état du groupe actuellement enregistré. Lorsque QuarantineDigest est actif, le récapitulatif de quarantaine est envoyé quotidiennement par e-mail. PPTP reste exclu des nouvelles architectures ; L2TP reste uniquement l’option de compatibilité limitée décrite plus haut.

Limites de l’exemple de référence : Il sépare les paramètres des groupes Normal d’une branche Clientless qui présente QoSPolicy. Il est toutefois contradictoire concernant GroupType : le modèle contient Normal/Clienless, la description mentionne Normal ou Clientless et indique INTEGER comme type de données. Le modèle contient en outre des deux-points comme espaces réservés au lieu de contenus XML complets. Il ne faut en déduire ni un encodage Clientless corrigé ni une correspondance numérique. Pour une opération d’écriture, utilisez une valeur lue ou exportée depuis la version installée, dont la correspondance est déjà établie ; sinon, utilisez la procédure sûre dans l’interface. Les alternatives séparées par une barre oblique, comme Enable/Disable, ne sont pas des valeurs uniques à reprendre telles quelles.

Le modèle présente également After avec un Name imbriqué comme indication de position. La deuxième ligne du tableau consacrée à Name mentionne moveto, mais n’atteste pas d’une opération exécutable de manière autonome. Un changement de position doit être traité comme Reorder : il peut modifier le Main Group. Au préalable, sauvegardez l’ordre, les appartenances, l’état actuel et l’état prévu des stratégies, ainsi que la procédure de retour arrière ; vérifiez ensuite avec l’utilisateur pilote et, en cas d’effet inattendu, rétablissez l’ordre sauvegardé. Le modèle n’atteste ni d’un comportement de remplacement ou de fusion de GroupMembers, ni de la sémantique de mise à jour de After ou des champs omis.

Avant une opération d’écriture Add/Edit strictement limitée, consignez le nom cible et l’état souhaité. Ensuite, analysez le résultat réel de l’opération XML, relisez précisément le groupe nommé et effectuez les tests positifs et négatifs décrits plus haut sur le service concerné. Pour Add et Edit, la référence associe 502 à la clé UserGroupRecordExists et 503 à la clé UserGroupDuplicateIPInLoginRestriction. Si le résultat correspond à l’un de ces cas, vérifiez d’abord le nom du groupe existant prévu ou les adresses en double dans SelectedNodes, respectivement. Ne renvoyez pas la requête à l’aveugle et n’élargissez pas LoginRestriction. Ces correspondances attestent de clés de référence, et non de messages d’exécution rendus qui auraient été observés ici.

Importer les groupes d’annuaire de manière contrôlée

Groupes Active Directory

Allez à Authentication > Servers et lancez l’assistant d’importation pour le serveur AD configuré. Dans un cluster HA, l’importation doit être effectuée sur le 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 faire l’objet d’une nouvelle importation.

Avant l’importation, les requêtes AD doivent fonctionner : le serveur doit être configuré avec les valeurs correctes de NetBIOS domain et Domain name, un ADS username disposant des droits de recherche, de lecture et d’interrogation des appartenances aux groupes, ainsi que son Password. Un compte administrateur de domaine n’est pas nécessaire pour importer les groupes. Connection security propose SSL/TLS par défaut et STARTTLS comme autre option chiffrée ; Plaintext transmet les identifiants sans chiffrement et n’est pas une solution sûre en production. Le Port doit correspondre au type de connexion choisi. Pour Validate server certificate, le certificat du serveur AD est téléversé sous Certificates > Certificates > Add > Upload certificate ; Server IP/domain doit utiliser le CNAME indiqué dans le certificat. Si le pare-feu ne parvient pas à résoudre ce nom, vérifiez la résolution DNS interne ou Network > DNS > DNS host entry. La configuration complète du serveur reste décrite dans l’article AD lié plus haut.

Les Search queries limitent le périmètre des utilisateurs pris en compte. Par exemple, OU=VPN_Users,DC=example,DC=com effectue une recherche dans l’OU VPN_Users du domaine de documentation example.com ; l’OU et les composants du domaine doivent être remplacés par le nom distinctif réel. Une base de recherche plus restreinte permet de conserver un périmètre d’utilisateurs clair, mais ne doit pas exclure les utilisateurs prévus. Seuls les utilisateurs inclus dans ce périmètre peuvent apparaître comme Live Users via ce serveur. Test connection vérifie la connexion et les identifiants, mais ne prouve pas encore qu’un utilisateur normal est affecté au bon groupe. L’application stricte de LDAP Channel Binding et de LDAP Signing n’est pas prise en charge ; toute exigence de sécurité AD correspondante doit être clarifiée avant l’intégration, et non contournée comme s’il s’agissait d’une erreur de groupe.

L’importation proprement dite se déroule comme suit :

Sur le serveur AD prévu, cliquez sur Import, puis sur Start dans Import group wizard.
Sélectionnez le Base DN adapté à la recherche de groupes. Il doit inclure les groupes nécessaires et doit être distingué de la base de recherche des utilisateurs.
Sélectionnez uniquement les groupes AD prévus, par exemple SFOS_Internet_Standard et SFOS_SSLVPN.
Sélectionnez les stratégies communes aux groupes, puis vérifiez la sélection et les résultats.
Sous Authentication > Groups, vérifiez les deux groupes et leurs stratégies. L’assistant importe les groupes, mais pas immédiatement tous les enregistrements utilisateurs ni toutes les appartenances.
Sous Authentication > Services > Firewall authentication methods, vérifiez que le serveur AD est sélectionné pour le service prévu. Si AD doit être interrogé en premier dans cette procédure de configuration, déplacez le serveur en première position, puis cliquez sur Apply. Dans un environnement existant, conservez l’ordre des serveurs planifié au préalable plutôt que de le modifier systématiquement.

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 précis doit être importé. Le groupe primaire AD d’un utilisateur n’est pas non plus repris comme une appartenance ordinaire. Pour les stratégies, il est donc préférable d’utiliser des groupes de sécurité explicites plutôt que le groupe standard AD Domain Users.

Cela ne concerne pas uniquement Domain Users : si, par exemple, SFOS_Internet_Standard devient le groupe primaire AD de l’utilisateur, cette appartenance précise n’est pas reprise comme une appartenance AD ordinaire. Le groupe importé correspondant suivant peut alors devenir le groupe principal du pare-feu. Le groupe principal du pare-feu est déterminé à partir de sa propre liste de groupes et ne correspond pas au groupe primaire dans AD.

Après toute modification des appartenances 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éévalue les groupes et met à jour l’objet utilisateur.

Si STAS et Synchronized User ID sont configurés simultanément, le serveur d’authentification utilise le mécanisme dont la demande de connexion arrive en premier. Si les résultats des tests pilotes diffèrent, vérifiez donc également Client Type plutôt que de réorganiser immédiatement les groupes ou les serveurs.

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 consentement administrateur. Les horloges du pare-feu et de Microsoft Entra ID doivent être synchronisées ; sinon, la connexion peut échouer.

Allez ensuite sous Authentication > Servers et lancez l’assistant d’importation de groupes du serveur Microsoft Entra ID. Vous pouvez importer tous les groupes ou uniquement ceux dont le Display name ou la Description correspond à un filtre. Surfing quota, Access time, Network traffic et Traffic shaping peuvent être attribués à tous les groupes importés ou à certains d’entre eux. Les groupes nouvellement importés doivent également être ajoutés aux politiques Remote access IPsec ou SSL VPN utilisées ; l’importation seule ne donne pas accès au VPN.

Évaluer correctement le groupe principal et les appartenances 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, qui constitue donc le groupe principal.
Other group memberships affiche les autres groupes AD importés auxquels appartient l’utilisateur.

Deux champs supplémentaires apparaissent sous Policies uniquement si les deux conditions sont réunies pour chacun d’eux :

Group SSL VPN policies: L’utilisateur appartient à plusieurs groupes AD, et au moins deux de ces groupes sont inclus dans les stratégies SSL VPN d’accès à distance.
Group clientless SSL VPN policies: L’utilisateur appartient à plusieurs groupes AD, et au moins deux de ces groupes sont inclus dans les stratégies SSL VPN sans client.

Si l’un de ces champs n’apparaît pas, vérifiez donc d’abord les appartenances AD, les groupes importés et leur inclusion dans la stratégie VPN correspondante. L’appartenance à plusieurs groupes AD ne suffit pas à elle seule pour que le champ s’affiche. N’élargissez pas les autorisations VPN de production dans le seul but de rendre le champ visible. Cet affichage ne constitue pas non plus un test d’accès ; la combinaison réelle des autorisations est expliquée plus bas.

Sous Authentication > Groups > Reorder, vous pouvez 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 correspondant placé le plus haut devient 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 prenant en charge 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 sans vérification.

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 correspondante en tunnel complet intervient, le résultat est un tunnel complet. Vérifiez cette combinaison avec un test réel sur un client.

Pour Clientless SSL VPN, les autorisations de toutes les stratégies auxquelles appartient l’un des groupes AD de l’utilisateur sont prises en compte. Vérifiez donc non seulement la stratégie attendue, mais aussi les favoris ou ressources supplémentaires autorisés par d’autres groupes.

Les Hotspots prennent exclusivement en compte le groupe principal.

Seul le groupe principal ou une attribution explicite à l’utilisateur est pris en compte pour :

WAF rules et My policy overrides ;
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 Remote access IPsec, la stratégie utilisateur peut afficher Enable, 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 prenant en charge plusieurs groupes, l’ordre des règles ou des stratégies concernées reste déterminant. 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 la MFA ou les quotas utilisent également SFOS_SSLVPN.

Pour Web policies, deux décisions distinctes interviennent : la règle de pare-feu correspondante détermine d’abord la stratégie web. Dans cette stratégie, la première règle qui correspond à la fois à l’utilisateur et au site web s’applique. Si l’utilisateur pilote appartient aux deux groupes de l’exemple et que la première règle web bloque les sites sportifs pour SFOS_SSLVPN, un site sportif est bloqué, même si SFOS_Internet_Standard est son groupe principal et qu’une règle ultérieure autorise les sites d’actualités pour ce groupe. IPS et Application control utilisent, en revanche, la stratégie de la règle de pare-feu correspondante ; l’ordre des groupes ne crée aucune combinaison supplémentaire de ces stratégies.

Pour la MFA, vous pouvez inclure explicitement l’utilisateur au lieu de sélectionner un groupe, ou appliquer la MFA à tous les utilisateurs. Une autorisation provenant uniquement de Other group memberships ne suffit pas. Les Hotspots dans le User Portal dépendent exclusivement du groupe principal ; une autre appartenance AD n’élargit pas cette liste.

Vérifier l’effet du groupe

Un groupe enregistré et un utilisateur visible ne constituent pas encore une preuve de réussite :

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 dérogations.
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 les plages d’accès, les quotas, la MFA et l’accès à distance au moyen du service réellement concerné.
Répétez le même test avec un utilisateur extérieur au groupe pilote pour effectuer un test négatif.

Pour contrôler le quota, ouvrez Authentication > Users > utilisateur > View usage. Les données d’utilisation ne sont disponibles que si 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 présente 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 vous guide dans toute la chaîne de vérification.

Annuler les modifications et nettoyer les groupes

Ne modifiez qu’une stratégie de groupe ou une position à la fois. Si le test pilote révèle un effet inattendu, rétablissez l’ordre et l’attribution de stratégie consignés, reconnectez l’utilisateur et répétez les tests 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 :

Supprimez d’abord l’utilisateur dans AD. Tant qu’il y existe, le pare-feu peut le recréer lors d’une connexion ultérieure.
Sous Authentication > Users, cliquez 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 dans cet annuaire.
En HA, lancez la procédure sur le Primary. Les enregistrements sont supprimés sur Primary et Auxiliary. Le nettoyage n’interrompt ni Sign-in, ni Sign-out, ni User Accounting.

Une exportation de configuration contient les 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. Tenez compte de cette limite si le retour arrière ne concerne pas uniquement la modification d’une seule stratégie.

Supprimer en toute sécurité un groupe nommé via l’API

Avant toute suppression, définissez le Name exact du groupe cible et sauvegardez ses stratégies, sa position dans l’ordre, ses membres et ses utilisations. Le fait que l’ancien tableau de l’API indique que Name n’est pas obligatoire n’autorise pas une suppression sans nom : la description exige un nom pour identifier l’objet. Vérifiez au préalable les utilisateurs réels du groupe, les affectations VPN, y compris L2TP/IPsec, la sélection pour l’authentification externe, les références dans les règles de pare-feu et l’utilisation comme groupe par défaut des invités. Si le groupe est encore nécessaire, effectuez une migration explicitement planifiée et strictement limitée, ou arrêtez la procédure. Ne forcez pas la suppression, ne nettoyez pas les utilisateurs et n’assouplissez pas les accès dans le seul but de faire aboutir la suppression. L’ordre des opérations AD décrit plus haut et la distinction avec Purge AD users restent applicables.

La référence de suppression associe des lignes de résultat à des clés de messages JavaScript concernant ces dépendances. Cela atteste de ces catégories de vérification, et non des textes de messages rendus manquants ou d’une erreur d’appliance observée ici. Pour la construction de la requête et le traitement du résultat XML, consultez Utiliser l’API XML en toute sécurité ; la référence de suppression des groupes ne fournit pas d’exemple de charge utile, aucune enveloppe Delete n’est donc inventée ici. En cas de refus, conservez le groupe et vérifiez de manière ciblée la référence indiquée dans le résultat. Même après un résultat de réussite, relisez précisément la cible, vérifiez son absence et répétez les tests de service et d’accès prévus.

Les utilisateurs et les groupes se partagent la plage d’ID interne jusqu’à 65535. Un nombre élevé d’objets visibles ne suffit pas à prouver un problème de limite. Si un utilisateur affiche un User ID supérieur à 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. Pour chaque symptôme, une vérification suivante ciblée suffit ensuite.

Le nouveau groupe AD n’apparaît pas

Relancez l’assistant d’importation du serveur AD et, en HA, exécutez-le sur le Primary. Vérifiez ensuite sous Authentication > Groups que le groupe précisément requis est présent. Ne créez pas de groupe de remplacement trop permissif dans le seul but de permettre une connexion.

L’utilisateur LDAP se retrouve 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 se retrouve 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 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 appartenances AD, les groupes importés et l’ordre actuel. Vérifiez le nouvel ordre uniquement 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, contrairement à la MFA et aux quotas. Vérifiez sous Authentication > Users > utilisateur > Policies le groupe principal, les éventuelles dérogations et l’attribution réelle de la stratégie. L’effet de la règle ne prouve pas que la MFA ou le quota évalue le même groupe.

Le changement de groupe ne s’applique pas à un seul utilisateur

Comparez les champs de stratégie propres à l’utilisateur et la sélection réelle des utilisateurs et des groupes dans la règle ou la stratégie concernée : si seul le groupe est sélectionné, les valeurs du groupe sont utilisées ; si l’utilisateur et son groupe sont sélectionnés, les valeurs de l’utilisateur sont utilisées. Vérifiez également les limites de la fonction concernant le groupe principal et les appartenances multiples. Rétablissez la valeur du groupe uniquement si l’exception documentée n’est plus nécessaire.

Le groupe AD imbriqué ne s’applique pas

Importez le sous-groupe requis lui-même et ajoutez-y directement l’utilisateur. Importer uniquement le groupe parent ne suffit pas.