Vérifier la limite des User ID et nettoyer les utilisateurs AD

Si des utilisateurs nouveaux ou particuliers ne sont plus authentifiés alors que l’annuaire, le groupe et le mot de passe sont corrects, la User ID interne de Sophos Firewall peut en être la cause. Sophos mentionne également des cas dans lesquels les utilisateurs concernés ne peuvent pas télécharger de configuration .ovpn depuis le VPN Portal.

Sophos documente pour les utilisateurs et les groupes une plage d’ID interne commune allant jusqu’à 65535. Les utilisateurs dont l’ID est supérieure ne sont pas authentifiés et ne peuvent pas apparaître en tant que Live Users. Toutefois, le symptôme seul ne prouve pas que la limite est atteinte ; seule l’ID réellement attribuée est déterminante.

Les pages d’aide Sophos actuelles comptent cette plage différemment : Authentication > Users indique au maximum 65 535 User ID, tandis que Current activities > Live users en indique 65 536. Pour le diagnostic, la limite fiable reste identique dans les deux descriptions : 65535 est pris en charge, mais pas une valeur supérieure.

Vérifier rapidement la limite des User ID

L’ID concrète est visible dans WebAdmin :

1. Ouvrir Authentication > Users.
2. Sélectionner Show additional properties et afficher User ID.
3. Rechercher l’utilisateur concerné et noter son ID.
4. Si possible, vérifier à titre de comparaison un utilisateur fonctionnel du même groupe.
5. Sous Current activities > Live users, contrôler si l’utilisateur apparaît après une connexion.

L’interprétation est claire :

• User ID jusqu’à 65535 : La limite documentée n’est pas dépassée pour cet utilisateur. Le diagnostic général de l’authentification guide ensuite le contrôle du serveur, du service, de Live Users, du groupe, de la MFA, du portail et du chemin de trafic ultérieur.
• User ID supérieure à 65535 : L’objet utilisateur se trouve hors de la plage prise en charge. Le pare-feu n’authentifie pas cet utilisateur. Sophos mentionne également l’absence de téléchargement .ovpn comme un problème fonctionnel possible.
• L’utilisateur n’apparaît pas dans la liste : Les utilisateurs de serveurs d’authentification externes n’apparaissent normalement ici qu’après leur première connexion réussie à un service du pare-feu. Vérifier d’abord le chemin d’authentification proprement dit.

⚠️ Le nombre d’utilisateurs visibles ne suffit pas pour établir le diagnostic. Les groupes occupent également des ID et la numérotation peut comporter des lacunes. Seule la colonne User ID indique si l’utilisateur concerné est touché.

Une connexion manifestement réussie au VPN Portal indique que la limite des User ID n’est probablement pas la cause principale. Si le fichier .ovpn est absent, reste vide ou ne peut pas être généré, Sophos Firewall : fichier .ovpn absent ou de 0 octet distingue les erreurs de policy, d’utilisateur, de certificat et de système. La limite des User ID ne constitue qu’une branche possible du diagnostic.

Signification de la User ID interne

La User ID est l’attribution numérique interne d’un objet utilisateur ou groupe sur le pare-feu. Il ne s’agit ni d’un SID Active Directory, ni d’un Microsoft Entra Object ID, ni de la fonction Synchronized user ID authentication.

Un exemple simple illustre la limite :

• 60000 se trouve dans la plage prise en charge.
• 65535 est la dernière ID prise en charge.
• 65536 se trouve déjà hors de la plage prise en charge.

Les utilisateurs d’Active Directory, de RADIUS et d’autres serveurs d’authentification externes ne sont pas tous importés à l’avance. Leur enregistrement local est généralement créé lorsqu’ils s’authentifient pour la première fois auprès d’un service du pare-feu. Les groupes et les objets utilisateur déjà présents consomment la même plage d’ID.

Les Clientless Users créés manuellement font également partie de la structure d’identités locale. Configurer les Clientless Users sur Sophos Firewall présente leur procédure sûre de configuration et de test ; un nombre élevé d’objets ne prouve cependant toujours pas un problème de User ID.

Sophos recommande de supprimer les utilisateurs et groupes qui ne sont plus nécessaires afin de pouvoir réutiliser les ID libérées. Cela n’implique toutefois aucune renumérotation automatique : La suppression d’anciens objets ne documente ni ne garantit qu’un utilisateur existant dont l’ID est trop élevée recevra immédiatement un numéro inférieur.

Vérifier les dépendances avant le nettoyage

Le nettoyage des utilisateurs ou des groupes intervient dans la structure des identités et des stratégies. Avant une modification importante, une sauvegarde actuelle du pare-feu doit être disponible. Il faut également disposer d’une liste des objets à supprimer, de leurs User ID et de leurs utilisations connues.

Pour chaque utilisateur et chaque groupe, il faut au minimum vérifier les dépendances suivantes :

• stratégies SSL VPN et IPsec Remote Access ;
• stratégies de pare-feu, Web et d’application basées sur les utilisateurs ;
• attributions MFA, OTP ou de jetons ;
• Main Group et autres appartenances à des groupes ;
• règles d’inspection SSL/TLS ;
• source d’annuaire et comportement lors de la prochaine connexion.

Les objets ne sont pas supprimés uniquement en raison de leur ancienneté ou d’une ID élevée. Les comptes de test clairement obsolètes, les anciens collaborateurs et les groupes inutilisés sont traités en premier. Les identités de production ne sont pas supprimées et recréées sans vérification.

Nettoyer les utilisateurs AD de façon contrôlée

Utiliser correctement Purge AD users

Purge AD users supprime les enregistrements locaux des utilisateurs AD qui ont déjà été supprimés d’Active Directory. Il n’est pas nécessaire de sélectionner des utilisateurs individuels : Le pare-feu compare les enregistrements avec AD et supprime uniquement les utilisateurs qui n’y existent plus.

La procédure sûre est la suivante :

1. Vérifier que le serveur AD configuré est accessible et traite normalement les connexions.
2. Supprimer d’abord d’Active Directory les utilisateurs qui ne sont plus nécessaires.
3. Sur le pare-feu, ouvrir Authentication > Users.
4. Exécuter Purge AD users.
5. Vérifier que seuls les enregistrements attendus ont disparu.

Un compte uniquement désactivé dans AD, mais qui y existe toujours, n’est pas supprimé automatiquement par cette procédure. Si l’enregistrement local d’un utilisateur toujours présent dans AD est supprimé du pare-feu, il peut être recréé lors d’une connexion ultérieure. Configurer Active Directory sur Sophos Firewall explique la configuration et l’importation des groupes.

Dans un cluster HA, Purge AD users est lancé sur l’appareil Primary. Le pare-feu supprime les enregistrements sur les appareils Primary et Auxiliary ; il convient de vérifier le résultat sur les deux appareils. Sophos indique que le nettoyage n’interrompt pas les événements de connexion, de déconnexion et d’accounting. Cela ne garantit toutefois pas le comportement de chaque session VPN active. Pour les nettoyages très importants, il est conseillé de prévoir une fenêtre de maintenance, une surveillance de l’authentification et un plan de retour en arrière.

Nettoyer les utilisateurs locaux et les groupes

Les utilisateurs locaux, les comptes de test et les groupes qui ne sont plus nécessaires sont supprimés de manière ciblée sous Authentication > Users ou Authentication > Groups. Purge AD users ne nettoie pas les groupes AD. Un groupe AD qui n’est plus nécessaire est d’abord supprimé dans AD, puis séparément sur le pare-feu.

Le nettoyage s’effectue par petites étapes traçables :

1. Documenter les objets clairement obsolètes et leurs références.
2. Supprimer ou remplacer de façon contrôlée les références dans les règles, les stratégies VPN ou d’autres configurations.
3. Supprimer un petit ensemble d’objets qui ne sont plus nécessaires.
4. Tester la connexion en production, l’attribution des groupes et stratégies, ainsi que la MFA.
5. Ne poursuivre qu’ensuite avec l’étape de nettoyage suivante.

La désactivation d’un compte local ne suffit pas si son ID doit être réutilisée. Les importations étendues de groupes doivent également être limitées aux groupes réellement nécessaires pour les VPN, les portails, les règles ou les stratégies utilisateur.

Vérifier le résultat

Un nettoyage n’est pas réussi uniquement parce que moins d’objets sont visibles. Il faut ensuite tester à nouveau le même parcours utilisateur :

1. Sous Authentication > Users, vérifier que seuls les enregistrements AD attendus ont été supprimés.
2. Dans un cluster HA, comparer le résultat sur les appareils Primary et Auxiliary.
3. Afficher à nouveau la User ID du compte concerné.
4. Authentifier l’utilisateur auprès du service réellement concerné.
5. Sous Current activities > Live users et dans les journaux d’authentification, vérifier que la connexion a réussi.
6. Si l’erreur initiale concernait l’accès VPN, tester ensuite le VPN Portal, le téléchargement .ovpn et le tunnel.
7. Contrôler une connexion AD représentative en production, avec le groupe, la stratégie et la MFA.

Si l’ID reste supérieure à 65535, le problème de limite n’est pas résolu. La suppression d’autres objets de production ou la recréation répétée du compte concerné ne constitue pas une méthode de diagnostic sûre. Il est préférable d’ouvrir un dossier auprès de Sophos Support en indiquant la version du firmware, la source utilisateur, la User ID, l’horodatage, le journal d’authentification et les étapes de nettoyage documentées.

Éviter les problèmes de User ID

L’hygiène des utilisateurs doit faire partie de l’exploitation normale du pare-feu :

• importer uniquement les groupes d’annuaire réellement nécessaires ;
• nettoyer les anciens collaborateurs d’abord dans l’annuaire, puis sur le pare-feu ;
• supprimer les comptes locaux de test et de projet après leur utilisation ;
• vérifier les anciens objets utilisateur et groupe après une restructuration de l’annuaire ;
• comparer rapidement les User ID en cas de problèmes inhabituels d’authentification ou de VPN Portal ;
• documenter les Main Groups et les dépendances de MFA et de stratégies ;
• effectuer les nettoyages importants avec une sauvegarde, un petit ensemble de modifications et un test fonctionnel.

Le pare-feu ne doit connaître que les identités dont il a réellement besoin pour l’authentification, les stratégies, les portails, Remote Access et le reporting. Il ne remplace pas un cycle de vie des identités correct dans le service d’annuaire.

FAQ