Configurer Microsoft Entra ID SSO pour le portail captif du pare-feu Sophos

Avec Microsoft Entra ID SSO pour Captive Portal, Sophos Firewall peut authentifier les utilisateurs auprès de Microsoft Entra ID via un navigateur avant que les règles de pare-feu basées sur l’utilisateur ne prennent effet. Ceci est particulièrement intéressant pour les réseaux BYOD, les zones invités ou partenaires, les appareils sans détection AD transparente ou les environnements où STAS ne convient pas à tous les clients.

Il est important de distinguer les usages : Captive Portal n’est ni VPN Portal ni Remote Access. L’utilisateur se trouve déjà sur le réseau local ou Wi-Fi et s’authentifie dans le navigateur afin que le pare-feu puisse attribuer le trafic suivant à une identité utilisateur. Pour l’accès à distance avec Sophos Connect, l’article séparé Configurer Microsoft Entra ID SSO pour Sophos Connect et le portail VPN convient.

Si Microsoft Entra ID SSO est déjà configuré pour VPN Portal ou Sophos Connect, il ne faut pas automatiquement créer une toute nouvelle architecture Entra. Dans beaucoup de cas, le même objet serveur Microsoft Entra ID sur le pare-feu peut être réutilisé. Captive Portal a toutefois besoin de la bonne Captive portal URL comme URI de redirection, de l’affectation sous Authentication > Services et d’un test séparé de la règle utilisateur qui s’appliquera ensuite.

Quand le portail captif avec Entra ID SSO a du sens

Le portail captif avec Entra ID SSO est logique si les utilisateurs se connectent quand même avec Microsoft 365 et que le pare-feu a besoin d’une identité d’utilisateur pour certains réseaux.

Applications typiques :

• Réseaux BYOD ou WiFi sans adhésion de domaine.
• Invités ou utilisateurs externes avec accès contrôlé à quelques destinations.
• Règles Internet basées sur l’utilisateur sans STAS ou SATC.
• Réseaux où l’authentification transparente n’est pas fiable.
• Scénarios de transition où l’authentification AD locale doit être réduite.

Pour les clients Windows entièrement gérés dans un domaine classique, Captive Portal n’est pas automatiquement la meilleure solution. Là, STAS, AD SSO ou d’autres procédures transparentes peuvent être plus ergonomiques car les utilisateurs n’ont pas à déclencher activement une connexion au navigateur. Le portail captif est plutôt une solution de repli ou une solution spéciale pour les appareils non gérés.

Portail captif séparé, portail VPN et portail utilisateur

Avec Entra ID SSO, les termes du portail se mélangent rapidement. La séparation est cruciale pour la configuration.

• Portail captif : Les utilisateurs du réseau local se connectent via un navigateur afin que les règles basées sur leur identité s’appliquent. Entra ID SSO sert ici à la connexion dans le navigateur et à l’association de l’utilisateur.
• Portail VPN : Les utilisateurs d’accès à distance téléchargent Sophos Connect ou des configurations VPN. Entra ID SSO est ici pertinent pour l’accès à distance et la connexion au portail.
• Portail utilisateur : Ce portail contient des fonctions utilisateur telles que OTP ou d’anciennes options personnelles. Selon l’environnement, il reste pertinent pour les jetons ou les options utilisateur.

Un aperçu général du portail est disponible dans Portails Sophos : SophosID, Central, Support et accès au pare-feu. Pour le portail captif, vous devez avant tout vérifier à partir de quelle zone le service de pare-feu local est accessible et quelle règle de pare-feu traite ensuite le trafic réel des utilisateurs.

Exigences

Avant la mise en place, ces points doivent être clarifiés :

• Sophos Firewall avec une version SFOS prenant en charge Microsoft Entra ID SSO.
• Microsoft Entra Tenant avec autorisation pour l’enregistrement de l’application, les URI de redirection, les autorisations API, le consentement de l’administrateur et le secret client.
• FQDN et certificat pour le portail captif afin que les utilisateurs ne voient pas d’avertissements inutiles du navigateur.
• Accessibilité des points de terminaison de connexion Microsoft à partir du réseau client concerné.
• Le portail captif est autorisé sous Administration > Accès aux appareils pour la zone appropriée.
• Les utilisateurs ou les groupes sont correctement gérés dans Microsoft Entra ID.
• Les règles de pare-feu utilisent les utilisateurs ou groupes attendus.
• Un utilisateur test et un accès de secours sont disponibles.
• L’heure et NTP sur le pare-feu et les clients sont corrects car OAuth/OIDC dépend du temps.
• Si Affectation requise est actif dans Microsoft Entra ID, les utilisateurs ou groupes requis sont attribués à l’application d’entreprise.

⚠️ Le portail captif est une zone de connexion sur le pare-feu. Il ne doit être accessible que dans les zones où il est réellement nécessaire. L’accès aux appareils et l’ACL du service local sont ici des contrôles de sécurité, pas seulement des paramètres de connexion.

Sécurisation de l’accès à Sophos Firewall : configurer correctement l’accès aux appareils convient pour renforcer les services de pare-feu locaux. Dans cette conception, la MFA est implémentée dans Microsoft Entra ID, par exemple via l’accès conditionnel. Le MFA local du Sophos Firewall ne remplace pas le facteur de connexion Microsoft par Entra ID SSO. C’est généralement mieux du point de vue de l’utilisateur, car le même MFA est utilisé comme Microsoft 365, mais il doit être soigneusement planifié et testé dans le locataire.

Planifier l’architecture avant la configuration

Avant la configuration technique, vous devez décider quelle tâche le portail captif doit spécifiquement résoudre. Sinon, vous vous retrouvez rapidement avec un login qui fonctionne mais ne déclenche pas de règle de pare-feu adaptée.

Questions de conception importantes :

• Quelle zone utilise le portail captif ?: L’accès aux appareils et la source des règles dépendent de la zone.
• Quel groupe d’utilisateurs est autorisé à se connecter ?: Le groupe Entra doit correspondre à la règle de pare-feu la plus récente.
• Quels objectifs peuvent être atteints après la connexion ?: Le portail captif ne remplace pas une segmentation propre.
• Quelle est la durée de validité des sessions ?: Les sessions trop longues diluent l’allocation des utilisateurs et les sessions trop courtes perturbent les opérations.
• Que se passe-t-il en cas de panne d’Entra ou d’Internet ?: Il doit y avoir une solution de repli claire pour les tâches critiques.
• Comment se déclenche la connexion ?: Les utilisateurs ont besoin d’une URL de portail captif accessible ou d’une redirection propre.

Le portail captif ne doit pas être utilisé en remplacement des VLAN, des zones ou des règles de pare-feu minimales. Le pare-feu connaît mieux l’utilisateur après la connexion, mais l’architecture réseau doit rester propre. Configurer les zones et les interfaces de Sophos Firewall convient à la logique de base des zones.

Créer un serveur Microsoft Entra ID

La configuration se compose de deux parties : Tout d’abord, un enregistrement d’application est préparé dans Microsoft Entra ID. Cette application est ensuite enregistrée en tant que serveur d’authentification sur le pare-feu Sophos.

Préparer l’enregistrement de l’application dans Microsoft Entra ID

Un enregistrement d’application distinct pour le pare-feu doit être créé dans Microsoft Entra ID. Cela signifie que les URI de redirection, les autorisations et les secrets client restent clairement séparés des autres applications.

Processus typique :

1. Ouvrez le centre d’administration Microsoft Entra.
2. Ouvrez Inscriptions d’applications > Nouvelle inscription.
3. Donner un nom explicite, par exemple Sophos-Firewall-SSO.
4. En règle générale, sélectionnez votre propre locataire comme type de compte pris en charge.
5. Utilisez la plateforme Web.
6. Notez l’ID d’application (client) et l’ID de répertoire (locataire).
7. Créez un secret client sous Certificats et secrets et enregistrez immédiatement la valeur secrète en toute sécurité.
8. Sous Autorisations API, ajoutez les autorisations Microsoft Graph requises, généralement User.Read.All et Group.Read.All.
9. Accordez le Consentement de l’administrateur pour les autorisations.
10. Si Affectation requise est utilisé, attribuez les utilisateurs ou groupes autorisés à l’application d’entreprise.

Sans les autorisations API appropriées et le consentement de l’administrateur, la connexion peut accéder à la connexion Microsoft, mais le pare-feu ne peut alors pas évaluer correctement les données de l’utilisateur ou du groupe. En pratique, cela ressemble souvent à un problème de portail captif, même si la cause réside dans Microsoft Entra ID.

Créer ou réutiliser un serveur Entra ID sur Sophos Firewall

Le chemin du menu sur Sophos Firewall est le suivant :

Authentication > Servers

Processus de base :

1. Ouvrez Ajouter.
2. Sélectionnez l’option Microsoft Entra ID SSO comme Type de serveur.
3. Attribuer un nom descriptif, par exemple Entra-SSO-Firewall.
4. Saisissez l’ID d’application (client) depuis l’application Entra.
5. Saisissez l’ID d’annuaire (locataire).
6. Saisissez Secret client.
7. Définissez consciemment un groupe de secours et gardez-le aussi restrictif que possible.
8. Testez la connexion.
9. Enregistrez.

Le groupe de secours ne doit pas recevoir un accès large à internet ou au réseau. C’est un filet de sécurité, pas un raccourci pour contourner l’autorisation.

⚠️ Les client secrets sont des données d’accès productives. La date d’expiration, la rotation et la responsabilité doivent être documentées. Un secret expiré ressemble souvent à un problème de connexion normal du point de vue de l’utilisateur, mais il s’agit en réalité d’un problème de configuration ou d’exploitation.

Saisissez correctement les URI de redirection

L’URI de redirection qui correspond au pare-feu doit être saisi dans l’enregistrement de l’application dans Microsoft Entra ID. Il est crucial que le nom de domaine complet, le certificat, le port et le chemin correspondent exactement. De petites différences dans le nom d’hôte, le port, le protocole ou la barre oblique suffisent pour que le processus OAuth/OIDC échoue.

Le Sophos Firewall affiche les URL de service requises sur le serveur Entra ID. L’URL du portail captif est particulièrement pertinente pour cet article. Si WebAdmin ou Remote Access avec Entra ID SSO sont également utilisés, ces services ont leurs propres URL :

• URL de la console d’administration Web: Entra ID SSO pour la console WebAdmin.
• URL du portail captif: Entra ID SSO pour portail captif dans le réseau local.
• Portail VPN et URL d’accès à distance: Entra ID SSO pour le portail VPN et Sophos Connect.

Si le même serveur Entra ID est déjà utilisé pour Remote Access, ajouter la Captive portal URL aux Redirect URIs existantes dans l’application Entra. Captive Portal doit malgré tout être testé séparément, car le chemin de connexion, Device Access, la correspondance des groupes et la règle firewall suivante ont d’autres causes d’erreur que Sophos Connect ou VPN Portal.

Définir la méthode d’authentification du portail captif

Après avoir créé le serveur Entra, la méthode d’authentification pour Captive Portal doit pointer vers le bon serveur.

La zone concernée se trouve sous :

Authentication > Services

Pour vérifier :

1. Ouvrez la zone Firewall authentication methods.
2. Ajoutez ou faites glisser le serveur Microsoft Entra ID vers la position correcte.
3. Ne conservez les autres serveurs d’authentification que s’ils servent de solution de repli délibérée.
4. Appliquez la modification avec Appliquer.
5. Effectuez une connexion test avec un seul utilisateur.

Si plusieurs méthodes d’authentification sont actives en parallèle, il doit être clair quel serveur est responsable de quel groupe d’utilisateurs. Le fonctionnement mixte de l’Entra ID et de l’authentification AD locale peut fonctionner, mais augmente considérablement les efforts de dépannage. La liste des problèmes connus de Sophos documente les cas Entra SSO dans lesquels des sessions mixtes Entra et AD sur site peuvent conduire à des erreurs de type no permission.

De plus, vous devez vérifier sous Authentification > Authentification Web comment le portail captif est ouvert dans le navigateur. HTTPS est important pour Entra ID SSO. L’option Utiliser HTTP non sécurisé au lieu de HTTPS ne doit pas être activée car le flux Entra-OAuth sur HTTP n’est pas correctement pris en charge et serait inutilement non sécurisé.

Les éléments suivants sont utiles pour le fonctionnement :

1. Ouvrez le portail captif dans une nouvelle fenêtre de navigateur.
2. Gardez la fenêtre du portail captif ouverte pendant la session.
3. Demandez aux utilisateurs de se déconnecter consciemment via le portail captif si l’association doit être résiliée.
4. Une fois connecté, vérifiez sous Activités en cours > Utilisateurs en direct si l’utilisateur est visible.

En fonction de l’interface et du certificat, l’URL standard https://<Firewall-IP>:8090 peut également être utile pour les tests. Un FQDN propre avec un certificat approprié est beaucoup plus agréable pour un fonctionnement productif.

Vérifiez l’accès à l’appareil et l’accessibilité du portail

Captive Portal est un service local du pare-feu. Une règle de pare-feu normale ne permet pas à elle seule cet accès. L’accessibilité est contrôlée sous Administration > Accès aux appareils pour la zone respective.

Il faudrait vérifier :

• Le portail captif n’est autorisé que dans les zones requises.
• Cela signifie que WebAdmin et SSH ne sont pas accidentellement également largement accessibles.
• Le certificat et le FQDN correspondent à l’URL de l’utilisateur.
• Le DNS du réseau client résout correctement le nom du portail.
• Les règles d’exception ACL du service local ne sont définies que lorsqu’elles sont vraiment nécessaires.

Si le portail captif n’est pas accessible depuis un réseau, vous ne devez pas créer d’abord une règle d’autorisation normale. La cause est souvent l’accès à l’appareil, l’ACL du service local, le DNS, le certificat ou un mappage de zone incorrect.

Tenir compte de la connexion Microsoft et du filtrage Web

Le client doit accéder aux pages de connexion Microsoft et aux ressources associées lors de la connexion. Sinon, dans les réseaux restrictifs, le flux SSO peut s’arrêter à un point qui ressemble aux utilisateurs à une erreur de pare-feu ou de navigateur.

Pour vérifier :

• La résolution DNS pour les domaines de connexion Microsoft fonctionne.
• HTTPS vers les points de terminaison de connexion Microsoft est autorisé.
• Le filtre Web, l’inspection TLS ou le proxy ne bloquent pas la page de connexion.
• Le temps passé sur le pare-feu et le client est plausible.
• Les cookies du navigateur ne sont pas rendus inutilisables par une politique stricte.

Dans les environnements restrictifs, vous devez vérifier explicitement la connexion Microsoft et les points de terminaison Entra. En fonction du locataire, du navigateur et du chemin de connexion Microsoft, ces domaines sont pertinents, entre autres :

• login.microsoftonline.com
• *.login.microsoftonline.com
• *.microsoftonline.com
• *.msauth.net
• *.msftauth.net
• aadcdn.msauth.net
• aadcdn.msftauth.net
• aadcdn.msftauthimages.net
• graph.microsoft.com

Si le filtre Web, un proxy ou une inspection TLS prend effet avant la connexion, ces cibles ne doivent pas être inutilement déchiffrées ou bloquées. L’authoriser la section URL de la documentation Entra ID doit être recoupé pour détecter des politiques très restrictives.

Si la protection Web ou l’inspection TLS sont actives, la connexion avec un utilisateur test doit être observée dans la visionneuse de journaux. Parfois, le problème ne vient pas du portail captif lui-même, mais d’une politique Web, d’une exception TLS ou d’un réseau client qui n’atteint pas complètement les points de terminaison Microsoft.

Testez les groupes d’utilisateurs et les règles de pare-feu

Après une connexion réussie au portail captif, la règle de pare-feu réelle doit voir l’utilisateur ou le groupe dans le trafic. Il s’agit de l’examen pratique le plus important.

Processus typique :

1. Vérifiez les utilisateurs dans Microsoft Entra ID.
2. Comparez l’UPN, l’adresse e-mail et l’adhésion au groupe.
3. Cochez le groupe Entra sur Sophos Firewall.
4. Activez Match known users et Use web authentication for unknown users dans la règle utilisateur.
5. Effectuez une connexion au portail captif avec l’utilisateur test.
6. Déclenchez ensuite le trafic utilisateur réel, par exemple HTTPS vers une destination autorisée.
7. Dans Log Viewer, vérifiez si l’utilisateur, le groupe, la zone source, le réseau source et le Rule ID correspondent à la règle attendue.

Une connexion réussie au navigateur prouve uniquement l’authentification. Cela ne prouve pas que la règle de l’utilisateur ultérieur s’applique. Si le compteur de règles reste à 0 ou qu’aucun utilisateur n’est visible dans la visionneuse de journaux, vous devez utiliser le flux de La règle du pare-feu Sophos ne fonctionne pas : vérifier les causes.

Correspondance des groupes et ancienne restriction du groupe principal

Pour les règles utilisateur, le groupe Entra prévu doit être présent sur le pare-feu. Après la connexion, vérifier sous Current activities > Live users et dans Log Viewer à quel groupe l’utilisateur a été associé et quel Rule ID traite le trafic.

Il existait une restriction connue dans SFOS 20.0 GA Build 222 : avec NC-167130, l’accès Internet via un groupe Entra secondaire ne fonctionnait pas ; la règle devait contenir le groupe principal ou l’utilisateur individuel. Sophos indique que ce problème est corrigé dans SFOS 21.5 MR2 Build 323 et SFOS 22.0 MR1 Build 490. Sur les builds actuels, le groupe principal n’est donc plus une exigence générale de conception.

Avant un déploiement, consigner les points suivants pour chaque utilisateur test :

• Groupe Entra : Le groupe cible et l’appartenance sont connus.
• Groupe sur le pare-feu Sophos: Le même groupe est importé ou mappé correctement.
• Règle de pare-feu : Le groupe prévu est inclus dans la condition utilisateur ou groupe.
• Trafic de test après la connexion : Log Viewer affiche l’utilisateur, le groupe, le Rule ID et l’action attendue.
• Ancien build concerné : Utiliser le groupe principal ou une règle de test propre à l’utilisateur et planifier la mise à jour.

Cela n’affecte pas Sophos Connect VPN avec Microsoft Entra ID SSO. Pour l’accès à distance, le processus distinct pour Microsoft Entra ID SSO pour Sophos Connect et le portail VPN doit donc être vérifié.

Validation après le déploiement

Pour la validation, ne pas vérifier uniquement si la page de connexion Microsoft apparaît.

• Ouvrir l’URL du portail captif depuis le réseau client : Le navigateur affiche la connexion Entra attendue ou la redirection Sophos.
• Connectez-vous avec un utilisateur autorisé: Connexion réussie, l’utilisateur apparaît sur le pare-feu.
• Connectez-vous avec un utilisateur non autorisé: L’accès est naturellement refusé.
• Test de règle de groupe : L’utilisateur test correspond à la règle utilisateur attendue.
• Trafic utilisateur après connexion : La bonne règle de pare-feu correspond avec l’identité de l’utilisateur.
• Déroulement de la session: Après un délai d’attente, vous devez vous reconnecter.
• Connexion Microsoft bloquée: La visionneuse de journaux ou les journaux Web affichent une raison compréhensible.
• Scénario de repli : L’accès lors d’une panne Entra peut être vérifié ou modifié temporairement.

Surtout avec les réseaux BYOD, vous devez tester avec plusieurs navigateurs et appareils. Les modes de navigation privée, les cookies tiers bloqués, les anciennes connexions enregistrées ou plusieurs comptes Microsoft sur le même appareil peuvent produire des résultats différents.

Dépannage

Le portail captif n’est pas accessible

Vérifiez d’abord Administration > Accès aux appareils pour la zone concernée. Vérifiez ensuite le DNS, le certificat, le FQDN du portail, l’ACL du service local et le mappage de zones. Si l’accès se fait via le pare-feu lui-même, une règle de pare-feu normale ne constitue pas le premier point de contrôle.

La connexion Microsoft démarre mais ne revient pas

Comparez l’URI de redirection, le FQDN, le certificat et le port. L’URL exacte utilisée par le pare-feu Sophos pour le portail captif doit être stockée dans Microsoft Entra ID. Les règles d’inspection proxy ou TLS peuvent également interférer avec le retour.

Lorsque Microsoft affiche l’erreur AADSTS50011, l’URI de redirection dans l’enregistrement de l’application ne correspond généralement pas à l’URL utilisée par le pare-feu. Ensuite, le protocole, le FQDN, le port et le chemin doivent être comparés exactement.

Une erreur interne apparaît après la connexion Microsoft

Un 500 Internal Server Error ou une erreur générique similaire après une connexion Microsoft réussie indique souvent un manque d’autorisations Microsoft Graph, un manque de consentement de l’administrateur ou un problème avec le secret client. Ensuite, vous devez vérifier les autorisations API, le consentement de l’administrateur, la validité du secret et l’attribution des applications d’entreprise dans Microsoft Entra ID.

Le nom d’utilisateur et le mot de passe ne fonctionnent pas directement

Entra ID SSO est un navigateur et un flux OAuth/OIDC. Les utilisateurs ne se connectent pas directement au pare-feu avec les identifiants classiques, mais sont redirigés vers Microsoft. Si un client ou un flux prend uniquement en charge le nom d’utilisateur et le mot de passe sans redirection du navigateur, cette méthode ne convient pas.

MFA n’apparaît pas ou apparaît différemment que prévu

Avec Entra ID SSO, la MFA est contrôlée dans Microsoft Entra ID. L’authentification MFA du pare-feu sur site n’est pas le point de contrôle approprié pour ce flux SSO. Si MFA est requis, vous devez vérifier l’accès conditionnel, les groupes d’utilisateurs, les exclusions et tester les utilisateurs dans Microsoft Entra ID.

L’utilisateur voit no permission ou est rejeté après un fonctionnement prolongé

Effacez les cookies du navigateur et vérifiez si le même utilisateur est utilisé en parallèle via Entra ID SSO et l’authentification AD locale. Lorsque vous mélangez Entra et On-Prem AD pour le même utilisateur, la conception de l’authentification doit être simplifiée ou au moins documentée proprement.

La connexion fonctionne, mais la règle utilisateur ne correspond pas

Le portail captif n’est alors probablement plus le seul problème. Vérifiez la zone source, le réseau source, le groupe d’utilisateurs, la position des règles et la visionneuse de journaux. Souvent, une règle plus générale est supérieure à la règle de l’utilisateur ou le trafic provient d’un réseau différent de celui prévu.

Vérifier également que le groupe Entra prévu est importé et que l’utilisateur lui est associé sur le pare-feu. Ce n’est que sur SFOS 20.0 GA Build 222, concerné par NC-167130, que le groupe principal ou l’utilisateur individuel doit figurer dans la règle pour ce problème.

Seuls les utilisateurs individuels sont concernés

Comparez l’UPN, l’adresse e-mail, le nom d’affichage, l’appartenance au groupe et le groupe importé. Avec Entra ID SSO, vous ne devez pas supposer que le nom visible et l’identifiant technique sont identiques. Si l’adresse e-mail et l’UPN divergent historiquement, des erreurs de mappage surviennent facilement.

Quels journaux sont utiles ?

oauth_sso_captive.log est particulièrement pertinent pour le portail captif avec Entra ID SSO. De plus, Log Viewer avec le module Authentication, access_server.log et, selon le problème rencontré, les journaux Web, de pare-feu ou d’authentification sont utiles. L’attribution des fichiers les plus importants se trouve dans Dépannage de Sophos Firewall : services et journaux.

Liste de contrôle

• Le cas d’utilisation du portail captif est clair : BYOD, invités, appareils non gérés ou solution de secours.
• Le FQDN et le certificat du portail captif sont propres.
• L’application Microsoft Entra ID avec l’URI de redirection, l’ID client, l’ID de locataire et le secret client est documentée.
• Les autorisations de l’API Microsoft Graph et le consentement de l’administrateur sont définis.
• Les attributions d’applications d’entreprise sont vérifiées si Affectation requise est active.
• Client Secret a une date d’expiration, un propriétaire et un processus de rotation.
• L’URI de redirection du portail captif a été repris par le pare-feu et saisi exactement dans Entra ID.
• Authentification > Services utilise le bon serveur Entra pour Captive Portal.
• Authentification > Authentification Web utilise HTTPS et les paramètres appropriés de la fenêtre du navigateur.
• Administration > Accès aux appareils autorise uniquement le portail captif dans les zones requises.
• Les points de terminaison de connexion Microsoft sont accessibles depuis le réseau client.
• Le filtrage Web et l’inspection TLS ne bloquent pas le flux SSO.
• MFA et accès conditionnel sont planifiés et testés dans Microsoft Entra ID.
• Correspondance du groupe Entra et du groupe pare-feu.
• Le groupe Entra prévu est importé et réellement évalué pour l’utilisateur test.
• L’utilisateur test peut se connecter, puis son trafic correspond à la règle de pare-feu attendue.
• La visionneuse de journaux affiche l’utilisateur, l’ID de règle et l’action.
• oauth_sso_captive.log et access_server.log sont connus pour les cas de support.
• Le repli en cas de panne d’Entra ou de Portal est documenté.

Questions fréquemment posées