Aller au contenu
Avanet

Configurer Microsoft Entra ID SSO pour WebAdmin de Sophos Firewall

Sophos Firewall

Pour utiliser Microsoft Entra ID SSO avec WebAdmin, quatre paramètres doivent être cohérents : un groupe ou rôle d’application Entra, un profil Device Access local, la Web admin console URL exacte comme Redirect URI et le serveur Entra sous Administrator authentication methods. Seule cette chaîne complète transforme un utilisateur Entra correctement authentifié en administrateur du pare-feu avec les droits prévus.

Si l’environnement utilise TACACS+ plutôt qu’OAuth pour l’administration centralisée des équipements, suivez la procédure distincte TACACS+ pour les administrateurs Sophos Firewall. Contrairement à Entra Role Mapping, TACACS+ n’attribue pas automatiquement le profil local dans ce flux.

⚠️ Avant l’activation : Conservez une session d’administration locale ouverte, testez le compte admin local depuis le réseau de gestion et assurez-vous de connaître l’accès à la console ou à la Device Console. SSO et Entra MFA ne justifient pas d’exposer largement WebAdmin à la zone WAN. Ne donnez pas la priorité à Entra en production tant que la connexion pilote, les droits et la voie de récupération locale ne fonctionnent pas.

WebAdmin SSO en huit étapes

SFOS 22

  1. Vérifiez le FQDN WebAdmin, le DNS, le certificat, l’heure système et l’accès restreint depuis le réseau de gestion.
  2. Préparez les profils d’administrateur nécessaires sous Profiles > Device access.
  3. Dans Microsoft Entra ID, créez une application Single-Tenant dédiée avec un administrateur pilote, un rôle d’application ou un groupe de sécurité et un Client Secret supervisé.
  4. Sous Authentication > Servers, créez un serveur de type Microsoft Entra ID SSO ou complétez le serveur existant.
  5. Définissez User type sur Administrator et associez les rôles ou groupes Entra aux profils locaux dans le bon ordre.
  6. Ajoutez la Web admin console URL affichée par le pare-feu comme Redirect URI exacte de l’application Entra, puis exécutez Test connection avec succès.
  7. Activez le serveur Entra sous Authentication > Services > Administrator authentication methods, remontez-le dans la liste et sélectionnez Apply.
  8. Dans une fenêtre de navigation privée, testez séparément un administrateur pilote, un utilisateur non associé, les droits réels et le fallback local.

Les chemins de navigation, les champs User type et Role mapping ainsi que les logs propres à chaque service présentés jusqu’ici dans cet article concernent SFOS 22. Pour SFOS 23.0, suivez la procédure OIDC ci-dessous. Les voies de gestion sécurisées, les profils locaux, les attributions d’application ainsi que les tests MFA, positifs, négatifs et du fallback restent nécessaires. L’aide de SFOS 23 ne confirme pas une date de disponibilité générale (GA).

SFOS 23.0 : serveur OIDC et mapping des administrateurs

  1. Sous Authentication > Servers > Add, sélectionnez Server type: OpenID Connect et IdP vendor: Microsoft Entra ID. Avant toute modification d’un objet Entra existant, documentez ses attributions de services et ses Redirect URIs ; ne créez pas une seconde application Entra uniquement à cause de la nouvelle interface.
  2. Renseignez Server name, Client ID avec l’Application (client) ID et Client secret avec le Value du secret de l’application. Sous OpenID Connect URLs > Issuer URL, la configuration Entra prévoit de saisir la Directory (tenant) ID, et non une URL construite manuellement. Les autres paramètres d’URL ne s’appliquent pas à ce fournisseur.
  3. Sous Redirect URIs, choisissez entre Use firewall URL et Enter manually. Si vous configurez un pare-feu individuel via Sophos Fusion, définissez manuellement le nom d’hôte de l’appliance et ne reprenez pas l’URL Reverse SSO. Ouvrez Show URLs et enregistrez la Web admin console URL exacte comme Redirect URI Web dans l’application Entra. Le DNS et le certificat doivent correspondre à ce nom.
  4. Sous User attributes, conservez les valeurs par défaut Display name: name, Username: upn et Email address: email, sauf si vous utilisez un token dont la structure différente et la prise en charge ont été vérifiées. Le paramètre Fallback group destiné aux services utilisateur ne remplace toujours pas un profil d’administrateur.
  5. Activez IdP authentication for firewall administrators. Ce commutateur est désactivé par défaut pour les services exclusivement destinés aux utilisateurs et remplace, dans SFOS 23, l’ancienne sélection User type: Administrator.
  6. Sous IdP attribute, choisissez entre Roles et Groups ; sous IdP value, saisissez la valeur exacte du rôle ou du groupe configuré ; sous Device access profile, sélectionnez le profil local. Dans l’exemple existant, sfosAdminReadOnly est associé à Entra-WebAdmin-ReadOnly. Ajoutez les autres mappings et vérifiez leur ordre : la première entrée correspondante détermine le profil.
  7. Exécutez Test connection avec succès, enregistrez et sélectionnez le serveur sous Authentication > Services > Administrator authentication methods. Dans SFOS 23, chaque méthode ne peut utiliser qu’un seul serveur IdP OpenID Connect, et non un serveur par fournisseur. Documentez l’ordre, conservez le fallback local et sélectionnez Apply.
  8. Lors d’une nouvelle connexion WebAdmin, vérifiez le rôle pilote, les droits réels sur les menus, le refus des utilisateurs non autorisés et l’accès d’urgence local. Une connexion VPN ou Captive Portal authentifie l’utilisateur, mais ne crée ni ne met à jour un objet administrateur. Les modifications des rôles Entra, des groupes ou des attributions de profils sont synchronisées lors d’une connexion WebAdmin.

Lors du retrait des droits, la particularité décrite plus bas reste importante : un objet administrateur local existant ne devient pas un utilisateur standard par le seul fait d’une rétrogradation dans Entra. La suppression contrôlée sur le pare-feu et le test négatif WebAdmin restent nécessaires. Après une mise à niveau, validez à nouveau les champs OIDC, le callback, l’attribution au service et cette vérification des droits avant de fermer la session locale restée ouverte.

Automatisation API uniquement : vérifier les réponses lors du passage de SFOS 22 à 23

Si vous ajoutez ou modifiez le serveur Microsoft Entra ID SSO via l’API, vérifiez l’interprétation des résultats séparément de la procédure UI/OIDC ci-dessus. La référence API documente les lignes de statut suivantes pour ces opérations :

  • SFOS 22, Add et Edit : 200/500/502/503.
  • SFOS 23, Add : 200/400/401/403/409/500.
  • SFOS 23, Edit : 200/400/401/403/404/500.

Ainsi, 409 apparaît uniquement pour Add et 404 uniquement pour Edit ; les anciennes lignes 502/503 ne figurent plus dans la référence SFOS 23. Il s’agit d’une modification documentaire, et non d’un comportement testé ici à l’exécution : ces lignes ne confirment ni les statuts de transport HTTP réellement renvoyés, ni les codes de résultat XML, ni les messages exacts à l’exécution. Elles n’impliquent pas non plus de règle de nouvelle tentative. Avant de valider une écriture autorisée ou de modifier un classificateur automatique de résultats, consultez l’API help du build installé ; validez ensuite la réponse de l’opération et l’état attendu de l’objet cible. Pour sécuriser les requêtes, les secrets et la vérification des réponses, suivez le guide d’accès sécurisé à l’API.

L’exemple XML inchangé de la référence n’est pas un schéma OIDC confirmé pour SFOS 23. Ne renommez pas AzureADSSO en OIDC uniquement à cause de la nouvelle interface et ne reprenez pas en production sans vérification les choix larges Administrator et Open Group de l’exemple. Les exigences de gestion, de moindre privilège, de tests négatifs et de récupération de cet article restent applicables.

Rôle de chaque niveau

WebAdmin SSO associe plusieurs contrôles qu’il est facile de confondre :

  • Device Access et Local Service ACL déterminent depuis quels réseaux la console WebAdmin est accessible.
  • Microsoft Entra ID authentifie l’utilisateur et fournit les informations de rôle ou de groupe dans le token.
  • Le Role mapping du pare-feu associe la première valeur correspondante du token à un profil d’administrateur local.
  • Le profil Device Access détermine quels menus l’administrateur ne peut pas utiliser, peut consulter ou peut modifier.
  • Administrator authentication methods active le serveur Entra pour la connexion à WebAdmin.

Une règle de pare-feu classique n’active pas WebAdmin. Inversement, une page de connexion accessible n’accorde aucun droit d’administration. Device Access et Local Service ACL sur Sophos Firewall explique comment limiter l’accès réseau en toute sécurité.

Si aucun Role mapping ne correspond, l’authentification auprès d’Entra ID peut tout de même réussir. SFOS crée alors le compte uniquement comme utilisateur standard et refuse l’accès à WebAdmin. Il ne s’agit pas d’une erreur du navigateur, mais d’une association manquante avec des droits d’administration.

Groupes Entra ou rôles d’application

SFOS prend en charge les deux variantes :

  • Les groupes de sécurité sont simples lorsque l’organisation gère déjà les droits à l’aide de groupes aux noms explicites. Le nom du groupe doit correspondre exactement dans le mapping.
  • Les rôles d’application s’appliquent spécifiquement à l’application du pare-feu. Le mapping utilise le Value exact du rôle, pas seulement son nom d’affichage.

Les rôles propres à l’application facilitent la traçabilité des nouvelles intégrations d’administration. Les groupes de sécurité restent une bonne solution lorsque les appartenances sont déjà approuvées, contrôlées et documentées correctement. Ne mélangez pas les deux modèles sans contrôle.

SFOS évalue les mappings de haut en bas et utilise la première correspondance. Les attributions Full Access et Read-only doivent donc s’exclure mutuellement. Si un chevauchement est détecté, corrigez d’abord les attributions Entra, puis testez à nouveau les deux rôles. L’ordre des mappings ne doit pas servir de modèle d’autorisation.

Planifier l’exemple et les prérequis

L’exemple suivant utilise des valeurs de documentation. Remplacez-les par celles de votre environnement :

  • FQDN WebAdmin : fw01.example.com
  • Application Entra : Sophos Firewall - FW01 - WebAdmin
  • Rôle d’application Full Access : sfosAdminFull
  • Rôle d’application Read-only : sfosAdminReadOnly
  • Profil local Full Access : Administrator
  • Profil local Read-only : Entra-WebAdmin-ReadOnly

example.com est un domaine réservé aux exemples. Le FQDN de production doit se résoudre vers le bon pare-feu depuis le réseau de gestion et correspondre au certificat WebAdmin utilisé. Pour séparer les cycles de droits et de changements, une application Entra dédiée avec son propre objet serveur sur le pare-feu pour chaque intégration WebAdmin est la solution la plus claire. Une application partagée est possible, mais elle lie les administrateurs, les utilisateurs VPN et les utilisateurs des portails aux mêmes attributions d’application.

Avant la modification, vérifiez également les points suivants :

  • Un second administrateur local ou le compte admin local fonctionne indépendamment d’Entra ID.
  • Le mot de passe, la procédure de récupération et l’accès à la console du compte de secours sont documentés. Si cette voie n’a pas encore été testée, Récupérer le mot de passe admin de Sophos Firewall aide à la préparer en toute sécurité.
  • La session d’administration actuelle reste ouverte pendant la modification.
  • Le pare-feu utilise l’heure correcte et peut joindre les endpoints Microsoft requis via DNS et HTTPS.
  • Le pare-feu et le navigateur de l’administrateur peuvent joindre les destinations Microsoft nécessaires au flux SSO. La liste FQDN complète et les exceptions Direct Web Proxy figurent dans liste d’autorisation des connexions Microsoft Entra.
  • Le FQDN WebAdmin utilise un certificat de confiance avec une chaîne complète.
  • WebAdmin est accessible uniquement depuis les réseaux de gestion, via VPN ou depuis des sources expressément autorisées.
  • Le propriétaire et la date d’expiration du Client Secret sont documentés.
  • Les utilisateurs d’un même domaine ne sont pas synchronisés simultanément via Active Directory et Microsoft Entra ID. Les deux serveurs peuvent exister, mais il faut définir avant la modification quel annuaire gère ces utilisateurs sur le pare-feu.
  • SFOS 22 : Le tenant n’est pas Microsoft 365 Government Community Cloud High (GCC High), car cette intégration SSO n’est pas prise en charge pour cet environnement. L’aide de SFOS 23 ne mentionne plus cette restriction ; cela ne confirme pas sa prise en charge. La prise en charge de GCC High doit être clarifiée séparément avant un déploiement de SFOS 23.

Configurer l’heure système et NTP et Importer et attribuer des certificats fournissent de l’aide pour l’heure et les certificats.

Préparer les profils Device Access

Créez les profils avant de basculer vers SSO afin que chaque valeur Entra pointe immédiatement vers des droits définis. Configurer les administrateurs et profils Sophos Firewall en toute sécurité explique la conception générale et la validation sécurisée des profils administrateur locaux ; cette section traite uniquement de l’association propre à Entra.

Le profil intégré Administrator peut être utilisé pour l’accès complet. Il doit être réservé au plus petit nombre de personnes nécessaire. Pour l’exploitation, l’audit ou le helpdesk, un profil personnalisé est généralement préférable :

  1. Ouvrez Profiles > Device access.
  2. Sélectionnez Add.
  3. Saisissez par exemple le nom Entra-WebAdmin-ReadOnly.
  4. Définissez chaque menu nécessaire sur Read-only.
  5. Laissez les zones inutiles sur None.
  6. N’accordez Read-write que lorsque la fonction nécessite réellement un accès en écriture.
  7. Enregistrez le profil et comparez-le à nouveau au rôle réel de l’équipe.

Un nom contenant Read-only ne rend pas à lui seul le profil accessible en lecture seule. Les paramètres None, Read-only et Read-write de la matrice de droits déterminent l’accès effectif. Les sous-menus peuvent être configurés plus précisément en les dépliant.

Préparer l’application Entra et les rôles d’administrateur

Si une application Entra correctement documentée existe déjà pour le VPN ou le Captive Portal, le même serveur Entra ID peut également servir à WebAdmin. La Redirect URI, les rôles d’administrateur et les tests restent toutefois propres à chaque service. Entra ID SSO pour Sophos Connect et le portail VPN décrit la base commune de l’application et du serveur ; les utilisateurs locaux du navigateur suivent la procédure distincte Entra ID SSO pour Captive Portal.

Avec une application partagée, attribuez tous les groupes d’administrateurs, VPN et de portails autorisés avant d’activer Assignment required, puis testez chaque service utilisé. Une application WebAdmin dédiée avec son propre objet serveur Entra est plus claire si les droits administratifs, les rotations de secrets et les déploiements doivent rester indépendants.

Pour une nouvelle intégration, la configuration Sophos actuelle comprend :

  1. Sous Microsoft Entra ID > App registrations, créez une application Single-Tenant dédiée au pare-feu.
  2. Ajoutez les autorisations Microsoft Graph déléguées User.Read.All et Group.Read.All.
  3. Pour l’importation des groupes, ajoutez également Group.Read.All comme Application Permission.
  4. Accordez l’Admin Consent pour ces autorisations.
  5. Sous Certificates & secrets, créez un Client Secret, enregistrez immédiatement son Value en lieu sûr et surveillez sa date d’expiration.
  6. Sous App roles, créez sfosAdminReadOnly et, uniquement si nécessaire, sfosAdminFull.
  7. Sous Users and groups dans l’Enterprise Application associée, attribuez le rôle approprié à l’administrateur pilote ou à un groupe pilote contrôlé.
  8. Pour une application WebAdmin dédiée, activez Assignment required comme contrôle d’accès supplémentaire et attribuez uniquement les administrateurs pilotes ou groupes d’administrateurs prévus. Il s’agit d’une recommandation de sécurité Avanet, pas d’une exigence technique de SFOS.

Des groupes de sécurité dédiés comme SFOS-FW01-WebAdmin-Full et SFOS-FW01-WebAdmin-ReadOnly peuvent remplacer les rôles d’application. Les groupes informatiques généraux ou Microsoft 365 sont trop larges pour les droits d’administration du pare-feu et compliquent les révisions ultérieures.

Le fournisseur d’identité impose MFA pour cette connexion. Sophos Firewall MFA ne peut pas être ajouté au même flux Entra SSO. Conditional Access doit donc être testé spécifiquement pour l’application du pare-feu et pas seulement de manière générale pour Microsoft 365. MFA pour Sophos Firewall explique les différences avec Sophos OTP.

SFOS 22 : configurer le serveur Entra ID sur le pare-feu

Sous Authentication > Servers, ouvrez un serveur Microsoft Entra ID existant ou créez-en un avec Add > Microsoft Entra ID SSO.

Configurer le serveur et la Redirect URI

  1. Saisissez un Server name explicite.
  2. Collez l’Application (client) ID de l’App Registration.
  3. Collez le Directory (tenant) ID.
  4. Saisissez le Value du Client Secret enregistré précédemment.
  5. Choisissez délibérément le fallback user group. Il contrôle les services utilisateur et ne remplace pas un profil d’administrateur.
  6. Sous Redirect URI, vérifiez ou définissez manuellement le FQDN WebAdmin.
  7. Copiez la Web admin console URL affichée dans son intégralité.

Ne construisez pas vous-même la Redirect URI à partir du nom d’hôte, du port et d’un chemin de callback supposé. Dans l’application Entra, ouvrez App registrations > Application > Authentication > Add a platform > Web et ajoutez exactement l’URL affichée par SFOS.

Lorsqu’un pare-feu individuel est modifié via Sophos Fusion (anciennement Sophos Central), le nom d’hôte du pare-feu doit être défini manuellement. L’URL Central Reverse SSO affichée automatiquement n’est pas la Redirect URI WebAdmin de l’appliance.

Exécutez ensuite Test connection. Le test vérifie la connexion réseau, les autorisations de l’application et la validation du certificat TLS. Ne modifiez pas l’authentification des administrateurs tant qu’il échoue.

Associer les rôles ou groupes aux profils

  1. Définissez User type sur Administrator. Le paramètre User active uniquement les services utilisateur et ne suffit pas pour WebAdmin.
  2. Sous Role mapping, sélectionnez l’Identifier type :
    • Roles pour la valeur exacte du rôle d’application, par exemple sfosAdminReadOnly ;
    • Groups pour le nom exact du groupe Entra.
  3. Sous Value, saisissez sans modification la valeur du rôle ou le nom du groupe.
  4. Sous Profile, sélectionnez le profil local, par exemple Entra-WebAdmin-ReadOnly.
  5. Ajoutez d’autres mappings et vérifiez consciemment leur ordre.
  6. Enregistrez la configuration.

Les associations sont évaluées de haut en bas et la première correspondance s’applique. Les appartenances à sfosAdminFull et sfosAdminReadOnly doivent donc s’exclure mutuellement. En cas de double appartenance, corrigez d’abord l’attribution Entra et testez à nouveau le pilote au lieu d’utiliser l’ordre comme règle d’autorisation. L’ordre de la liste doit néanmoins être documenté, car il détermine le profil effectif lors de toute correspondance multiple inattendue.

Activer Entra SSO pour les administrateurs

Le serveur Entra ID ne devient une méthode de connexion WebAdmin qu’après son attribution au service d’administration :

  1. Ouvrez Authentication > Services.
  2. Accédez à Administrator authentication methods.
  3. Sélectionnez le serveur Microsoft Entra ID.
  4. Remontez le serveur dans la liste.
  5. Conservez délibérément l’authentification locale existante comme fallback pour les administrateurs locaux.
  6. Sélectionnez Apply.

Un seul serveur Microsoft Entra ID peut être sélectionné par méthode d’authentification. Les paramètres sous Administrator authentication methods ne s’appliquent pas au super-administrateur par défaut admin. Ce compte reste donc un accès d’urgence local et n’est pas remplacé par un Role mapping Entra.

Revenir en arrière sans risquer un verrouillage

Si le login pilote, le test du profil ou le fallback local échoue, interrompez le déploiement :

  1. Utilisez la session administrateur locale déjà ouverte ; ne vous déconnectez pas et ne basculez pas vers la session SSO défaillante.
  2. Sous Authentication > Services > Administrator authentication methods, retirez le serveur Entra.
  3. Sélectionnez Apply, puis testez le compte admin local depuis le réseau de gestion dans une nouvelle fenêtre privée.
  4. Ne fermez l’ancienne session qu’après avoir validé ce login et ses droits. Conservez l’objet serveur Entra pour l’analyse au lieu de le supprimer dans l’urgence.

Tester la connexion et les droits en toute sécurité

La réussite du dialogue Entra ne suffit pas à valider le test. Le pare-feu doit appliquer le bon profil, refuser un utilisateur non autorisé et continuer à offrir une voie de récupération locale.

Test positif avec des administrateurs pilotes

  1. Conservez la session d’administration locale existante ouverte.
  2. Ouvrez le FQDN WebAdmin documenté dans une fenêtre de navigation privée.
  3. Connectez-vous via Entra ID avec l’administrateur pilote Read-only.
  4. Effectuez Entra MFA et Conditional Access comme prévu.
  5. Vérifiez que seuls les menus autorisés sont visibles et que les actions d’écriture sont réellement indisponibles.
  6. Sous Authentication > Users, vérifiez que le compte a été créé comme administrateur avec le profil attendu.
  7. Si Full Access est nécessaire, testez un administrateur pilote distinct doté du rôle Full Access.

N’effectuez pas le test Full Access avec le même compte qui doit également recevoir Read-only. Deux comptes de test sans ambiguïté montrent si les rôles, l’ordre des mappings et les profils locaux sont réellement séparés.

Test négatif et du fallback

  • Lorsque Assignment required est activé, un utilisateur non affecté à l’Enterprise Application ne doit pas pouvoir terminer le flux SSO avec succès.
  • Un utilisateur attribué mais sans mapping ne doit pas obtenir d’accès à WebAdmin.
  • Un administrateur Read-only ne doit pas pouvoir enregistrer une modification de configuration.
  • Le compte admin local doit continuer à fonctionner depuis le réseau de gestion prévu.
  • Un accès depuis un réseau non autorisé doit déjà échouer au niveau de Device Access ou de Local Service ACL.

Si le test négatif obtient un accès, l’attribution, l’appartenance au groupe ou l’ordre des mappings est incorrect. Arrêtez la phase pilote ; ne contournez pas le problème de droits en élargissant un rôle ou en exposant WebAdmin au WAN.

Exploitation, retrait des droits et HA

Entra SSO transfère l’identité et la MFA au fournisseur d’identité. Les droits d’administrateur effectifs localement doivent néanmoins rester contrôlés sur le pare-feu.

Finaliser consciemment les changements de rôle

Lorsqu’un utilisateur Entra devient administrateur du pare-feu, SFOS applique la modification lors de sa prochaine connexion. L’opération inverse n’est pas automatique : si un administrateur est rétrogradé au rang d’utilisateur standard dans Entra, l’objet administrateur local reste d’abord présent sur le pare-feu.

Procédure sûre pour une rétrogradation :

  1. Confirmez un second administrateur local et la voie de récupération.
  2. Retirez le rôle ou le groupe d’administration dans Entra, ou adaptez l’attribution de l’application.
  3. Sous Authentication > Users, supprimez de manière contrôlée l’objet administrateur local concerné.
  4. N’autorisez une nouvelle connexion que si l’utilisateur doit continuer à utiliser des services utilisateur. SFOS recrée le compte comme utilisateur selon le token actuel.
  5. Effectuez un test négatif d’une nouvelle connexion WebAdmin et ne supposez pas que les sessions existantes se terminent automatiquement.

Si le compte ne doit plus utiliser aucun service du pare-feu, ne le réattribuez pas. Le simple retrait d’un groupe ne doit pas être documenté comme une révocation immédiate des droits d’administration locaux déjà effectifs.

Surveiller le secret, les logs et les modifications

SFOS 23.0 : Vérifiez le flux OIDC dans /log/oauth_sso_svc.log et les erreurs TLS lors de Test connection dans /log/sfos-macro-cfg.log. Dans le Log Viewer, WebAdmin utilise le module Admin. Les références à oauth_sso_webadmin.log et la commande de lecture ci-dessous concernent SFOS 22.

  • Surveillez la date d’expiration du Client Secret avec un responsable et un délai suffisant.
  • Vérifiez les Entra Sign-in Logs par application, utilisateur, MFA et Conditional Access.
  • Utilisez oauth_sso_webadmin.log sur le pare-feu pour le flux SSO WebAdmin.
  • Retracez les modifications d’administrateurs, de profils et d’authentification grâce à l’Audit Trail.
  • Révisez régulièrement et ensemble les groupes d’administrateurs, les rôles d’application et les profils Device Access.

Dans l’Advanced Shell, la commande de lecture suivante affiche les dernières entrées du service SSO WebAdmin :

tail -n 200 /log/oauth_sso_webadmin.log

Services et logs Sophos Firewall explique l’association générale des fichiers de logs et les méthodes de lecture sûres.

Tenir compte de la restriction HA

Dans un cluster HA, Entra ID SSO ne fonctionne actuellement pas pour WebAdmin de l’appareil Auxiliary. L’accès direct au peer, la récupération et la maintenance nécessitent donc une procédure locale. Associer un rôle Entra à HAProfile ne lève pas cette restriction du produit.

Avant un test HA, documentez les deux voies de gestion, les identifiants locaux et les rôles. Après un changement de rôle, testez à nouveau séparément l’accès au Primary, la gestion locale du peer et SSO.

Dépannage

La connexion Entra fonctionne, mais WebAdmin refuse l’accès

Il manque généralement un mapping d’administrateur correspondant. Vérifiez User type: Administrator, le type d’identifiant, la valeur exacte du rôle ou le nom du groupe et le profil attribué. Sous Authentication > Users, un compte créé comme utilisateur standard indique qu’aucun mapping d’administrateur n’a correspondu.

L’administrateur reçoit le mauvais profil

Role mapping est évalué de haut en bas. Vérifiez les appartenances aux groupes et les rôles d’application du compte, supprimez les doubles attributions et testez à nouveau l’ordre avec une nouvelle connexion. N’élargissez pas simplement les droits du profil restrictif.

La redirection aboutit à une page d’erreur

Comparez caractère par caractère la Web admin console URL du pare-feu avec la Redirect URI sous App registrations > Authentication > Web. Le FQDN, le port, le chemin, le DNS et le certificat WebAdmin font partie du même test. N’utilisez pas l’URL Reverse SSO lors d’une configuration via Central.

Test connection échoue

SFOS 23.0 : Après avoir vérifié le DNS, l’heure, les autorisations et les certificats, répétez d’abord Test connection. Uniquement si le test échoue encore après la correction de la chaîne de CA et si l’interruption des services de connexion OIDC utilisés est acceptée, redémarrez le service partagé dans l’Advanced Shell pendant une fenêtre de maintenance :

service oauth_sso_svc:restart -ds nosync

Testez ensuite séparément Test connection, une nouvelle connexion pilote WebAdmin et tous les autres services OIDC utilisés. Le service partagé ne se limite pas à WebAdmin. La commande service oauth_sso_webadmin:restart -ds nosync présentée plus bas et le fichier de logs propre à ce service concernent SFOS 22.

Vérifiez l’accès à login.microsoftonline.com et graph.microsoft.com, le DNS, l’heure système, le Tenant ID, le Client ID, le Client Secret, les autorisations Microsoft Graph et l’Admin Consent. Une nouvelle Redirect URI ne corrige pas un secret expiré.

Si oauth_sso_webadmin.log affiche x509: certificate signed by unknown authority, il manque peut-être une autorité de certification racine ou intermédiaire pour la chaîne de certificats Microsoft effectivement présentée. Lisez la chaîne depuis l’Advanced Shell du pare-feu pour connaître ce que le pare-feu reçoit réellement :

openssl s_client -connect login.microsoftonline.com:443 -showcerts

Un ordinateur de test peut servir de comparaison, mais ne prouve pas quelle chaîne le pare-feu voit lui-même. Importez uniquement une CA dont l’absence a été démontrée et provenant d’une source de confiance. N’utilisez pas un certificat de serveur comme CA et ne redémarrez pas un service SSO comme première étape de dépannage.

Si Test connection échoue encore après la correction de la chaîne de CA, le redémarrage local au nœud du service WebAdmin SSO documenté par Sophos constitue une dernière étape facultative pendant une fenêtre de maintenance :

service oauth_sso_webadmin:restart -ds nosync

Répéter ensuite Test connection et une nouvelle connexion SSO. Le redémarrage ne remplace ni le DNS, ni l’heure, ni les autorisations de l’application, ni Admin Consent, ni une chaîne de certificats complète.

SSO fonctionne sur le Primary, mais pas sur l’Auxiliary

Il s’agit d’une restriction HA documentée. WebAdmin de l’Auxiliary nécessite un accès local testé. Un nouveau rôle Entra, un accès Device Access plus large ou une autre Redirect URI ne résout pas cette restriction.

Liste de contrôle

  • Le compte admin local, un second administrateur et l’accès à la console fonctionnent.
  • WebAdmin est accessible uniquement depuis les réseaux de gestion ou les sources prévues.
  • Le FQDN, le DNS, le certificat et l’heure système sont corrects.
  • L’App Registration, les autorisations, l’Admin Consent et l’expiration du secret sont documentés.
  • Pour une application WebAdmin dédiée, Assignment required est activé et seul le groupe pilote d’administrateurs est attribué ; pour une application partagée, tous les groupes d’administrateurs, VPN et de portails autorisés sont inclus et testés.
  • Les profils Device Access contiennent les droits prévus.
  • SFOS 22 : User type: Administrator et Role mapping sont correctement ordonnés. SFOS 23 : IdP authentication for firewall administrators est activé et IdP attribute, IdP value ainsi que Device access profile ont été vérifiés.
  • La Web admin console URL exacte est enregistrée comme Redirect URI Entra.
  • Test connection réussit.
  • Entra est activé sous Administrator authentication methods.
  • Les tests Read-only, Full Access, négatif et du fallback local ont réussi.
  • Les Entra Sign-in Logs et le fichier de logs correspondant au firmware ont été vérifiés : SFOS 22 oauth_sso_webadmin.log, SFOS 23 oauth_sso_svc.log ; dans le Log Viewer, le module Admin.
  • Le retrait des droits, la rotation du secret et la restriction HA sont documentés pour l’exploitation.