Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access

L’accès administratif et les portails d’accès à distance ne doivent pas seulement être protégés par un nom d’utilisateur et un mot de passe. Avec l’authentification multifacteur, MFA en abrégé, le Sophos Firewall nécessite également un deuxième facteur, par exemple un code OTP temporel provenant d’une application Authenticator.

Pour le contexte global de hardening, consulter le hub Sophos Firewall Hardening : bonnes pratiques pour une configuration sécurisée.

L’article explique comment planifier, activer et tester judicieusement le MFA. L’accent est mis sur les WebAdmin, VPN Portal et l’accès à distance.

Classification et protection d’accès

MFA est une protection importante pour les connexions, mais seulement un élément de base. Premièrement, il doit être clair quel accès est protégé, quelle source d’identité se cache derrière et si le service doit même être accessible à partir du réseau concerné.

Quel article d’authentification convient ?

MFA n’est qu’une partie de la sécurité d’accès. Selon l’objectif, la première chose à considérer est l’accessibilité, la source d’identité, le portail, le client VPN ou l’application web publiée :

• MFA pour WebAdmin, VPN Portal ou programmer un accès à distance: Cet article.
• WebAdmin, SSH, User Portal, VPN Portal, Restreindre l’accès DNS ou Ping: Sophos Firewall Sécuriser l’accès : configurer correctement le Device Access
• Utilisez Microsoft Entra ID SSO pour Sophos Connect ou VPN Portal: Configurer l’authentification unique Microsoft Entra ID pour Sophos Connect et VPN Portal
• Comparez Sophos Connect, SSL VPN, IPsec ou ZTNA comme modèle d’accès à distance: Sophos Connect ou SSL VPN : quelle solution d’accès à distance est la bonne ?
• Vérifiez la version du client Sophos Connect, les reconnexions OTP ou le provisionnement SSO: Vérifiez la version de Sophos Connect Client et mettez-la à jour en toute sécurité
• Sécurisation des applications Web publiées WAF avec MFA: Sécurisez le WAF Sophos Firewall avec MFA
• Connecter Active Directory classique en tant que source d’utilisateurs: Ajouter Active Directory sur Sophos Firewall
• Préparez un accès contrôlé au support pour Avanet ou Sophos: Configuration de l’accès du support Avanet à Sophos Firewall
• Prioriser les résultats du contrôle de santé pour MFA ou l’accès au portail: Utiliser correctement Sophos Firewall Health Check

Cette séparation est importante : MFA protège les connexions, mais elle ne limite pas automatiquement les réseaux WebAdmin, SSH ou les portails accessibles. À l’inverse, une règle stricte d’accès aux appareils ne remplace pas un deuxième facteur. Une bonne sécurité d’accès combine l’accessibilité, la source d’identité, le MFA, la journalisation et un accès de secours testé.

Quand MFA a du sens

MFA doit être activé au moins pour tous les comptes autorisés à accéder aux interfaces d’administration ou aux fonctions d’accès à distance.

Domaines d’application typiques :

• Inscription sur WebAdmin.
• Inscription sur VPN Portal.
• SSL VPN ou accès à distance Sophos Connect.
• Accès pour les prestataires externes.
• Accès pour les administrateurs privilégiés.

Le MFA réduit le risque de vol de mots de passe, mais ne remplace pas les restrictions d’accès appropriées. SSH, WebAdmin et les portails ne doivent toujours être accessibles qu’à partir de réseaux fiables ou via un accès de gestion clairement défini.

MFA ne remplace pas Device Access

MFA protège le processus de connexion. Cependant, cela ne réduit pas la surface d’attaque d’un service. Si WebAdmin, User Portal, VPN Portal ou SSL VPN sont accessibles depuis Internet, ces services continueront d’être attaqués par des robots, des scanners et des tentatives de force brute. Cela crée des entrées de journal inutiles, des efforts de support et des risques.

C’est pourquoi vous devez toujours combiner le MFA avec des contrôles de disponibilité :

• Device access: définit en principe quels services sont accessibles dans quelle zone.
• Local service ACL exception rule: autorise WebAdmin, SSH ou les portails de manière ciblée uniquement depuis des réseaux de management, des réseaux VPN ou des adresses sources connues.
• MFA: Sécurisez également les inscriptions si les données d’accès valides ont été compromises.
• Journalisation et Syslog: Rendre compréhensibles les tentatives infructueuses, les problèmes de déploiement et les attaques.

Si un portail doit être accessible dans le monde entier, vous devez au moins combiner MFA, des certificats valides, une journalisation, des groupes d’utilisateurs restrictifs et des processus de révision réguliers. Pour les services de pare-feu accessibles au public, la question n’est pas seulement de savoir si un attaquant peut se connecter, mais si le service doit être largement accessible.

Restreindre également l’accès avec les règles ACL

Avant d’activer MFA, vous devez vérifier d’où WebAdmin, SSH, User Portal et VPN Portal sont réellement accessibles.

Le chemin du menu est System > Administration > Device access.

Il y a deux domaines pertinents :

• ACL de service local : Accès de base par zone, par exemple LAN, VPN ou WAN.
• Règle d’exception ACL de service local : exceptions ciblées pour les réseaux sources individuels, les hôtes ou l’accès au support.

Pour les environnements de production, il ne faut généralement pas activer WebAdmin et SSH pour la zone WAN. Il vaut mieux se limiter à :

• une IP de gestion,
• un réseau d’administration,
• un réseau VPN,
• un hébergeur support dédié,
• ou une exception FQDN/hôte clairement définie.

Si SSH est requis, l’accès doit être en outre restreint et idéalement utilisé avec une clé publique. Cela convient à Connecter Sophos Firewall via SSH.

⚠️ MFA protège contre le vol d’identifiants, mais pas contre les services inutilement exposés. WebAdmin, SSH et les portails ne doivent jamais être plus largement accessibles que nécessaire.

Sélectionnez la variante MFA et le déploiement du plan

Avant l’activation, vous devez décider si la fonction Sophos OTP locale est suffisante ou si une plateforme MFA existante doit être intégrée via RADIUS, NPS ou SSO. Le déploiement est ensuite planifié de manière à ce que les administrateurs et les utilisateurs ne se verrouillent pas.

Exigences

Avant l’activation, vous devez vérifier :

• L’heure du système du pare-feu est correcte.
• Un serveur NTP fonctionnel est configuré.
• Les utilisateurs existent localement, via AD, LDAP, RADIUS ou tout autre service d’authentification pris en charge.
• Les utilisateurs concernés peuvent se connecter au User Portal ou au service correspondant.
• Au moins un accès administratif de secours est disponible.

⚠️ Il faut être particulièrement prudent avec Admin-MFA. MFA ne doit pas être activé directement pour tous les administrateurs sans avoir préalablement vérifié un utilisateur test, un deuxième administrateur et un accès de secours. Une configuration incorrecte du MFA peut entraîner le verrouillage de votre accès au WebAdmin ou au VPN Portal.

Sophos MFA ou MFA externe ?

Il existe essentiellement deux manières d’utiliser MFA sur le Sophos Firewall : vous utilisez la fonction OTP locale du pare-feu ou vous connectez une solution MFA externe via RADIUS ou SSO. Les deux variantes sont légitimes, mais résolvent des problèmes différents.

Le MFA local du Sophos Firewall gère les tokens OTP directement sur le pare-feu. Il s’agit généralement du moyen le plus rapide de sécuriser le WebAdmin, les portails et l’accès à distance avec un deuxième facteur. Aucune infrastructure RADIUS ou fournisseur d’identité supplémentaire n’est requis.

Avantages du MFA de Sophos :

• Aucune intégration supplémentaire de RADIUS ou de fournisseur d’identité requise.
• Déploiement rapide pour les utilisateurs locaux et les petits environnements.
• Les jetons peuvent être générés et gérés directement sur le pare-feu.
• Convient pour l’accès à distance WebAdmin, User Portal, VPN Portal, SSL VPN et l’accès à distance IPsec.

Inconvénients :

• Les utilisateurs devront peut-être conserver une application ou un jeton Authenticator supplémentaire.
• Le jeton est distinct de Microsoft 365, Entra ID ou d’autres processus MFA existants.
• En fonction du masque de connexion, il n’y a pas de champ OTP séparé.
• Les utilisateurs doivent saisir directement le mot de passe et le token l’un après l’autre sur certains portails.

Dans des environnements plus grands, une solution externe MFA peut s’avérer plus logique. Les variantes typiques sont RADIUS avec un backend compatible MFA, Microsoft NPS avec l’extension Entra-MFA ou un autre système MFA compatible RADIUS. Selon la version SFOS et le modèle d’accès à distance, Microsoft Entra ID SSO pour WebAdmin, VPN Portal ainsi que Sophos Connect avec SSL VPN ou IPsec VPN peuvent également s’adapter.

La distinction importante est la suivante : Entra ID n’est pas simplement le même mécanisme que la fonctionnalité locale Sophos OTP. Soit Entra MFA est indirectement intégré au flux d’authentification via RADIUS/NPS, soit un modèle SSO est utilisé si le service et le client utilisés le prennent en charge.

Les utilisateurs trouvent souvent un MFA externe plus pratique car ils utilisent le même MFA que pour Microsoft 365 ou d’autres services professionnels. Cela ne crée pas un deuxième monde MFA avec une application supplémentaire, un jeton supplémentaire et un comportement de connexion différent.

L’inconvénient d’une solution externe est sa plus grande complexité. RADIUS, les groupes, les délais d’attente, le comportement de challenge et le repli doivent être soigneusement planifiés et testés.

• Sophos OTP sur le firewall: Mise en place rapide, sans infrastructure supplémentaire et gestion directe dans SFOS. En contrepartie, un token supplémentaire est créé, séparé de Microsoft 365 ou Entra ID; selon le portail, le mot de passe et l’OTP doivent être saisis dans le même champ. Typique des petits environnements, des utilisateurs locaux et du durcissement rapide de WebAdmin ou VPN.
• MFA externe via RADIUS: Une plateforme MFA existante peut être utilisée et les processus utilisateurs centraux sont conservés. En contrepartie, RADIUS, NPS, les timeouts, les groupes et le comportement client doivent être testés proprement. Typique des environnements AD/Microsoft 365 avec de nombreux utilisateurs VPN.
• Entra ID SSO: Login Microsoft familier, meilleure expérience utilisateur et processus d’identité centralisés. Tous les scénarios ne sont pas utilisables de manière identique; cela dépend de la version SFOS, du service et du client. Typique pour WebAdmin, VPN Portal et Sophos Connect lorsque SSO correspond au modèle d’exploitation.

Aide à la décision

La bonne variante MFA dépend moins du pare-feu que de l’opération d’identité existante.

• Petit environnement avec des utilisateurs de pare-feu locaux: La fonction OTP de Sophos est souvent suffisante.
• Environnement Microsoft 365 avec Entra-MFA existant: Validez le MFA externe via RADIUS/NPS ou Entra-ID SSO afin que les utilisateurs n’aient pas à gérer deux mondes MFA.
• De nombreux prestataires externes: Groupe d’utilisateurs propre, obligation MFA, durée claire et révision régulière.
• Accès administrateur critique: MFA plus Device Access, combinent la gestion du réseau, l’administration de secours et la journalisation.
• De nombreux utilisateurs d’accès à distance: Planifiez le groupe pilote, le processus d’assistance, la réinitialisation des jetons et les tests clients avant un déploiement à grande échelle.

Si Microsoft Entra ID est prévu directement comme source SSO pour VPN Portal ou Sophos Connect, Configurer Microsoft Entra ID SSO pour Sophos Connect et VPN Portal convient également. Il s’agit d’un modèle de fonctionnement différent de la fonction Sophos OTP classique et ne doit pas être assimilé à RADIUS-MFA non testé.

Plan MFA

Pour les environnements de production, il est généralement préférable d’activer d’abord MFA pour un petit groupe pilote.

Cette commande a fait ses preuves :

1. Préparez les utilisateurs de test ou le groupe pilote.
2. Vérifiez NTP et l’heure du pare-feu.
3. Activez MFA pour la zone de test.
4. Testez l’enregistrement avec l’application Authenticator.
5. Ensuite seulement, intégrez des groupes d’utilisateurs supplémentaires.

Un groupe d’utilisateurs distinct est recommandé pour les fournisseurs de services. Cela permet de forcer spécifiquement MFA et de supprimer l’accès ultérieurement plus facilement.

Pour les administrateurs, vous devez également prévoir :

• Qui est le premier administrateur du test ?
• Y a-t-il un deuxième administrateur avec un accès professionnel ?
• L’accès est-il possible via un réseau de gestion ou VPN ?
• Le admin par défaut est-il protégé séparément ?
• La manière dont un jeton perdu est remplacé est-elle documentée ?

Activez MFA et configurez les jetons

Lorsque les conditions préalables, les groupes et les solutions de secours sont clarifiés, MFA peut d’abord être activé pour un groupe pilote. Ce n’est qu’après des tests réussis que vous pourrez inclure des utilisateurs ou des administrateurs supplémentaires.

Activez le MFA sur le Sophos Firewall

Les paramètres MFA se trouvent dans les versions SFOS actuelles sous Authentication > Multi-factor authentication. Dans les anciennes interfaces ou selon la navigation, la section peut encore apparaître sous Configure > Authentication > Multi-factor authentication.

1. Connectez-vous au WebAdmin du Sophos Firewall.
2. Ouvrez Authentication.
3. Passez à l’onglet Multi-factor authentication.
4. Sous One-time password (OTP), sélectionnez à qui MFA doit s’appliquer:
   • No OTP: MFA est désactivé.
   • All users: MFA s’applique à tous les utilisateurs.
   • Specific users and groups: MFA s’applique uniquement aux utilisateurs ou groupes sélectionnés.
5. Activez Generate OTP token with next sign-in si les utilisateurs doivent configurer eux-mêmes leur token lors de leur prochaine connexion.
6. Sous Require MFA for, sélectionnez les services pour lesquels MFA est requis.
7. Enregistrez la configuration avec Apply.

Les options typiques sous Exiger MFA pour sont :

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

Selon l’environnement, MFA peut être appliqué différemment pour des services individuels ou des groupes d’utilisateurs. Pour les administrateurs, MFA doit être appliqué de manière cohérente, mais testé d’abord de manière contrôlée.

Si des applications web sont publiées via Web Server Protection, une stratégie d’authentification WAF adaptée est également nécessaire. La procédure est décrite dans Sécuriser Sophos Firewall WAF avec MFA.

Préparer le déploiement et les opérations

Le MFA n’est pas seulement un commutateur dans le pare-feu. Après l’activation, le comportement de connexion, les questions d’assistance et le changement d’accès d’urgence. Par conséquent, avant le déploiement à grande échelle, il convient de savoir clairement qui émet les jetons, qui réinitialise les jetons perdus et quelle sera la réaction en dehors des heures de bureau.

Ces points se sont révélés utiles pour le fonctionnement :

• Testez un groupe pilote avec de vrais utilisateurs, pas seulement des administrateurs.
• Documentez un deuxième administrateur et brisez l’accès au verre.
• Informer le service d’assistance du comportement du mot de passe + OTP.
• Définissez le processus de réinitialisation des jetons pour les nouveaux smartphones ou les appareils perdus.
• Vérifiez Log Viewer et les journaux d’authentification après le déploiement.
• Testez le MFA externe via RADIUS avec des délais d’attente réalistes.
• Vérifiez régulièrement les exceptions Device Access et ACL.

Surtout avec l’accès à distance, vous devez tester MFA avec les règles VPN, les groupes d’utilisateurs et les profils client concernés. Une connexion WebAdmin fonctionnelle ne prouve pas automatiquement que SSL VPN, IPsec Remote Access ou Sophos Connect fonctionnent de la même manière.

Planifiez le repli et le bris de glace

MFA augmente la sécurité, mais peut également verrouiller les administrateurs légitimes si le jeton, l’heure, le serveur d’authentification ou les groupes ne correspondent pas. C’est pourquoi un plan de repli est nécessaire avant l’activation.

Au moins ces points doivent être documentés :

• Qui dispose d’un deuxième accès administrateur testé ?
• L’accès est-il possible depuis un réseau de gestion ou un administrateur VPN ?
• Le admin local par défaut est-il protégé en tant que compte d’urgence mais n’est-il pas utilisé pour un usage quotidien ?
• Comment réinitialiser un token OTP perdu ou cassé ?
• Qui peut réinitialiser les jetons pour les administrateurs ?
• Comment réagissez-vous en dehors des heures de bureau ?
• Existe-t-il une sauvegarde en cours avant le changement ?Cette solution de repli ne doit pas signifier que l’accès administrateur non protégé reste accessible en permanence depuis Internet. Il est préférable d’avoir un compte d’urgence avec une documentation claire, un chemin d’accès étroit et des révisions régulières.

MFA pour l’administrateur par défaut

L’utilisateur local par défaut admin constitue un cas particulier. MFA pour cet utilisateur n’est pas activé directement dans l’onglet Authentification multifacteur.

Le chemin du menu est System > Administration > Device access.

Là, vous pouvez activer MFA pour l’administrateur par défaut. Vous ne devriez le faire que si :

• l’heure système est correcte,
• un deuxième administrateur a été testé,
• accéder aux œuvres via un réseau de gestion fiable,
• et il est clair comment récupérer l’accès administratif en cas d’urgence.

Ce qui suit s’applique au admin par défaut : ne le désactivez pas, ne le rendez pas accessible sans protection sur Internet et ne l’utilisez pas en tant qu’utilisateur quotidien normal. Il s’agit d’un compte brisé ou d’un compte d’urgence.

Les autres administrateurs ne doivent pas supposer qu’ils peuvent modifier ou supprimer le jeton MFA du admin par défaut comme un jeton utilisateur normal. Cet accès doit être consciemment planifié et testé via votre propre chemin d’accès à l’appareil.

Configurer des jetons pour les utilisateurs

Une fois activé, l’utilisateur doit configurer son deuxième facteur. Si Générer un jeton OTP lors de la prochaine connexion est actif, l’utilisateur se connecte au User Portal ou au VPN Portal et scanne le code QR avec une application Authenticator.

Les applications appropriées incluent :

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Autres applications TOTP compatibles Authenticator.

Le code généré est temporel. Si l’heure sur le pare-feu ou le smartphone diffère considérablement, la connexion échouera.

Si le User Portal est désactivé, les utilisateurs risquent de ne pas pouvoir configurer eux-mêmes leurs jetons. Dans ce cas, vous devez soit mettre à disposition le portail de manière contrôlée, soit préparer les jetons de manière administrative.

Algorithme de jeton et changement d’application

Sophos Firewall prend en charge les algorithmes de hachage SHA1, SHA256 et SHA512 pour les tokens OTP. Les versions SFOS antérieures à 22.0 utilisent SHA1 pour MFA; à partir de SFOS 22.0, les nouveaux tokens ou les tokens migrés doivent être testés avec SHA256 ou SHA512. Ce réglage ne doit pas être appliqué à l’aveugle: l’algorithme choisi doit être compatible avec l’application d’authentification utilisée.

Sophos indique explicitement qu’une application doit prendre en charge l’algorithme sélectionné. Si une application ne prend pas correctement en charge SHA256 ou SHA512, le code QR peut être scanné, mais la connexion échoue quand même. L’algorithme doit donc faire partie du test pilote, surtout lorsque Microsoft Authenticator, TOTP dans un gestionnaire de mots de passe, Google Authenticator ou Sophos Intercept X for Mobile sont utilisés en parallèle.

Ces points sont importants pour le fonctionnement :

• Ne planifiez plus de nouveaux jetons avec les anciennes hypothèses d’application.
• Utilisez une application Authenticator qui prend en charge l’algorithme de hachage sélectionné.
• Si vous changez d’application ou perdez votre smartphone, supprimez l’ancien token et faites régénérer le code QR.
• N’utilisez des jetons matériels que si l’algorithme, le pas de temps et le secret peuvent être gérés correctement.
• Testez un groupe pilote avant une migration SHA256/SHA512 au lieu de changer tous les jetons en même temps.
• Supprimer et recréer les tokens SHA1 existants de manière contrôlée lors d’une migration.

L’ancienne application Sophos Authenticator ne doit plus être planifiée comme nouvelle application par défaut; selon Sophos, elle est End of Life depuis le 31 juillet 2022. Dans de nombreux environnements, Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password ou Bitwarden sont des options plus réalistes. La marque de l’application compte moins que la compatibilité entre TOTP, algorithme de hachage, sauvegarde/restauration et processus d’assistance.

Remarque importante concernant le mot de passe et les jetons

Selon le service Sophos, il n’existe pas de champ de formulaire distinct pour le code OTP. Cela conduit toujours à de la confusion, notamment avec le VPN Portal ou les connexions par accès à distance. Dans ces cas-là, l’utilisateur doit souvent saisir le mot de passe et le code OTP l’un après l’autre.

Exemple :

Mot de passe: MonMotDePasseSur
Code OTP:     123456
Saisie:       MonMotDePasseSur123456

Cela doit être clairement communiqué aux utilisateurs avant le déploiement. Sinon, l’utilisateur aura l’impression que le mot de passe est incorrect, même s’il manque uniquement le code OTP.

Ce comportement doit être testé et documenté avant le déploiement car il est perçu différemment selon le service et le masque de connexion.

Opération de test et de contrôle

Un test WebAdmin réussi ne suffit pas. Chaque surface de connexion concernée doit être testée séparément car le portail, le client VPN, le groupe d’utilisateurs et le serveur d’authentification peuvent réagir différemment.

Tester la connexion

MFA doit d’abord être testé avec un utilisateur qui n’est pas le seul administrateur.

Ces points sont à vérifier :

• Inscription sur WebAdmin.
• Inscription sur VPN Portal.
• Connectez-vous au service d’accès à distance.
• Comportement en cas de code OTP incorrect.
• Comportement après l’expiration d’un code OTP.
• Accès avec un utilisateur qui ne fait pas partie du groupe MFA.
• Connectez-vous avec le mot de passe et le code OTP ci-joint.
• Accès via des règles ACL programmées.

Ce n’est que lorsque ces tests seront réussis que MFA pourra être déployé auprès d’autres groupes.

Matrice de test par service

Un test MFA ne doit pas consister uniquement en une connexion WebAdmin réussie. Selon le service, d’autres portails, groupes, profils et fichiers journaux s’appliquent. Cette matrice permet d’examiner séparément les cas les plus importants :

• WebAdmin: connexion d’un administrateur avec OTP correct et incorrect. L’OTP correct autorise l’accès, l’OTP incorrect est rejeté proprement et journalisé.
• Default admin: tester le chemin MFA séparé sous System > Administration > Device access. Le compte d’urgence est protégé, mais un chemin Break-Glass documenté reste disponible.
• User Portal: l’utilisateur configure lui-même le token. Le QR code n’apparaît que pour les utilisateurs autorisés et le token fonctionne ensuite à la connexion.
• VPN Portal: l’utilisateur se connecte avec mot de passe et OTP. La connexion fonctionne avec un format de saisie documenté et est visible dans Log Viewer.
• SSL VPN / Sophos Connect: importer un profil ou se reconnecter. MFA est demandé dans le vrai client, pas seulement dans le navigateur.
• IPsec Remote Access: vérifier le groupe et la méthode d’authentification. MFA s’applique au même groupe que celui autorisé dans la configuration Remote Access.
• MFA externe via RADIUS: tester push, challenge ou token avec un vrai client. Le timeout est suffisant, le comportement de challenge correspond au client et les erreurs sont visibles sur le serveur RADIUS.

Chaque test doit également vérifier si Device Access ou une règle ACL de service local autorise intentionnellement le service. Si le jeton fonctionne mais que le portail est accessible depuis le mauvais réseau, la configuration MFA n’est qu’une partie du problème résolu.

Journaux et contrôle opérationnel

Après le déploiement, vous devez vérifier si les événements MFA peuvent être tracés pendant le fonctionnement. Ceci est important pour les dossiers de support, les examens de sécurité et la réponse aux incidents.

Points de contrôle utiles :

• Vérifiez les événements d’authentification dans Log Viewer.
• Distinguez les connexions échouées d’un mot de passe incorrect, d’un OTP incorrect et d’un OTP expiré.
• Documenter les tests du portail VPN et d’accès à distance avec l’heure et l’utilisateur.
• Pour les RADIUS externes, vérifiez également le serveur RADIUS, les journaux NPS ou les journaux du fournisseur d’identité.
• Pour un stockage plus long, prévoyez Central Reporting ou Syslog/SIEM.

Pour les fichiers journaux locaux et le mappage de service, Dépannage Sophos Firewall : Services et journaux convient. Si l’authentification et les événements du portail doivent être évalués à long terme, Sophos Firewall envoie Syslog à SIEM convient.

Dépannage

Le code OTP n’est pas accepté

Vérifiez d’abord l’heure système du pare-feu et l’heure du smartphone. TOTP dépend du temps. Même un écart important peut entraîner le rejet de codes valides.

Vous pouvez vérifier les tokens émis sous Authentication > Multi-factor authentication. Si un seul token échoue systématiquement, il ne faut pas modifier immédiatement toute la configuration MFA. Vérifiez d’abord la dérive temporelle du token, l’application utilisée, l’algorithme de hachage et le pas de temps.

L’utilisateur ne voit pas le code QR

L’utilisateur doit être éligible pour MFA et se connecter au bon portail. De plus, il convient de vérifier si l’utilisateur est trouvé via la source d’authentification attendue.

Si le User Portal est désactivé, l’utilisateur risque de ne pas pouvoir configurer le jeton lui-même. Le portail doit alors être rendu temporairement accessible ou le token doit être créé administrativement.

Le portail n’est pas accessible via Device Access

Si les utilisateurs ne peuvent pas configurer leur token même si MFA a été activé correctement, il ne faut pas supprimer le token au préalable. Souvent, le portail requis n’est pas accessible à partir du réseau actuel via System > Administration > Device access ou une Local Service ACL rule.

Vérifiez d’abord :

• Quel portail est utilisé pour la configuration des jetons ?
• De quelle zone ou source provient l’utilisateur ?
• L’accès est-il intentionnellement autorisé ou accidentellement bloqué ?
• Existe-t-il une exception ACL plus étroite au lieu d’une version large ?

L’administrateur est verrouillé

Dans ce cas, utilisez l’accès de secours préparé. Si aucune solution de secours n’existe, l’accès doit être évalué via la console, le support ou les chemins de récupération en fonction de la situation.

MFA ne fonctionne pas pour l’accès à distance

Vérifiez si la configuration de l’accès à distance utilise le même groupe d’utilisateurs pour lequel MFA a été activé. Souvent, l’erreur ne vient pas de MFA lui-même, mais de différents groupes dans VPN et des règles d’authentification.

Les profils clients doivent également correspondre à la configuration actuelle. Après avoir apporté des modifications à VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO ou RADIUS, les profils Sophos Connect concernés doivent être réimportés ou redistribués.

L’utilisateur saisit uniquement le mot de passe

Si un champ OTP distinct n’est pas affiché, l’utilisateur doit saisir le mot de passe et le code OTP l’un après l’autre. Il s’agit de l’un des cas de support les plus courants après l’activation de Sophos OTP.

Le MFA externe ne fonctionne pas de manière fiable

Pour les solutions MFA basées sur RADIUS, les délais d’attente, le comportement de défi et les groupes doivent s’adapter parfaitement. Si Push-MFA, Call-MFA ou des réponses de défi sont utilisés, vous devez tester l’ensemble du processus de connexion avec le client concerné.

MFA a été activé pour le mauvais groupe

Si MFA fonctionne pour certains utilisateurs et pas pour d’autres, vous devez d’abord comparer les groupes sur le plan technique. Non seulement les noms d’affichage visibles sont pertinents, mais également les groupes réellement importés ou correspondants à partir de AD, LDAP, RADIUS ou Entra ID. Un utilisateur peut s’authentifier avec succès sans toutefois se retrouver dans le groupe pour lequel MFA est requis.

Liste de contrôle opérationnel et recommandation

Après l’activation technique, le MFA nécessite un processus de fonctionnement simple : qui réinitialise les jetons, qui vérifie les journaux et comment vérifier que les portails ne sont pas inutilement largement accessibles ?

Liste de contrôle des opérations

• Heure système et NTP vérifiés.
• Groupe pilote défini et testé.
• MFA non activé directement pour tous les administrateurs en même temps.
• Deuxième accès administrateur et bris de vitre documenté.
• Device Access et Local Service ACL testés pour WebAdmin, User Portal, VPN Portal et SSL VPN.
• Accès à partir de réseaux sources autorisés et interdits testés.
• Utilisateur informé du comportement mot de passe + OTP.
• Processus de réinitialisation des jetons documenté pour les smartphones perdus.
• Application Authenticator, algorithme de hachage et migration de jetons documentés.
• Accès à distance testé avec de vrais clients et profils actuels.
• Les délais d’attente RADIUS/Entra sont testés si un MFA externe est utilisé.
• Journaux et stockage central vérifiés.

Recommandation opérationnelle

MFA devrait être la norme pour l’accès administratif. MFA est particulièrement important pour WebAdmin, VPN Portal et tous les utilisateurs disposant d’une autorisation d’accès à distance.

Pour les petits environnements, la fonction OTP de Sophos est souvent suffisante. Dans les environnements Microsoft 365 ou Entra ID, un MFA externe sur RADIUS peut être plus pratique car les utilisateurs n’ont pas besoin d’apprendre un deuxième monde MFA.

Quelle que soit la variante MFA, les principes suivants s’appliquent : limitez d’abord l’accès avec des règles ACL, testez soigneusement Admin-MFA, informez les utilisateurs du mot de passe + du jeton, puis déployez-le à grande échelle.

FAQ