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

  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.

La fonction est disponible depuis SFOS 19.5 GA Build 197. La procédure et les restrictions décrites ici correspondent à SFOS 22.

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 est à l’heure et peut atteindre les endpoints Microsoft nécessaires via DNS et HTTPS.
  • 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 par Active Directory et Microsoft Entra ID. Les deux serveurs peuvent exister, mais il faut déterminer avant la modification quel annuaire gère ces utilisateurs sur le pare-feu.

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.

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 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 local de secours et n’est pas remplacé par un Role mapping Entra.

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

  • Un utilisateur non attribué à 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

  • 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

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.

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.
  • User type: Administrator et Role mapping sont correctement ordonné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 oauth_sso_webadmin.log ont été vérifiés.
  • Le retrait des droits, la rotation du secret et la restriction HA sont documentés pour l’exploitation.