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 et à certains prestataires externes. Un compte local ne constitue une solution de secours adaptée pour un service d’annuaire que si l’ordre des serveurs, le nom d’utilisateur distinct, l’accès au portail et le comportement en cas d’indisponibilité de la source externe ont été testés avec le service concerné. L’aide de SFOS décrit l’ordre des serveurs, mais ne garantit pas le basculement pour tous les types d’erreur.

Cet article s’applique à l’interface WebAdmin de SFOS 22. La seule création d’un utilisateur ne lui accorde aucun accès. Le groupe, la méthode d’authentification, le portail ou le client ainsi que la stratégie de pare-feu ou VPN doivent être configurés de manière cohérente.

Procédure rapide :

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. Définissez la convention de nommage, le type de compte et le responsable avant l’enregistrement. SFOS convertit les majuscules du nom d’utilisateur en minuscules. Un compte de remplacement possède une nouvelle identité ; vérifiez à nouveau ses règles, quotas, affectations VPN 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 avec soin. 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 ;
• une solution de repli testée, avec un nom d’utilisateur distinct, lorsqu’une source d’authentification externe est temporairement indisponible.

N’utilisez pas un compte local pour plusieurs personnes. Les identifiants partagés compliquent les changements de mot de passe, l’utilisation de la MFA, la gestion des quotas, les audits 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.

Exemple et conditions préalables

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 ;
• une source de connexion autorisée comprise entre 10.20.30.10 et 10.20.30.50.

example.com est un domaine réservé à la documentation ; la plage d’adresses appartient à un réseau privé utilisé comme exemple. Remplacez le nom d’utilisateur, l’adresse e-mail, le groupe, la règle et les adresses par les valeurs de votre environnement. Le nom d’utilisateur, volontairement neutre sur le plan fonctionnel, ne contient aucune adresse e-mail et reste donc valable si celle-ci change. La convention de nommage doit être compatible avec les processus du support et de départ ainsi qu’avec les noms déjà utilisés dans l’annuaire.

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. SFOS enregistre la valeur en minuscules ; celle-ci ne peut plus être modifiée par la suite.
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 la boîte aux lettres de cette personne. Pour un compte technique, utiliser une adresse surveillée placée sous la responsabilité d’une personne clairement désignée.
6. Dans Group, sélectionner Local_Pilot_Users.
7. Ne modifier Quarantine digest, les champs de stratégie et les champs Remote Access que si la fonction correspondante ou une exception utilisateur documentée est nécessaire.
8. Définir Simultaneous sign-ins et Sign-in restriction de manière appropriée.
9. Enregistrer avec Save.

SFOS rejette les mots de passe courants ainsi que les termes détectés par son contrôle du dictionnaire. Utilisez pour chaque compte un mot de passe long et unique, généré conformément à votre processus de gestion des mots de passe. Un exemple de mot de passe directement copiable deviendrait immédiatement un secret connu et ne constituerait donc 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, ne définissez pas de valeurs spécifiques dans ces champs par simple 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. N’attribuez dans l’objet utilisateur qu’une stratégie dont vous connaissez déjà le fonctionnement.

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 compte utilisateur individuel standard 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.

Pour cet exemple, sélectionnez Node range, puis saisissez 10.20.30.10 comme adresse de début et 10.20.30.50 comme adresse de fin. Remplacez ces deux valeurs par la plus petite plage contiguë depuis laquelle l’utilisateur se connecte réellement. Si vous avez besoin d’adresses IPv4 individuelles non contiguës, utilisez Selected nodes. Une sélection trop restrictive bloque les connexions légitimes ; Any node 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 la base de données locale. Sous Authentication > Services, activez la méthode Local dans la liste correspondant au service utilisé.

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.

Au maximum, 20 serveurs peuvent être sélectionnés par méthode d’authentification. Pour User Portal et VPN Portal, l’option d’héritage est Set authentication methods same as firewall. Pour SSL VPN, SFOS affiche Same as VPN ou Same as firewall, selon la référence sélectionnée. Vérifiez cette option et l’ordre qui en résulte avant d’ajouter ou de déplacer Local.

Configurer l’accès séparément

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.

Interpréter correctement les champs Remote Access

Pour les méthodes Remote Access autres que SSL VPN, les valeurs de stratégie propres à l’utilisateur ont priorité sur celles du groupe. SSL VPN suit une autre logique : L’utilisateur reçoit les ressources de toutes les stratégies Full et Split Tunnel qui le contiennent directement ou qui contiennent l’un de ses groupes pris en charge. Le champ SSL VPN policy ne remplace donc pas simplement les stratégies de groupe.

SSL VPN IP address n’apparaît que si les adresses statiques sont activées sous SSL VPN global settings. L’adresse IPv4 ou IPv6 doit être libre et appartenir à la plage statique créée automatiquement à cet endroit. Si un serveur RADIUS attribue les adresses, son attribution prévaut. IPsec remote access active en revanche l’accès avec Sophos Connect et peut recevoir sa propre adresse attribuée.

L2TP et PPTP sont des méthodes héritées. Après l’attribution, l’utilisateur doit d’abord se connecter à VPN Portal et créer un mot de passe avant de pouvoir établir la connexion. L’évaluation actuelle et le parcours de migration de L2TP figurent dans L2TP Remote Access ; PPTP ne doit plus être planifié pour de nouveaux accès. Clientless SSL VPN policy ouvre uniquement les bookmarks de navigateur attribués et ne constitue pas un tunnel complet. Le parcours séparé est présenté sous Clientless Access.

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 dans le journal du pare-feu ou du VPN que Local-Pilot-to-WAN, ou son Firewall Rule ID, correspond bien à la règle appliquée.
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.

S’il n’est pas clair si l’erreur provient du statut de l’utilisateur, de la méthode d’authentification, du groupe ou de la règle d’accès, Résoudre systématiquement les erreurs d’authentification de Sophos Firewall décrit la séquence de vérifications. Pour une analyse détaillée, /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, MFA et l’utilisation

Pour modifier en tant qu’administrateur le mot de passe d’un compte local existant dans SFOS 22 et 23, on ouvre l’utilisateur concerné sous Authentication > Users, puis on clique sur Change password. Au préalable, on vérifie le compte et son responsable, puis on prépare un nouveau mot de passe long et unique selon le processus approuvé de gestion des mots de passe. On saisit le nouveau mot de passe, on enregistre la modification et on transmet le secret de manière sécurisée à la personne autorisée. On teste ensuite une nouvelle connexion avec le nouveau mot de passe sur le service réellement utilisé. Cette opération dans WebAdmin se distingue du libre-service dans User Portal ; les comptes authentifiés en externe restent gérés par leur source d’utilisateurs respective. Cela ne garantit pas la fermeture automatique des sessions existantes.

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. Sous Personal > Personal Details, l’utilisateur peut également modifier son nom d’affichage. Le nom d’utilisateur et l’adresse e-mail y restent en lecture seule et sont gérés par l’administrateur dans l’objet utilisateur. User Portal n’est rendu accessible que depuis les zones nécessaires et n’est pas exposé largement au WAN uniquement pour cette maintenance.

Pour une protection supplémentaire, sélectionnez le compte 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 déploiement pilote. N’activez la MFA qu’après avoir testé la connexion normale et la procédure de récupération.

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.

Annuler la modification et supprimer le compte

Avant la phase pilote, documentez l’ordre existant sous Authentication > Services ainsi que tous les paramètres de groupe, de portail, de règle et de VPN que vous modifiez. Le retour en arrière ne reposera ainsi pas sur des valeurs par défaut supposées. En cas de départ, d’échec du pilote ou de fin d’utilisation du compte, procédez dans l’ordre inverse :

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 définir Change status sur Inactive.
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. Retirer l’utilisateur des règles du pare-feu et des politiques d’accès à distance, ou restaurer la sélection précédente documentée.
6. Rétablir exactement l’état précédent consigné pour les paramètres modifiés des groupes, des portails et des services d’authentification.
7. Contrôler les journaux du pare-feu, du VPN et de configuration afin d’y rechercher d’autres tentatives, du trafic résiduel et les modifications effectuées.
8. Ne supprimer le compte qu’après avoir résolu les dépendances, ou le garder inactif selon le processus de conservation.

L’aide de SFOS ne confirme pas que la désactivation met fin à toutes les connexions existantes. Vérifiez et déconnectez donc séparément les sessions et les tunnels. Après une réactivation, répétez les tests positifs et négatifs.

Avant une suppression risquée, vous pouvez exporter l’objet de configuration User avec Include dependent entity sous Backup and firmware > Import export. Cette exportation contient des données sensibles, notamment des mots de passe ; elle doit être chiffrée et stockée dans un emplacement dont l’accès est contrôlé. La clé Secure Storage Master Key appropriée doit également être disponible en vue d’une importation ultérieure. Une importation met à jour la configuration existante et applique les valeurs importées en cas de chevauchement. Les dépendances communes exportées en même temps peuvent donc également être écrasées. Examinez le contenu et les conséquences de l’importation au préalable, de préférence dans un environnement de test approprié.

Une sauvegarde complète ne permet pas d’annuler rapidement les modifications d’un seul utilisateur : une restauration remplace toute la configuration, redémarre le pare-feu et supprime les modifications effectuées ultérieurement. Le processus est décrit dans Sauvegarde et restauration sur Sophos Firewall.

Dans un cluster HA, effectuez la modification sur le nœud principal, puis vérifiez l’état de la synchronisation. Les journaux et les rapports ne sont pas synchronisés entre les nœuds et doivent être examinés séparément lors d’un diagnostic.

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 les mots de passe ou les 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à correspondre au trafic.

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. Ne rétablissez l’héritage du groupe qu’après avoir comparé la valeur 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

• Live users affiche pilotuser01, l’adresse IP source attendue et le Client Type prévu.
• Le journal d’authentification confirme la connexion locale ; Local-Pilot-to-WAN ou son Firewall Rule ID correspond au trafic de test.
• Un mot de passe incorrect, une source refusée et une fonction non autorisée fournissent la preuve négative attendue.
• Les exceptions propres à l’utilisateur, Simultaneous sign-ins, Sign-in restriction et toute date d’expiration sont documentées.
• L’enregistrement MFA et la procédure de récupération ont été testés si la MFA est utilisée.
• L’état précédent, le responsable, la désactivation, la déconnexion des sessions et la suppression ultérieure sont documentés.

Questions fréquentes