Aller au contenu
Avanet

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

Sophos Firewall

Pour la fonction OTP locale, on ouvre Authentication > Multi-factor authentication, on sélectionne d’abord Specific users and groups, on active les services nécessaires et on teste l’ensemble avec un groupe pilote. All users ne doit être utilisé qu’après la réussite des tests.

MFA protège WebAdmin, VPN Portal et l’accès à distance contre l’utilisation d’un mot de passe volé comme seul moyen d’authentification. Cette protection ne remplace toutefois ni des règles d’accès restrictives ni un accès d’urgence testé. Cet article couvre donc l’activation sécurisée, le choix de l’application, la récupération et le dépannage.

La procédure principale configure le Sophos OTP local. RADIUS et Entra ID SSO sont comparés plus loin comme solutions alternatives.

Activer Sophos OTP en toute sécurité

Les procédures suivantes distinguent les fonctions MFA documentées de SFOS 22 et de SFOS 23. En particulier, Share QR code et la durée de validité du QR décrite ne doivent pas être transposés à SFOS 22. Les restrictions concernant les applications se rapportent à la procédure d’enregistrement Sophos documentée, et non indistinctement à toutes les versions actuelles des applications. Avant le déploiement, le build SFOS installé, le système d’exploitation mobile, la version précise de l’application et chaque service requis sont donc vérifiés avec le groupe pilote.

Avant l’activation

Avant toute modification, les points suivants doivent être clarifiés :

  • Le pare-feu utilise une heure correcte sous Administration > Time, idéalement via NTP.
  • Les utilisateurs et les groupes sont disponibles localement ou par AD, LDAP ou un autre serveur d’authentification.
  • Un groupe pilote et un second administrateur testé existent.
  • La console et la procédure de récupération du admin par défaut sont connues.
  • Une sauvegarde récente et une procédure documentée de réinitialisation des tokens sont disponibles.

Pour un Active Directory classique, Ajouter Active Directory à Sophos Firewall explique la configuration de la source d’utilisateurs.

Sous Administration > Device access, on définit les zones depuis lesquelles WebAdmin, User Portal, VPN Portal et les autres services locaux sont accessibles. Les Local service ACL exception rules limitent encore l’accès aux réseaux de gestion, aux réseaux VPN ou aux adresses sources connues. Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access détaille ce durcissement.

SSH ne fait pas partie des services protégés par Sophos OTP. Il doit être limité par Device Access et utiliser si possible une clé publique ; la procédure est décrite dans Se connecter à Sophos Firewall par SSH.

⚠️ MFA réduit le risque lié aux mots de passe compromis, mais ne diminue pas la surface d’attaque d’un service accessible publiquement. WebAdmin, SSH et les portails ne doivent jamais être exposés plus largement que nécessaire.

Avant les tests négatifs, on vérifie également Administration > Admin and user settings > Login security > Block login. Plusieurs échecs volontaires peuvent bloquer l’adresse IP source pour WebAdmin, CLI, VPN Portal et User Portal, et ainsi exclure aussi un administrateur de secours utilisant le même réseau. Une seconde source ou l’accès à la console doit donc être disponible.

Configurer MFA pour un groupe pilote

  1. Se connecter à WebAdmin et ouvrir Authentication > Multi-factor authentication.
  2. Sous One-time password (OTP), sélectionner d’abord Specific users and groups.
  3. Ouvrir Add users and groups, sélectionner le groupe pilote et appliquer la sélection.
  4. Activer Generate OTP token with next sign-in si une application d’authentification est utilisée. Sous SFOS 23, sélectionner aussi Share QR code : Email envoie le code QR à l’adresse e-mail de l’utilisateur lors de sa prochaine connexion à VPN Portal ou User Portal. Portals l’affiche dans User Portal et VPN Portal après la prochaine connexion à VPN Portal, User Portal ou WebAdmin. Ce choix ne concerne pas l’assistant de l’admin par défaut décrit plus bas.
  5. Sous Require MFA for, sélectionner uniquement les interfaces de connexion réellement nécessaires.
  6. Sous OTP hash algorithm, choisir un algorithme pris en charge par l’application prévue.
  7. Ne modifier les paramètres facultatifs OTP timestep settings que si l’application accepte le même pas de temps ; la valeur par défaut est de 30 secondes.
  8. Enregistrer avec Apply.
Sophos Firewall Authentication > Multi-factor authentication avec sélection des utilisateurs, services protégés et algorithme de hachage OTP
Cet écran définit les utilisateurs MFA, les services protégés et l’algorithme de hachage OTP. Les valeurs affichées All users et SHA1 ne constituent pas des recommandations de déploiement.

Après Apply, un utilisateur pilote termine immédiatement la procédure : selon le service sélectionné, il se connecte d’abord à User Portal ou VPN Portal avec son seul mot de passe, enregistre le code QR ou la clé Base32 dans l’application d’authentification, puis ouvre une nouvelle session avec <password><passcode>. Un code volontairement incorrect doit être refusé et la tentative doit apparaître dans Log viewer. All users ne peut être envisagé qu’après ce test positif et négatif.

Les options utilisateur signifient :

  • No OTP: MFA est désactivée.
  • All users: MFA s’applique à tous les utilisateurs ; à utiliser seulement après le pilote.
  • Specific users and groups: MFA s’applique uniquement aux comptes ou groupes sélectionnés.

Pour les utilisateurs authentifiés par un serveur externe, le retrait d’un groupe MFA ne prend pas effet immédiatement lors de la première connexion suivante. Sophos exige encore une connexion avec MFA ; l’OTP ne disparaît que lors des connexions ultérieures. Une modification de groupe est donc vérifiée avec une nouvelle session et au moins deux connexions contrôlées.

Lorsque Generate OTP token with next sign-in est activé, les utilisateurs enregistrent une application logicielle lors de leur prochaine connexion. User Portal est alors automatiquement sélectionné comme service MFA. Lorsque cette option est désactivée, les tokens matériels ou gérés manuellement sont attribués sous Issued tokens.

Avec Email, vérifier avant le pilote que l’adresse correcte de l’utilisateur est renseignée et que la livraison fonctionne. Le code QR contient le secret du token : protéger l’accès à la boîte aux lettres et ne pas inclure le code QR ni la clé Base32 dans des tickets ou des captures d’écran non protégés. En l’absence de livraison, vérifier d’abord l’adresse et l’envoi des e-mails, sans déclencher de blocage de connexion par des tentatives de connexion infructueuses répétées. Pour un pilote sans livraison par e-mail, Portals est l’alternative documentée ; l’accès au portail doit être possible depuis le réseau prévu.

Choisir les services de manière réfléchie

Sous SFOS 22, les services suivants sont disponibles sous Require MFA for :

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

MFA pour User Portal s’applique également à Captive Portal et aux Client Authentication Agents. Les utilisateurs d’accès à distance doivent d’abord enregistrer leur token via VPN Portal ou User Portal.

Pour WAF, la sélection du service ne suffit pas. À partir de SFOS 22, Webserver Protection, une Authentication Policy basée sur un formulaire et son affectation à la règle WAF sont nécessaires. La procédure complète est décrite dans Sécuriser Sophos Firewall WAF avec MFA.

Choisir le modèle MFA adapté

Sophos OTP local

Sophos OTP gère les tokens directement sur le pare-feu et ne nécessite aucune infrastructure RADIUS ou de fournisseur d’identité supplémentaire. Il convient particulièrement aux utilisateurs locaux normaux, aux petits environnements et au durcissement rapide de WebAdmin ou de l’accès à distance.

La contrepartie d’un déploiement simple est un token distinct des processus Microsoft 365 existants. Les utilisateurs et le support doivent connaître l’enregistrement de l’application, la saisie du mot de passe plus OTP et la procédure de changement d’appareil.

RADIUS ou Entra ID SSO

Une plateforme MFA existante peut mieux s’intégrer à la gestion centralisée des identités via RADIUS ou SSO. Elle requiert toutefois des tests propres à chaque service :

  • VPN Portal ne prend pas en charge RADIUS avec MFA par challenge.
  • Sophos Connect ne prend pas en charge les challenges OTP. Le client envoie ensemble le mot de passe et l’OTP au format passwordotp, mais prend en charge MFA par appel et notification push.
  • User Portal et WebAdmin prennent également en charge MFA par challenge.
  • Avec Entra ID SSO, MFA s’effectue chez le fournisseur d’identité ; la MFA Sophos OTP locale ne peut pas être ajoutée à la même connexion SSO.
  • Entra SSO avec Sophos Connect exige au minimum la version 2.4 du client sous Windows. WebAdmin SSO n’est pas disponible sur l’appareil auxiliaire HA.

Pour l’accès à distance, consulter le guide dédié Configurer Microsoft Entra ID SSO pour Sophos Connect et VPN Portal. Si Entra doit plutôt contrôler la connexion WebAdmin et les rôles d’administrateur, Entra ID SSO pour WebAdmin de Sophos Firewall décrit le Role mapping, le moindre privilège, la connexion pilote et l’accès local de secours.

Sophos Connect ou SSL VPN : quelle solution choisir ? aide à choisir le modèle d’accès à distance ; avant le déploiement, il faut également vérifier la version du client Sophos Connect.

Quel que soit le modèle, on commence par un groupe pilote. Les autres utilisateurs ne sont ajoutés qu’après validation de WebAdmin, des portails, des véritables clients VPN, des groupes, des délais d’attente, des journaux et de la solution de secours.

Configurer les tokens et l’application d’authentification

Enregistrer et gérer les tokens

Lorsque Generate OTP token with next sign-in est activé, l’utilisateur se connecte à VPN Portal ou User Portal et enregistre le code QR dans une application compatible. Sous SFOS 22, le code QR est affiché ; les administrateurs peuvent aussi enregistrer le token dans WebAdmin si MFA y est imposé. Sous SFOS 23, la distribution suit Share QR code : avec Email, utiliser le code QR reçu par e-mail ; avec Portals, celui affiché dans les portails. Une connexion WebAdmin peut déclencher l’affichage dans les portails avec Portals, mais pas l’envoi par e-mail. L’enregistrement concerne uniquement les utilisateurs et groupes auxquels MFA est appliqué.

Pour l’enregistrement initial sous SFOS 23 avec Generate OTP token with next sign-in sur ON, la règle suivante s’applique aux utilisateurs MFA sélectionnés : le code QR généré expire s’il n’est pas utilisé pour se connecter dans les 24 heures suivant sa génération. Pour en générer un nouveau, l’utilisateur se connecte à VPN Portal ou User Portal avec son seul mot de passe ; le nouveau code QR est distribué selon Email ou Portals. L’enregistrer ensuite dans l’application et vérifier une nouvelle connexion avec <password><passcode>. Cette durée du QR est distincte de la fenêtre de 300 secondes du premier code. Le flux ne s’applique ni à un token émis avec le statut OFF ni à une nouvelle attribution manuelle de seed ; il n’est présumé ni pour SFOS 22 ni pour tous les flux de l’assistant de l’admin par défaut.

Sous Authentication > Multi-factor authentication > Issued tokens, les tokens émis peuvent être contrôlés, désactivés temporairement, supprimés ou ajoutés manuellement. On peut également y générer des codes à usage unique supplémentaires et vérifier ou synchroniser le décalage horaire d’un token.

Passer le statut du token à OFF empêche l’utilisateur de se connecter ; cela n’autorise pas un accès avec le seul mot de passe. Ce n’est ni une suppression suivie d’un nouvel enregistrement ni l’exemption MFA pour une seule connexion sous CLI Main Menu > 2. System Configuration.

En cas de perte du smartphone ou de changement d’application, vérifier d’abord l’identité de l’utilisateur. Juste avant la suppression, vérifier sous Authentication > Multi-factor authentication que Generate OTP token with next sign-in est sur ON ; sous SFOS 23, définir aussi Share QR code sur Email ou Portals. Si le mode manuel OFF est volontaire, préparer plutôt une nouvelle attribution manuelle avec un nouveau seed ; le flux QR automatique ci-dessous ne s’applique pas. Supprimer ensuite seulement l’ancien token sous Issued tokens. L’utilisateur se connecte une fois à VPN Portal ou User Portal avec son seul mot de passe et enregistre le nouveau code QR : SFOS 22 l’affiche, tandis que SFOS 23 l’envoie par e-mail ou l’affiche dans le portail selon le choix. Vérifier ensuite une nouvelle connexion avec <password><passcode>. Un ancien token ne doit pas continuer à exister en parallèle sans contrôle.

Pour ce flux de changement d’application ou de remplacement sous SFOS 23, le code QR expire s’il n’est pas utilisé pour se connecter dans les 24 heures suivant sa génération. Une nouvelle connexion avec le seul mot de passe génère un nouveau code QR, à nouveau distribué via Email ou Portals. Les 24 heures concernent le code QR, pas la fenêtre de 300 secondes du premier code expliquée plus bas. Cette durée n’est présumée ni pour SFOS 22 ni pour tous les flux de l’assistant de l’admin par défaut.

La liste peut également contenir des tokens préparés manuellement sans affectation à un utilisateur ; un utilisateur pourra leur être affecté ultérieurement. Les tokens affectés manuellement y figurent aussi, ainsi que ceux des utilisateurs et administrateurs ayant enregistré le code QR. Une entrée dans la liste ne prouve donc pas à elle seule qu’une connexion MFA a réussi : avant la remise, vérifier l’affectation à l’utilisateur, l’état du token et la connexion effective.

Après la suppression, le code d’accès de l’ancien token est invalide et ne doit pas être ajouté lors de la connexion d’enregistrement avec mot de passe uniquement. Une suppression ne peut pas être annulée en saisissant à nouveau l’ancien code ; la méthode de récupération sûre est une réémission contrôlée. Avant la suppression, vérifier donc l’accès au portail, la livraison ou la remise manuelle du seed, ainsi que la solution de secours. Pour plusieurs utilisateurs, procéder par étapes et valider chaque nouvel enregistrement avant de migrer le groupe suivant.

Provisionner manuellement un token matériel ou logiciel

En mode manuel également, commencer par configurer Specific users and groups avec le groupe pilote ainsi que les services requis sous Require MFA for, choisir l’algorithme compatible et le pas de temps, puis enregistrer avec Apply. Ensuite, dans la boîte de dialogue Add token (for hardware tokens), sélectionner OTP hash algorithm pour le token à créer avant de renseigner Secret, l’utilisateur et, le cas échéant, Use custom timestep, puis d’enregistrer avec Save. Le seul choix d’une valeur globale par défaut ne remplace ni l’affectation du token ni la connexion pilote ultérieure.

Si le pare-feu ne doit pas générer de code QR, Generate OTP token with next sign-in reste désactivé. Les tokens déjà enregistrés continuent de fonctionner ; pour les nouveaux utilisateurs, le seed est saisi manuellement sous Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). Le libellé du bouton est plus restrictif que sa fonction, car la même boîte de dialogue permet également de provisionner manuellement un token logiciel.

Sélectionner d’abord OTP hash algorithm et le timestep requis par le token concerné ou l’application d’authentification utilisée. Les règles suivantes s’appliquent à Secret :

  • Pour un token matériel, saisir la clé individuelle fournie par le fabricant.
  • Pour un token logiciel, utiliser un seed hexadécimal unique et suffisamment aléatoire. Si l’application exige Base32, convertir localement ce seed avec un outil hors ligne contrôlé.
  • Un seed de production ne doit jamais être saisi sur un site public de conversion ni placé dans un ticket, un e-mail non chiffré ou une commande shell conservée dans l’historique. Toute personne connaissant le seed peut générer des codes OTP valides.

Si le token concerné diffère du Default token timestep global, activer Use custom timestep uniquement pour ce token et saisir l’intervalle qu’il prend réellement en charge. Sans cette option, la valeur globale s’applique ; vérifier la compatibilité de l’application et du matériel avant d’enregistrer.

Sélectionner ensuite l’utilisateur prévu avec précision et enregistrer avec Save. Le token matériel ou le seed Base32 est remis une seule fois par un canal protégé. Tester ensuite un code correct et un code volontairement incorrect, puis synchroniser si nécessaire le décalage horaire sous Issued tokens. Si le seed a pu être divulgué, ne pas continuer à utiliser le token : le supprimer et en attribuer un avec un nouveau seed.

Automatisation via l’API : distinguer les paramètres de l’état des tokens

Dans une automatisation via l’API, OTPSettings et OTPTokens correspondent à deux tâches distinctes : les paramètres définissent le périmètre d’application de MFA, les services et les valeurs globales ; l’enregistrement d’un token concerne un seul token émis. Une modification des paramètres ne remplace ni l’affectation à un utilisateur, ni l’enregistrement, ni la connexion pilote.

Sous OTPSettings, utiliser les valeurs de commutation documentées 0 et 1, et non les libellés de l’interface graphique ou Enable/Disable :

  • otp désactive ou active OTP. allUsers=0 limite le périmètre aux utilisateurs ou groupes explicitement sélectionnés ; ce paramètre n’active pas lui-même OTP. Pour le pilote, conserver une sélection restreinte plutôt que de définir allUsers=1. L’exemple présente la sélection sous otpUsers/user, mais le tableau des paramètres ne définit aucun encodage d’identifiant utilisateur pour ce champ. Ne pas construire d’identités à partir de noms ou d’identifiants supposés.
  • tokenAutoCreation contrôle la génération automatique des tokens, et non l’état d’un token déjà émis. otpUserPortal, otpVPNPortal, otpSSLVPN, otpWebAdmin et otpIPsec correspondent à User Portal, VPN Portal, SSL VPN Remote Access, WebAdmin et IPsec Remote Access. Sélectionner uniquement les services nécessaires ; lors du contrôle, tenir compte de la sélection automatique de User Portal dans la procédure de l’interface graphique.
  • Seul SFOS 23 documente le champ facultatif qrCodeVia, avec exactement les valeurs email ou portal. Les libellés Email et Portals de l’interface graphique ne sont pas des valeurs littérales de l’API. Aucune valeur par défaut de l’API n’est documentée ; ce champ est absent de la référence SFOS 22.

Traiter séparément les valeurs temporelles : OTPSettings/defaultTimeStep est l’intervalle global des tokens, OTPSettings/maxTimeStepsInterval la fenêtre de vérification pour les utilisations courantes et OTPSettings/maxInitialTimeStepDiff la fenêtre lors de la première utilisation. En revanche, OTPTokens/timeStep est l’intervalle propre à chaque token. L’API indique respectivement 10–300 secondes, 0–10 pas de temps, 0–600 pas de temps et 10–300 secondes comme limites de validation. Il ne s’agit ni de recommandations d’exploitation ni de valeurs par défaut de l’API ; les colonnes des valeurs par défaut sont vides. Les valeurs par défaut de l’interface graphique décrites plus haut et la compatibilité des applications restent des questions distinctes.

Pour un token, active, autoCreated et lastLogin concernent son état, son origine et sa dernière connexion réussie, et non la sélection globale de MFA. Ne pas renseigner lastLogin ou autoCreated comme des champs obligatoires d’une automatisation. L’exemple de token n’est pas non plus un schéma d’import validé : il utilise OTPTokens/user, alors que le tableau indique userid. Dans l’aide MFA, Sophos exige un <tokenid/> vide pour l’import via l’API ; l’exemple de token le présente également, mais le tableau de l’API indique une longueur minimale de 1 caractère. Ne pas résoudre cette contradiction en inventant des identifiants ou en supposant un schéma d’écriture universellement valable.

XML-Delete n’est pas un import de token. La référence Delete OTP Token pour SFOS 22 et SFOS 23 identifie un token existant par tokenid ; la valeur documentée est une chaîne unique de 1–32 caractères. Avant une suppression, lire l’enregistrement du token sauvegardé depuis une vue actuelle et fiable, puis vérifier son identifiant et son affectation à l’utilisateur précisément prévu. Ni user, ni userid, ni le <tokenid/> vide de la procédure d’import ne remplacent cet identifiant de suppression. L’indication Mandatory: No du tableau n’autorise pas à omettre l’identifiant, à l’inventer ou à le déduire d’un nom d’utilisateur. Si l’identité ou le schéma adapté à la version ne sont pas clairs, ne pas procéder à la suppression : clarifier d’abord l’affectation ou le schéma.

Avant XML-Delete, l’accès de secours testé, l’accès de gestion et l’accès à la console restent disponibles ; la vérification de l’utilisateur et la préparation de la réémission automatique ou manuelle décrites plus haut s’appliquent sans changement. Les restrictions concernant l’administrateur par défaut restent également applicables. Après l’appel, relire l’inventaire des tokens et vérifier que seul l’ancien token précisément prévu a disparu et que les autres tokens sont restés inchangés. Procéder ensuite à la réémission préparée et vérifier une connexion MFA réussie dans une nouvelle session ; l’accès de secours reste disponible jusqu’à la validation. Une réponse ne remplace à elle seule ni ce contrôle de l’inventaire ni le test MFA.

La référence Delete répertorie 200 avec le symbole de message non résolu OTPTokenDeleted et 500 avec OTPTokenNotThere. Il s’agit d’indications documentaires, et non de messages confirmés à l’exécution ni de garanties concernant un statut HTTP, la répétabilité ou une nouvelle tentative automatique sûre. On n’en déduit ni une requête XML exécutable ni une enveloppe de requête.

L’import via l’API n’est pas équivalent à la boîte de dialogue manuelle Add token. Avant un import en production, vérifier la sauvegarde et l’accès autorisé à l’API, clarifier le schéma adapté à la version et ne pas stocker de seeds dans des journaux de requêtes non protégés. Contrôler ensuite les paramètres enregistrés, la sélection restreinte des utilisateurs, l’affectation des services et l’état des tokens, puis vérifier la connexion pilote décrite. Un appel API réussi ne constitue pas à lui seul une validation MFA.

Distribuer des codes à usage unique supplémentaires de manière contrôlée

Si l’accès à l’application ou au token matériel est temporairement indisponible, modifier l’utilisateur concerné sous Authentication > Multi-factor authentication > Issued tokens. Sous Additional codes, le bouton plus génère des codes supplémentaires ; Save les associe au token. Le pare-feu supprime automatiquement chaque code de la liste après son utilisation.

Vérifier l’identité de l’utilisateur avant de distribuer les codes. Les remettre une seule fois par un canal protégé exclusivement à cet utilisateur et ne pas les placer ensemble dans un ticket ou un e-mail non protégé. Les codes supplémentaires ne remplacent pas le renouvellement d’un token définitivement perdu ou potentiellement copié : supprimer l’ancien token et en enregistrer un nouveau avec un nouveau seed.

L’application et l’algorithme de hachage doivent être compatibles

SFOS 22 prend en charge SHA1, SHA256 et SHA512. Sophos recommande SHA256 ou SHA512, mais l’application doit prendre en charge l’algorithme sélectionné :

  • Sophos Intercept X for Mobile et Google Authenticator prennent en charge SHA256 et SHA512.
  • Microsoft Authenticator ne prend pas en charge ces deux algorithmes dans ce flux Sophos. Le scan du code QR peut réussir, mais la connexion échoue ensuite.
  • Duo Mobile et Okta Verify figurent parmi les applications citées par Sophos ; leur compatibilité avec le code QR et l’algorithme doit correspondre au système d’exploitation et à la configuration utilisés.
  • Les autres applications TOTP ne sont approuvées qu’après un véritable test pilote.

Sophos Intercept X for Mobile prend en charge un timestep personnalisé pour les tokens. La plupart des autres applications d’authentification ne prennent en charge que la valeur par défaut de 30 secondes ; la valeur globale n’est donc pas modifiée uniquement pour une application.

Sous iOS, le code QR Sophos ne peut pas être scanné avec Google Authenticator, Duo Mobile ou Microsoft Authenticator. Le compte doit être créé manuellement à l’aide de la clé Base32 affichée. Okta Verify exige un enregistrement Base32 manuel sous iOS et Android. Cela ne résout toutefois pas l’absence de prise en charge de SHA256/SHA512 par Microsoft Authenticator.

L’ancienne application Sophos Authenticator est arrivée en fin de vie le 31 juillet 2022 et ne doit plus être prévue pour les nouveaux déploiements.

Après une mise à niveau depuis une version antérieure à SFOS 22, il faut s’attendre à trouver des tokens SHA1, car les versions précédentes de SFOS généraient les tokens MFA avec SHA1. La sélection d’un algorithme global plus robuste ne convertit pas ces tokens existants.

Pour migrer de SHA1 vers un algorithme plus robuste :

  1. Tester l’application pilote avec SHA256 ou SHA512.
  2. Activer Generate OTP token with next sign-in. Sous SFOS 23, choisir aussi Email ou Portals sous Share QR code avant Apply.
  3. Sélectionner le nouvel algorithme sous Authentication > Multi-factor authentication.
  4. Enregistrer avec Apply.
  5. Supprimer les anciens tokens SHA1 sous Issued tokens. Pour supprimer le token du compte admin par défaut, se connecter avec ce compte ; un autre administrateur ne peut pas le supprimer. Garder au préalable l’accès de secours testé et l’accès à la console disponibles.
  6. Demander aux utilisateurs ordinaires de se connecter à VPN Portal ou User Portal avec leur seul mot de passe et d’enregistrer à nouveau le code QR ou la clé Base32 dans une application compatible avec SHA256/SHA512. Sous SFOS 23, la distribution du QR suit Email ou Portals. Pour le compte admin par défaut, le nouvel enregistrement après suppression commence en revanche par une connexion WebAdmin avec le seul mot de passe, et non par User Portal ou VPN Portal ; suivre le flux d’enregistrement qui y est affiché. Il s’agit de la migration SHA, pas de Use an existing token dans l’assistant de réactivation. Ne pas présumer un sélecteur Share QR code supplémentaire dans l’assistant pour cette exception.
  7. Effectuer des tests de connexion contrôlés avec un code correct et un code incorrect.

Des tokens utilisant des algorithmes différents peuvent coexister pendant la migration. Les tokens qui ne sont pas supprimés continuent toutefois d’utiliser leur ancien algorithme.

Limiter le timestep et les fenêtres de tolérance

Sous OTP timestep settings, on configure non seulement l’intervalle des nouveaux codes, mais aussi deux fenêtres de vérification. Les trois valeurs ont des effets différents :

  • Default token timestep définit l’intervalle auquel l’application ou le token matériel génère un nouveau code. La valeur par défaut est de 30 secondes. Une modification s’applique uniquement aux nouveaux tokens et ne change pas les tokens existants.
  • Maximum verification code offset détermine pendant combien de pas de temps un code non utilisé reste valide. Avec la valeur par défaut 2 et un pas de 30 secondes, les codes non utilisés des 60 secondes précédentes sont également acceptés.
  • Maximum initial verification code offset s’applique au premier code après le scan du code QR. Avec la valeur par défaut 10 et un pas de 30 secondes, la fenêtre est de 300 secondes si le code n’a pas encore été utilisé.

Ces fenêtres ne remplacent pas une heure correcte. Vérifier d’abord le NTP du pare-feu et l’heure du terminal, puis conserver chaque décalage aussi faible que possible avec les applications et tokens matériels utilisés. Une fenêtre plus large accepte plus longtemps un code intercepté encore inutilisé. Après une modification, tester un nouveau token pilote ; ne pas supposer qu’un token existant utilise le timestep modifié.

Saisir correctement le mot de passe et l’OTP

Pour les connexions Sophos OTP natives, le format officiel est <password><passcode>, sans espace ni séparateur.

Exemple :

Mot de passe : MonMotDePasseSecurise
Code OTP :     123456
Saisie :       MonMotDePasseSecurise123456

Sophos Connect peut afficher un troisième champ distinct au moyen de otp: true. Le client ajoute le code au mot de passe en interne. Cette présentation ne modifie pas le format envoyé au serveur d’authentification.

Sécuriser et restaurer l’administrateur par défaut

Activer MFA pour l’admin par défaut

L’utilisateur local admin par défaut n’est pas activé via la liste normale des utilisateurs. Son assistant dédié se trouve sous Administration > Device access, et non sous Issued tokens > Add token (for hardware tokens) pour les utilisateurs ordinaires.

Au préalable, le second administrateur, l’accès de gestion et l’accès à la console doivent fonctionner. Les codes à usage unique supplémentaires sont conservés de manière sûre, par exemple dans un gestionnaire de mots de passe. Le compte admin par défaut reste un compte d’urgence et ne sert pas à l’administration quotidienne.

Les autres administrateurs ne peuvent ni activer, ni désactiver, ni modifier, ni supprimer le token du compte admin par défaut. L’OTP hash algorithm global sélectionné s’applique également à ce token.

Avant de commencer, on vérifie aussi l’heure, la compatibilité de l’application ou du matériel et Block login, comme expliqué plus haut. Les nouveaux tokens matériels et logiciels reprennent l’algorithme défini sous Authentication > Multi-factor authentication > OTP hash algorithm ; celui-ci n’est pas choisi séparément dans l’assistant du compte admin par défaut. Un scan QR réussi ne prouve pas la compatibilité de l’algorithme. Les restrictions relatives aux applications et à Base32 décrites plus haut restent applicables.

  1. Se connecter à WebAdmin avec le compte admin par défaut et ouvrir Administration > Device access.
  2. Activer MFA for default admin et cliquer sur Apply.
  3. Sélectionner la méthode de token appropriée dans l’assistant et cliquer sur Next. Terminer ensuite la branche correspondante :
  • Configure a hardware token: Saisir la clé individuelle fournie par le fabricant de l’appareil et le pas de temps correspondant au token matériel. Cliquer sur Next, puis saisir le mot de passe de l’admin par défaut immédiatement suivi du code actuel du token matériel, au format <password><passcode>, sans espace ni séparateur. Cliquer sur Validate, puis terminer avec Apply après une validation réussie.
  • Generate a software token: Installer une application d’authentification compatible sur l’appareil mobile et scanner le code QR affiché. Saisir le mot de passe de l’admin par défaut immédiatement suivi du code actuel de l’application, au format <password><passcode>. Cliquer sur Validate, puis terminer avec Apply après une validation réussie.
  • Use an existing token: Si un token matériel ou logiciel existe déjà pour le compte admin par défaut et que l’on réactive seulement MFA, choisir cette branche et saisir le mot de passe immédiatement suivi du code actuel. Pour configurer plutôt un nouveau token logiciel, choisir Generate a software token et enregistrer le code QR dans l’application. Ce choix ne constitue pas une migration des tokens utilisateur SHA1 existants.

Le premier Apply lance la configuration ; les nouveaux tokens matériels et logiciels nécessitent toujours Validate et le Apply final. Si la validation échoue, vérifier d’abord la saisie du mot de passe plus code, l’heure, le pas de temps et l’algorithme, plutôt que multiplier les essais au hasard. Garder la session existante ouverte pendant la vérification puis, une fois la configuration terminée, tester une nouvelle session WebAdmin distincte avec le compte admin par défaut, le mot de passe et un nouveau code. Ne considérer la configuration comme terminée qu’après une connexion réussie et le stockage sécurisé des codes à usage unique ; le second administrateur ne remplace ni la gestion du token de l’admin par défaut ni la procédure de récupération par console décrite ci-dessous.

Récupération via CLI Main Menu > 2. System Configuration

Les options de récupération se trouvent sous CLI Main Menu > 2. System Configuration, et non dans 4. Device Console. Si l’on se trouve déjà dans la Device Console, on revient d’abord au Main Menu, puis on y saisit 2 pour System Configuration.

Les options de menu 6 et 7 apparaissent uniquement si MFA for default admin a déjà été configuré sous Administration > Device access. Si elles sont absentes, ne pas conclure automatiquement à une erreur de console ; vérifier d’abord ce paramètre et que le compte est bien l’utilisateur default admin. Ces options ne s’appliquent pas aux autres comptes administrateur.

Si le token est seulement temporairement indisponible, on peut autoriser uniquement la prochaine connexion WebAdmin du compte admin par défaut sans MFA sous CLI Main Menu > 2. System Configuration :

  1. Dans CLI Main Menu, saisir 2 pour System Configuration.
  2. Saisir 6 pour Skip multi-factor authentication for next Admin user login.
  3. Se connecter une fois à WebAdmin avec le seul mot de passe du compte admin par défaut et contrôler le token. Garder l’accès de secours testé et l’accès à la console disponibles.
  4. Ouvrir ensuite une nouvelle session WebAdmin distincte avec le compte admin par défaut, en saisissant le mot de passe suivi du code actuel au format <password><passcode>. La récupération n’est terminée qu’après une connexion MFA réussie ; documenter le résultat et garder l’accès de secours disponible jusque-là.

Si le token reste inutilisable, suivre la procédure de réinitialisation et de nouvel enregistrement ci-dessous, puis vérifier à nouveau une connexion MFA dans une nouvelle session. L’exemption ne s’applique qu’à la prochaine connexion ; ni No OTP pour tous ni une ouverture plus large de l’accès WAN ne remplacent cette vérification.

En cas de perte de l’appareil ou de token définitivement inutilisable, on réinitialise MFA :

  1. Dans CLI Main Menu, saisir 2 pour System Configuration.
  2. Saisir 7 pour Reset multi-factor authentication for Admin user.
  3. Confirmer avec y.
  4. Se connecter une fois à WebAdmin avec le seul mot de passe administrateur.
  5. Suivre les instructions pour enregistrer à nouveau MFA, puis retester une connexion avec MFA.

Ces deux options modifient uniquement l’état de MFA. Si le mot de passe du compte administrateur par défaut est également inconnu, l’article séparé sur la récupération du mot de passe explique la procédure série documentée pour les appliances physiques et les limites en cas de perte simultanée du mot de passe et de MFA.

Tester, contrôler les journaux et déployer

Tester chaque service séparément

Une connexion réussie à WebAdmin ne prouve pas que les portails et les clients VPN fonctionnent de la même manière. Avant un déploiement général, on teste :

  • WebAdmin: Connexion de l’administrateur pilote avec un OTP correct, puis volontairement incorrect.
  • Default admin: Vérification du chemin Device Access distinct et de la procédure de récupération documentée.
  • User Portal et VPN Portal: Enregistrement par QR ou Base32 et connexion avec <password><passcode>.
  • SSL VPN et IPsec Remote Access: Test de véritables clients et du groupe d’utilisateurs exactement utilisé en production.
  • Sophos Connect: Le cas échéant, test du troisième champ OTP, des profils client actuels et du comportement appel/push.
  • RADIUS ou Entra SSO: Vérification des délais d’attente, des journaux IdP et du comportement de challenge réellement pris en charge.
  • Device Access: Test depuis un réseau source autorisé et un réseau non autorisé.

Le nombre d’échecs volontaires reste limité après vérification de Block login. Le résultat attendu ne se résume pas à une connexion réussie : un code incorrect doit être rejeté, la tentative doit être journalisée et le service doit être accessible uniquement depuis les réseaux prévus.

Lire correctement les journaux d’authentification

Dans Log viewer, on examine les connexions réussies et échouées avec le service, l’utilisateur, la source, l’heure et la raison documentée. Selon l’événement, SFOS peut ne fournir qu’un message générique tel que des identifiants incorrects. Sans preuve supplémentaire, on ne doit pas en déduire que le mot de passe, l’OTP ou un code expiré est à lui seul responsable.

Avec une MFA externe, les journaux RADIUS, NPS ou IdP font partie de la même vérification. Dépannage Sophos Firewall : services et journaux aide à identifier les fichiers journaux locaux et les services. Pour une conservation plus longue et la corrélation, consulter Envoyer le Syslog Sophos Firewall vers un SIEM.

Avant le déploiement général

Si le pilote échoue, le déploiement est arrêté. Avec le deuxième administrateur testé, la sélection normale du pilote sous Specific users and groups peut être rétablie à l’état initial documenté ; cela n’affecte pas l’assistant distinct de l’administrateur par défaut et ne restaure pas les tokens supprimés. Pour les groupes externes, la connexion MFA supplémentaire expliquée ci-dessus reste à prendre en compte. N’utiliser ni No OTP pour tous ni une ouverture large de l’accès WAN comme méthode de réparation générale. Après une correction, tester à nouveau les services concernés dans de nouvelles sessions.

  • Groupe pilote testé avec succès pour tous les services nécessaires.
  • Second administrateur, codes à usage unique et récupération via CLI Main Menu > 2. System Configuration documentés.
  • Utilisateurs informés de l’enregistrement de l’application et de la saisie mot de passe plus OTP.
  • Réinitialisation des tokens définie pour les smartphones perdus ou remplacés.
  • Device Access, blocages de connexion et conservation centralisée des journaux contrôlés.
  • Responsabilités, délais d’attente et solution de secours définis pour la MFA externe.

Dépannage

Token, code QR et saisie

Le code OTP n’est pas accepté

On compare d’abord l’heure du pare-feu et du smartphone, l’application utilisée, l’algorithme de hachage et le pas de temps. Sous Issued tokens, on peut vérifier et synchroniser le décalage horaire. Après une migration d’algorithme, l’ancien token doit avoir été supprimé et enregistré à nouveau.

Pour synchroniser, ouvrir Authentication > Multi-factor authentication > Issued tokens, sélectionner Synchronize token time offset pour le token concerné, saisir le code actuel généré par l’application ou le token matériel et cliquer sur Check. Le décalage horaire est synchronisé avec le pare-feu, ce qui corrige la dérive temporelle. Tester ensuite une nouvelle connexion de manière contrôlée ; garder l’accès de secours disponible et vérifier Block login avant d’autres tentatives infructueuses.

Un changement de serveur NTP doit être planifié séparément, car le pare-feu reconnecte alors les tunnels IPsec existants.

Le code QR n’apparaît pas ou ne peut pas être scanné

L’utilisateur doit appartenir au groupe MFA sélectionné et se connecter à VPN Portal ou User Portal. Sous SFOS 22, les administrateurs peuvent aussi s’enregistrer dans WebAdmin lorsque MFA y est actif. Sous SFOS 23, vérifier d’abord Share QR code : avec Email, consulter la boîte de réception après la connexion au portail au lieu d’attendre un QR affiché dans le portail ; avec Portals, le QR est affiché dans les portails, y compris après une connexion WebAdmin qui déclenche cet affichage. Le portail et la source doivent aussi être autorisés sous Administration > Device access. Pour l’enregistrement initial ou le remplacement d’application sous SFOS 23 avec la génération de tokens activée, vérifier aussi la durée de 24 heures expliquée plus haut : si le QR n’a pas été utilisé pour se connecter pendant cette période, se connecter à VPN Portal ou User Portal avec le seul mot de passe et enregistrer le nouveau QR distribué selon Email ou Portals.

Sous iOS ou avec Okta Verify, on utilise la clé Base32 plutôt que le scan du code QR lorsque les restrictions mentionnées s’appliquent.

La connexion signale un mot de passe incorrect

Pour une connexion Sophos OTP native, le mot de passe doit être immédiatement suivi du code. Sans champ OTP distinct, le mot de passe seul est incomplet.

Accès, groupes et accès à distance

Le portail n’est pas accessible

On contrôle d’abord la zone, la source et le service requis sous Administration > Device access. Une Local Service ACL Exception Rule restrictive est plus sûre qu’une autorisation WAN générale.

MFA ne s’applique pas à l’accès à distance

Les configurations MFA et Remote Access doivent utiliser le même groupe d’utilisateurs réellement importé. On réimporte ou redistribue ensuite le profil client et on teste la connexion avec le véritable client. Le token doit être enregistré via VPN Portal ou User Portal avant la première connexion VPN.

MFA ne s’applique qu’à certains utilisateurs

Il ne faut pas comparer uniquement les noms de groupes visibles, mais vérifier les groupes réellement associés par AD, LDAP, RADIUS ou Entra ID. Après le retrait d’un utilisateur AD d’un groupe MFA, une dernière connexion avec MFA peut encore être nécessaire ; seules les connexions suivantes n’exigent plus d’OTP.

Verrouillage et MFA externe

L’administrateur est verrouillé

Pour le compte admin par défaut, on utilise les options 6 ou 7 décrites plus haut sous CLI Main Menu > 2. System Configuration. Pour un autre administrateur, on utilise le second administrateur préparé depuis une source autorisée, puis on contrôle les groupes, le token et l’état du blocage de connexion.

RADIUS ou Entra MFA ne fonctionne pas de manière fiable

On contrôle les délais d’attente RADIUS, les journaux IdP, les groupes et le comportement de challenge du service concerné. Un test réussi du serveur d’authentification ne prouve pas qu’une connexion de production via VPN Portal, Sophos Connect ou WebAdmin fonctionne. Chacun de ces chemins doit être testé séparément.