Créer et gérer des utilisateurs locaux sur Sophos Firewall

Un utilisateur local est enregistré directement sur Sophos Firewall et authentifié avec la base d’utilisateurs locale. Ce modèle convient aux petits environnements, aux comptes pilotes, à certains prestataires externes ou à un accès de secours géré volontairement. La création du compte ne donne toutefois pas accès à elle seule. Le groupe, la méthode d’authentification, le portail ou le client, la stratégie de pare-feu ou VPN et la vérification finale doivent être cohérents.

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

1. Définir le cas d’usage, la population cible et le service nécessaire.
2. Préparer un groupe restrictif de type Normal sous Authentication > Groups.
3. Sous Authentication > Users > Add, saisir un nom d’utilisateur durable et sélectionner User type: User.
4. Attribuer un mot de passe individuel robuste et le groupe approprié.
5. Laisser les champs de stratégie inchangés sur l’utilisateur si les valeurs du groupe doivent s’appliquer.
6. Limiter délibérément Simultaneous sign-ins et Sign-in restriction.
7. Sous Authentication > Services, vérifier que Local est sélectionné pour le service utilisé.
8. Configurer séparément et aussi précisément que possible le portail, la règle utilisateur ou la stratégie d’accès distant.
9. Tester avec un compte pilote une connexion positive, une connexion négative et le trafic réel.
10. Activer ensuite seulement la MFA, créer les autres utilisateurs et documenter le départ.

⚠️ Le nom d’utilisateur ne peut plus être modifié ultérieurement. Il faut donc définir la convention de nommage, le type de compte et la responsabilité avant l’enregistrement. Un nouveau compte portant un autre nom crée une nouvelle identité et peut disperser règles, quotas, affectations VPN, logs et traces d’audit.

Quand un utilisateur local est adapté

Les utilisateurs locaux ne nécessitent ni Active Directory ni serveur RADIUS ou LDAP externe. Cela simplifie la mise en œuvre, mais confie entièrement au pare-feu la gestion des mots de passe, de la MFA, des groupes, de la désactivation et des contrôles. Cette solution est pratique pour quelques comptes gérés consciemment. Pour de nombreux collaborateurs ou des arrivées et départs fréquents, un annuaire central est généralement plus facile à maintenir.

Un utilisateur local normal convient par exemple pour :

• un compte pilote pour Captive Portal, User Portal ou Remote Access ;
• un petit environnement sans service d’annuaire ;
• un prestataire externe précis avec une durée et un responsable clairement définis ;
• un accès de secours documenté lorsqu’une source d’utilisateurs externe est temporairement indisponible.

Un compte local partagé par plusieurs personnes n’est pas recommandé. Des identifiants communs compliquent les changements de mot de passe, la MFA, les quotas, l’audit et un départ propre.

Ne pas confondre les types d’utilisateurs

SFOS propose plusieurs types d’utilisateurs proches, mais destinés à des tâches différentes :

• Un utilisateur local normal se connecte avec un nom d’utilisateur et un mot de passe et reçoit ses stratégies par un groupe normal ou des exceptions utilisateur délibérées.
• Un utilisateur invité est limité dans le temps, utilise les paramètres Guest User et passe généralement par Captive Portal.
• Un Clientless User est identifié par une adresse IP et ne réalise aucune connexion interactive.
• Un administrateur local reçoit User type: Administrator ainsi qu’un profil Device Access pour les droits WebAdmin.
• Un utilisateur AD, LDAP, RADIUS ou Entra est authentifié par une source externe. Selon la méthode, sa fiche locale n’est créée qu’à la première connexion réussie.

Pour une personne qui doit se connecter à Captive Portal ou à un service VPN, on utilise User type: User. Ce compte n’obtient ainsi aucun accès WebAdmin ou SSH.

Planifier l’exemple et les prérequis

L’exemple suivant utilise :

• le nom d’utilisateur pilotuser01 ;
• le nom affiché Local Pilot User ;
• l’adresse e-mail pilotuser01@example.com ;
• le groupe Local_Pilot_Users ;
• la règle de pare-feu Local-Pilot-to-WAN ;
• la source de connexion autorisée 10.20.30.0/24.

example.com est un domaine réservé à la documentation ; 10.20.30.0/24 sert ici uniquement de réseau privé d’exemple. Le nom d’utilisateur, l’adresse e-mail, le groupe, la règle et le réseau doivent être remplacés par les valeurs de l’environnement réel. Le nom d’utilisateur est volontairement neutre et ne contient pas d’adresse e-mail, afin qu’un changement ultérieur d’adresse ne modifie pas l’identité de connexion. En production, la convention de nommage devrait être cohérente avec le support, le processus de départ et les noms d’annuaire existants.

Avant de créer le compte, il faut clarifier les points suivants :

• Quel service authentifie l’utilisateur : Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec ou un autre accès pris en charge ?
• Quel groupe normal porte la configuration commune ?
• Quelle stratégie de pare-feu ou d’accès distant autorise l’accès ultérieur ?
• Depuis quelles adresses IPv4 le compte peut-il se connecter ?
• Combien de connexions simultanées sont réellement nécessaires ?
• Une MFA locale est-elle requise et par quel portail l’enregistrement initial sera-t-il effectué ?
• Qui désactive le compte et contrôle les sessions existantes lors du départ ?

Gérer les groupes d’utilisateurs et le Main Group sur Sophos Firewall explique la logique commune des groupes. Pour les utilisateurs locaux normaux, on utilise un groupe de type Normal. Un groupe de type Clientless appartient au modèle basé sur l’adresse IP et ne constitue pas la bonne base pour ce parcours de connexion.

Créer l’utilisateur local

Le compte est créé sous Authentication > Users > Add :

1. Saisir pilotuser01 dans Username.
2. Saisir Local Pilot User dans Name.
3. Définir User type sur User.
4. Saisir et confirmer un mot de passe long et individuel issu du processus de mots de passe prévu.
5. Dans Email, saisir pilotuser01@example.com ou l’adresse réelle du responsable.
6. Dans Group, sélectionner Local_Pilot_Users.
7. Modifier les champs de stratégie et de Remote Access uniquement si une exception utilisateur documentée est voulue.
8. Définir Simultaneous sign-ins et Sign-in restriction de manière appropriée.
9. Enregistrer avec Save.

SFOS refuse les mots de passe courants et les mots repérés par son contrôle de dictionnaire. Cet article ne présente volontairement aucun mot de passe d’exemple. Un mot de passe copiable dans une documentation deviendrait immédiatement un secret connu et ne constituerait pas un modèle sûr.

Valeurs du groupe ou exceptions utilisateur

La fiche utilisateur permet de définir Surfing quota, Access time, Network traffic et Traffic shaping, ainsi que plusieurs champs Remote Access. Les valeurs propres à l’utilisateur ont priorité sur celles du groupe. Si le groupe doit rester la base facile à maintenir, ces champs ne sont pas remplacés par précaution.

Une exception utilisateur convient à un besoin clairement documenté, par exemple un Access Time plus restrictif pendant une intervention temporaire. Il faut consigner :

• le champ qui diffère de la valeur du groupe ;
• la raison de l’exception ;
• la date de révision ou de suppression ;
• la manière dont la valeur initiale du groupe redeviendra active.

Access Time pour les utilisateurs et quotas Surfing et Network Traffic expliquent chaque stratégie en détail. On n’attribue dans l’objet utilisateur qu’une stratégie déjà comprise.

Limiter le nombre et la source des connexions

Simultaneous sign-ins limite les sessions simultanées. Global setting reprend la valeur applicable aux nouveaux utilisateurs sous Authentication > Services. On peut également définir une valeur propre ou choisir Unlimited. Un nombre illimité est rarement nécessaire pour un utilisateur personnel normal et rend plus difficile la détection d’identifiants partagés.

Sign-in restriction limite les adresses IPv4 depuis lesquelles l’utilisateur peut se connecter :

• Any node: autoriser la connexion depuis toute source joignable ;
• User group nodes: reprendre la valeur du groupe ;
• Selected nodes: indiquer les adresses IPv4 prévues individuellement ;
• Node range: autoriser une plage IPv4 continue.

Dans l’exemple, on utilise le véritable réseau d’administration, d’utilisateurs ou VPN, et non une copie aveugle de 10.20.30.0/24. Un choix trop restrictif bloque des connexions légitimes. Any node élargit au contraire uniquement les sources de connexion possibles et ne remplace ni une règle de pare-feu, ni une ACL de portail, ni la MFA.

MAC binding n’est pas activé dans ce parcours de base. Cette option prend en charge l’authentification basée sur le client, mais pas Remote Access VPN ni Captive Portal. Si elle est activée sans adresse MAC, SFOS associe automatiquement la première adresse MAC détectée lors de la première connexion. Sur les appareils mobiles, après un changement de Wi-Fi ou avec des clients partagés, cela peut rapidement devenir une dépendance inattendue.

Relier la méthode d’authentification et l’accès

Un utilisateur enregistré ne peut se connecter qu’à un service qui interroge réellement la base locale. Sous Authentication > Services, on sélectionne donc Local pour le service prévu.

Les domaines sont distincts :

• Firewall authentication methods pour le trafic du pare-feu et Captive Portal ;
• User portal authentication methods pour User Portal ;
• VPN portal authentication methods pour VPN Portal ;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods pour ces méthodes VPN ;
• SSL VPN authentication methods pour Remote Access SSL VPN.

Lorsque plusieurs sources sont présentes, elles sont interrogées dans l’ordre affiché. Un test réussi sur User Portal ne prouve donc pas automatiquement que le même utilisateur est correctement configuré pour SSL VPN ou IPsec.

Le portail, la règle ou la stratégie VPN restent séparés

L’identité locale n’ouvre aucun chemin réseau. Captive Portal nécessite en plus Device Access, Web Authentication et une règle utilisateur adaptée. Le parcours complet est présenté dans Configurer et tester Captive Portal sur Sophos Firewall.

User Portal et VPN Portal sont également des services distincts. Le modèle des portails Sophos Firewall explique les ports, le rôle, Device Access et les limites WAN. Les stratégies Remote Access sont gérées dans les guides VPN correspondants et ne sont pas considérées comme terminées simplement parce qu’un champ est défini dans l’objet utilisateur.

Pour une règle de pare-feu basée sur l’utilisateur, on définit aussi précisément que possible la source, la destination, le service et l’utilisateur ou le groupe. Log firewall traffic reste activé pendant la validation. Les principes de base sont détaillés dans Comprendre et configurer en toute sécurité les règles Sophos Firewall.

Valider avec des tests positifs et négatifs

Un compte visible avec le statut Active ne prouve pas encore que tout fonctionne. Le compte pilote est testé via le service qui sera réellement utilisé :

1. Se connecter avec pilotuser01 dans une fenêtre de navigation privée ou depuis un client de test propre.
2. Sous Current activities > Live users, vérifier le nom d’utilisateur, l’adresse IP source et le Client Type.
3. Dans Log Viewer > Authentication, contrôler la connexion réussie, l’authentification locale et l’heure.
4. Générer le trafic prévu et vérifier la règle ou la stratégie attendue dans le log du pare-feu ou du VPN.
5. Utiliser comme test négatif une source ou une fonction explicitement non autorisée.
6. Si un quota ou un Access Time est actif, tester séparément son effet à l’intérieur et à l’extérieur de la limite.
7. Documenter le résultat, le groupe utilisé, les exceptions utilisateur et la méthode d’authentification.

Un test négatif ne devrait pas échouer uniquement parce qu’un mot de passe volontairement incorrect a été utilisé. Il faut aussi vérifier qu’une source non autorisée, un utilisateur sans le groupe approprié ou une fonction non prévue n’obtient réellement aucun accès. On distingue ainsi la vérification du mot de passe de l’effet des stratégies et des règles.

Si l’on ne sait pas encore si l’échec vient de la base locale, du choix du service, de l’état de l’utilisateur, du groupe ou de la règle suivante, dépanner méthodiquement les erreurs d’authentification Sophos Firewall fournit la séquence complète. Pour une analyse approfondie, /log/access_server.log contient les événements d’authentification, d’autorisation et de comptabilisation ; Log Viewer reste la première étape.

Gérer les mots de passe, la MFA et l’utilisation

Un utilisateur local peut modifier son mot de passe sous User Portal > Personal > Change Password. Cela vaut pour la base locale, et non pour les comptes AD, LDAP ou RADIUS authentifiés en externe. User Portal n’est rendu accessible que depuis les zones nécessaires et n’est pas exposé largement au WAN uniquement pour la gestion des mots de passe.

Pour une protection supplémentaire, le compte peut être sélectionné sous Authentication > Multi-factor authentication. Avec Generate OTP token with next sign-in, l’utilisateur enregistre le jeton via User Portal ou VPN Portal. MFA pour Sophos Firewall explique l’algorithme de hachage, l’accès au portail, la récupération et le pilote. La MFA n’est activée qu’une fois la connexion normale et la procédure de récupération opérationnelles.

Sous Authentication > Users > > View usage, on trouve les quotas attribués, le temps de Surfing et le volume de données consommé. Pour cela, le trafic doit correspondre à une règle de pare-feu basée sur l’utilisateur avec Log firewall traffic. Reset user accounting réinitialise les compteurs de Surfing et de Network Traffic et ne sert donc pas de correction générale pour un problème de connexion.

Désactiver et supprimer proprement le compte

Lors du départ d’une personne ou à la fin de la raison d’être du compte, celui-ci n’est pas supprimé immédiatement sans contrôle :

1. Vérifier les dépendances dans les règles, groupes, stratégies Remote Access, quotas, MFA et documentation.
2. Sous Authentication > Users, sélectionner l’utilisateur et utiliser Change status pour le rendre inactif.
3. Effectuer une nouvelle tentative de connexion comme test négatif.
4. Sous Current activities > Live users, vérifier les sessions existantes et utiliser Disconnect pour un utilisateur normal si nécessaire.
5. Contrôler les logs du pare-feu et du VPN pour repérer de nouvelles tentatives ou du trafic résiduel.
6. Supprimer le compte seulement après clarification des dépendances, ou le conserver inactif selon le processus de conservation.

La désactivation n’est pas considérée comme une garantie de fermeture automatique de chaque connexion existante. Les sessions, tunnels et flux sont vérifiés séparément. Après une réactivation, les tests positifs et négatifs sont répétés.

Les utilisateurs et les groupes partagent des identifiants internes. Un nombre élevé d’objets ne prouve pas à lui seul un problème. Si un utilisateur affiche toutefois un User ID supérieur à 65535 et ne s’authentifie pas, on utilise le parcours dédié à la limite d’ID utilisateur Sophos Firewall, plutôt que de modifier mots de passe ou règles sans preuve.

Dépanner selon le symptôme

Le nom d’utilisateur et le mot de passe sont refusés

Sous Authentication > Users, vérifier que le compte est local, actif et enregistré avec le nom d’utilisateur attendu. Contrôler ensuite sous Authentication > Services si Local est sélectionné pour le service précis. Une connexion réussie à un autre portail ne prouve pas ce choix de service.

La connexion fonctionne, mais la règle utilisateur ne correspond pas

Sous Current activities > Live users, vérifier l’identité, l’adresse IP source et le Client Type. Contrôler ensuite dans Log Viewer la position de la règle, Source Zone, l’utilisateur ou le groupe et Firewall Rule ID. Une règle réseau placée au-dessus de la règle utilisateur peut déjà prendre en charge le flux.

Une modification de groupe reste sans effet

Rechercher dans la fiche utilisateur des valeurs spécifiques pour le quota, Access Time, Traffic Shaping ou Remote Access. Ces exceptions ont priorité sur le groupe. Une valeur n’est replacée sur l’héritage du groupe qu’après comparaison avec l’exception documentée.

L’utilisateur peut se connecter depuis une source inattendue

Vérifier Sign-in restriction sur l’utilisateur et le groupe. Contrôler également le service réellement utilisé, Device Access et la règle réseau. Une valeur Any node n’est pas automatiquement compensée par la MFA ou une règle de pare-feu restrictive.

View usage reste vide

Vérifier que l’utilisateur est reconnu comme Live User et que le trafic correspond à une règle basée sur l’utilisateur avec Log firewall traffic. Contrôler ensuite la période, l’attribution du quota et le trafic de test réel. Reset user accounting ne génère pas les logs manquants et ne corrige pas une mauvaise règle.

Liste de contrôle opérationnelle

• Le cas d’usage, le responsable et la date d’expiration du compte sont documentés.
• Le nom d’utilisateur et le type d’utilisateur ont été choisis consciemment avant l’enregistrement.
• Un groupe de type Normal porte la configuration commune.
• Les exceptions utilisateur sont évitées ou justifiées.
• Simultaneous sign-ins et Sign-in restriction correspondent au cas d’usage.
• Local est sélectionné pour chaque service d’authentification nécessaire.
• Le portail, la règle de pare-feu ou la stratégie VPN ont été configurés séparément.
• Les connexions positive et négative ainsi que le trafic réel ont été contrôlés.
• Live Users, Authentication Log et la règle ou stratégie attendue concordent.
• La MFA et la récupération sont testées si la MFA est utilisée.
• Une personne responsable gère le changement de mot de passe, l’utilisation et le départ.
• La désactivation, les sessions existantes et la suppression ultérieure sont des étapes séparées.

Questions fréquentes