Résoudre les erreurs d’authentification sur Sophos Firewall

Une erreur d’authentification sur Sophos Firewall peut survenir à des étapes très différentes. Le serveur peut être joignable sans être sélectionné pour le service concerné. La connexion peut fonctionner alors que le groupe principal, un quota ou une règle firewall bloque l’accès. Il se peut aussi que le firewall ne voie pas du tout l’utilisateur et traite uniquement le trafic en fonction de son adresse IP.

La procédure rapide et sûre sépare volontairement ces niveaux :

1. Noter l’utilisateur, l’IP source, le service concerné, l’heure et le résultat attendu.
2. Tester l’accessibilité du portail ou du service d’authentification depuis la zone source réelle.
3. Sous Authentication > Services, vérifier que le bon serveur est sélectionné pour le service concerné et placé à la position prévue.
4. Exécuter Test connection sur le serveur d’authentification, mais considérer le résultat uniquement comme une preuve de validité des identifiants et de connectivité avec le serveur.
5. Générer une nouvelle connexion, puis contrôler l’utilisateur, l’IP source et le Client Type sous Current activities > Live users.
6. Sous Authentication > Users, contrôler le statut, le groupe principal, les autres groupes, les dérogations propres à l’utilisateur et le User ID.
7. Vérifier les plages d’accès, quotas, MFA et restrictions de connexion uniquement pour l’utilisateur réellement concerné ou son groupe effectif.
8. Une fois l’identité validée, tester avec un trafic réel la règle firewall attendue, la Rule ID, la stratégie web ou VPN, le NAT et le routage.

⚠️ Ne pas modifier largement les serveurs d’authentification, l’ordre des groupes, les quotas ou Device Access sur la base d’un soupçon. Un redémarrage de service, Purge AD users ou une règle Any ne constituent pas une première étape normale de diagnostic. Il faut d’abord prouver à quel niveau la procédure s’interrompt.

Cinq niveaux plutôt qu’une seule erreur de connexion

Dans la pratique, un modèle simple aide à raisonner. Un accès utilisateur ne passe pas une seule vérification, mais au moins cinq niveaux distincts :

1. Accessibilité : le client et le firewall atteignent le portail, le proxy ou le serveur d’authentification par le chemin prévu.
2. Service et méthode : le bon serveur d’authentification est sélectionné sous Authentication > Services pour ce service précis.
3. Identité : le firewall reconnaît l’utilisateur attendu et l’affiche avec la bonne IP source et le bon Client Type.
4. Autorisation : le statut de l’utilisateur, le groupe, le groupe principal, la plage d’accès, le quota, la MFA et les autorisations propres au service correspondent.
5. Trafic ultérieur : une règle firewall, une stratégie web ou une stratégie VPN autorise les destinations voulues et le chemin de retour fonctionne.

Cette séparation évite deux conclusions erronées fréquentes. Un Test connection vert ne prouve pas que la connexion SSO fonctionne. À l’inverse, la présence d’un utilisateur sous Live users ne prouve pas encore que son trafic correspond à la règle ou à la stratégie prévue.

Définir un cas de test reproductible

Avant toute modification, définir un seul cas de test. Les valeurs de documentation suivantes conviennent par exemple :

• Utilisateur : auth-pilot@example.com
• IP du client : 192.0.2.25
• Zone source : LAN
• Service : Firewall authentication, User portal, VPN portal, SSL VPN ou Web admin console
• Heure du test : heure locale du firewall avec date et minute
• Groupe attendu : Internet-Standard
• Règle attendue : LAN-Users-to-WAN
• Résultat attendu : connexion réussie et accès HTTPS à une destination de test définie

example.com et 192.0.2.0/24 sont des valeurs de documentation. Remplacer le nom d’utilisateur, l’IP source, la zone, le groupe, la règle et la destination par les valeurs réelles du pilote. Celui-ci doit utiliser la même source d’authentification et le même groupe d’autorisations que l’utilisateur concerné, sans disposer de privilèges administratifs inutiles.

Si possible, tester aussi un utilisateur de comparaison fonctionnel provenant de la même source. Si les deux échouent, la cause se situe plus probablement au niveau du service, du serveur ou de l’accessibilité. Si un seul utilisateur échoue, l’objet utilisateur, les groupes, les quotas, la MFA ou les restrictions de connexion sont plus probables.

Vérifier le service, l’accessibilité et le serveur

Contrôler Device Access uniquement pour le service nécessaire

Les portails et services d’authentification locaux ne sont pas autorisés par des règles firewall ordinaires. Sous Administration > Device access, ou à l’aide d’une Local service ACL exception rule ciblée, le service requis doit être joignable depuis la zone source prévue ou les réseaux sources connus.

Selon le test, différentes entrées peuvent être pertinentes, notamment Captive portal, User portal, VPN portal, SSL VPN, AD SSO ou Client Authentication. Contrôler uniquement le service réellement nécessaire. Une autorisation générale pour LAN ou WAN masquerait l’erreur et pourrait exposer d’autres services d’administration ou portails. Device Access et Local Service ACL sur Sophos Firewall explique cette limite de sécurité.

L’accessibilité seule n’est pas une authentification. Une page de portail visible confirme uniquement que le client atteint le service local. Le nom d’utilisateur, le mot de passe, le jeton SSO, le groupe et la règle firewall ultérieure ne sont pas encore vérifiés.

Vérifier la méthode d’authentification pour chaque service

Sous Authentication > Services, chaque service possède sa propre sélection de serveurs. Il ne suffit donc pas de vérifier qu’un serveur AD, LDAP, RADIUS ou Entra existe. Il faut confirmer qu’il est sélectionné pour le service concerné :

• Firewall authentication methods pour le trafic utilisateur et l’authentification firewall classique ;
• User portal authentication methods pour le User Portal ;
• VPN portal authentication methods pour le VPN Portal ;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods pour ces connexions VPN ;
• Administrator authentication methods pour les administrateurs nommés ;
• SSL VPN authentication methods pour SSL VPN.

La firewall prend en charge au maximum 20 serveurs d’authentification au total, et chaque méthode d’authentification accepte au maximum 20 serveurs sélectionnés. L’absence d’un serveur supplémentaire lors de l’ajout ou dans la sélection ne signifie donc pas automatiquement un problème de connexion. Vérifier d’abord le nombre total, la sélection et la nécessité réelle de chaque serveur.

Le User Portal et le VPN Portal peuvent hériter de la liste des serveurs d’authentification du pare-feu via Set authentication methods same as firewall. SSL VPN peut de même utiliser Same as VPN ou Same as firewall. Cet héritage est pratique, mais étend l’effet des modifications ultérieures de sélection ou d’ordre des serveurs. La liste effectivement héritée doit donc toujours être documentée lors du diagnostic. Administrator authentication methods ne s’applique pas non plus au super-administrateur local admin ; sa voie de secours doit être conservée et testée séparément.

Vérifier séparément les limites globales de session : Maximum session timeout met fin à une session authentifiée une fois sa durée maximale atteinte. SFOS vérifie l’autorisation toutes les trois minutes ; les Access Policies, le Surfing Quota, le Data Transfer Limit et la durée maximale de session peuvent limiter l’accès plus tôt. La valeur globale Simultaneous logins ne s’applique qu’aux utilisateurs créés après sa définition.

Dans SFOS 22 et SFOS 23, vérifier également séparément les valeurs propres à chaque méthode sous Authentication > Services : AD SSO settings (NTLM and Kerberos) et Web client settings (iOS, Android and API) disposent chacun des paramètres Inactivity time et Data transfer threshold. Si le volume de données transférées pendant la durée configurée est inférieur au minimum défini, l’utilisateur est considéré comme inactif ; Inactivity time définit la durée d’inactivité après laquelle il est déconnecté. En cas de déconnexion inattendue, documenter d’abord le Client Type utilisé, les deux valeurs du bloc correspondant et le trafic réel sur la même période. Ne pas modifier à la place le paramètre global Maximum session timeout ni les temporisations STAS ou Captive Portal.

Avec plusieurs serveurs, l’ordre compte également. Ne pas déplacer prématurément un serveur en première position. Documenter d’abord l’ordre actuel, le Default Group et l’utilisateur de comparaison fonctionnel. Une modification pourrait sinon affecter d’autres utilisateurs ou services. Pour les administrateurs externes, TACACS+ pour le WebAdmin de Sophos Firewall sépare en plus l’authentification du serveur, le profil administrateur local et un accès de secours évitant le verrouillage.

Remplacer eDirectory avant la mise à niveau : L’intégration native eDirectory relève de SFOS 22. Avant une mise à niveau vers SFOS 23.0 ou ultérieur, valider une solution de remplacement prise en charge pour tous les services concernés et supprimer la configuration native eDirectory ; si elle est conservée, la mise à niveau échoue. Ne pas supprimer l’authentification de production avant de vérifier les connexions via la nouvelle solution, les groupes, les stratégies et un accès local de secours indépendant. Migrer eDirectory en toute sécurité décrit la bascule contrôlée et le rétablissement.

Interpréter correctement Test connection

Sous Authentication > Servers, Test connection vérifie les identifiants et la connexion entre le firewall et le serveur. En cas d’échec, corriger d’abord le DNS, le routage, le port, la sécurité de la connexion, la chaîne de certificats, le compte de service ou le mot de passe.

Un test réussi ne constitue toutefois que le premier niveau. Pour AD SSO, il ne vérifie ni Kerberos, ni NTLM, ni le SPN, ni Redirection Location, ni la confiance du navigateur, ni l’accès réel de l’utilisateur. Pour les connexions au portail et au VPN, la sélection du service, le groupe, la MFA et la stratégie doivent également être testés séparément. Connecter Active Directory à Sophos Firewall décrit la configuration AD complète.

Utiliser Live Users comme première preuve d’identité

Après une nouvelle connexion, ouvrir Current activities > Live users. Trois valeurs au moins sont importantes :

Limite de capacité : SFOS 22 prend en charge au maximum 32,000 utilisateurs actifs. Les utilisateurs et les groupes partagent la plage de User ID ; pour le diagnostic, un identifiant visible jusqu’à 65535 est valide. Dans les très grands environnements, contrôler cette limite séparément d’un échec de connexion individuel. Ne pas supprimer sans contrôle des sessions ou des objets utilisateur.

Pour le Client Authentication Agent, le type de client doit être Authentication agent. Vérifier également séparément le chemin vers 1.2.3.4:9922, l’Authentication Server CA et le match réel de la règle firewall.

• User : l’utilisateur détecté correspond-il réellement au compte pilote ?
• IP address : l’adresse correspond-elle à la connexion client observée ?
• Client Type : le chemin attendu a-t-il été utilisé, par exemple AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Captive portal, RADIUS SSO ou un type de VPN ?

Le type doit être interprété selon sa source, et non comme une connexion générique. Les sessions Captive Portal dans un navigateur et les sessions d’invités apparaissent sous la forme Web client, Android web client ou iOS web client. Les associations initiées par le client comprennent STAS, Thin client, Heartbeat et API ; le SSO initié par le serveur comprend RADIUS SSO et Chromebook SSO. eDirectory SSO figure uniquement dans la liste de SFOS 22 ; SFOS 23 supprime le SSO eDirectory natif et ne répertorie plus ce type. Les entrées VPN distinguent IPsec VPN, SSL VPN, L2TP VPN et PPTP VPN. Le type observé doit correspondre au mécanisme prévu.

Les Clientless Users font exception au test avec une nouvelle connexion : ils apparaissent dans la liste dès leur configuration, car SFOS les authentifie par adresse IP, et n’y apparaissent plus lorsqu’ils sont Inactive.

Si l’utilisateur est absent, le niveau d’identité n’a pas encore réussi. Il ne faut pas poursuivre le diagnostic sur la règle utilisateur ultérieure. Si un nom d’ordinateur apparaît à la place de l’utilisateur connecté, un service du système d’exploitation tel que Windows Update peut avoir envoyé les identifiants NTLM de l’appareil. Une véritable connexion interactive de l’utilisateur suivie d’une nouvelle requête web permet d’isoler ce cas.

Un utilisateur AD, LDAP ou RADIUS externe n’apparaît normalement sous Authentication > Users qu’après sa première connexion réussie à un service du firewall. L’absence d’un enregistrement utilisateur local ne prouve donc pas que le compte manque dans l’annuaire. Pour un compte géré directement dans SFOS, créer et gérer des utilisateurs locaux normaux décrit au contraire le processus complet du compte, du service, des tests et du départ.

Pour répéter proprement le test, sélectionner une session normale existante sous Live users, cliquer sur Disconnect, modifier si nécessaire le texte de notification, puis confirmer avec Disconnect. Après la déconnexion manuelle d’une session AD SSO, jusqu’à trois minutes peuvent être nécessaires avant que l’utilisateur puisse se reconnecter. La notification n’est envoyée qu’aux utilisateurs connectés avec Authentication agent, Android client, iOS client ou Chromebook SSO.

Les Clientless Users ne sont pas déconnectés avec Disconnect. Il faut plutôt passer l’utilisateur concerné à Inactive sous Authentication > Clientless users. Si Disconnect a déjà été utilisé sur un Clientless User et que son accès doit être rétabli, passer son statut à Inactive, puis à Active.

Vérifier l’objet utilisateur, le groupe principal et les restrictions

Lorsque l’utilisateur est visible ou qu’un enregistrement local existe déjà, poursuivre sous Authentication > Users. Ne pas modifier les valeurs à l’aveugle. Documenter d’abord les propriétés effectives :

• statut Active ou Inactive ;
• champ Group comme groupe principal des utilisateurs AD ;
• Other group memberships ;
• dérogations de stratégie propres à l’utilisateur ;
• Access Time et Sign-in Restriction ;
• Surfing Quota et Network Traffic Quota ;
• attribution MFA pour le service concerné ;
• propriété supplémentaire User ID.

Ne pas confondre groupe principal et autres groupes

Un utilisateur AD peut appartenir à plusieurs groupes. Sophos Firewall affiche le groupe principal effectif dans le champ Group et les autres appartenances séparément. Les règles firewall, les stratégies web et quelques autres fonctions peuvent tenir compte de plusieurs groupes. Access Time, les quotas, la MFA et plusieurs fonctions d’accès distant utilisent en revanche uniquement le groupe principal ou une attribution explicite à l’utilisateur.

L’ordre des groupes ne doit donc pas être modifié comme solution rapide. Il faut d’abord déterminer quelle fonction échoue et quelle logique de groupes elle prend en charge. Après une modification planifiée, authentifier de nouveau l’utilisateur et contrôler encore une fois le groupe principal.

La procédure d’exploitation complète, de la création des groupes et du Default Group jusqu’à Reorder, aux groupes multiples, aux exceptions utilisateur et au retour arrière, est décrite dans Gérer correctement les groupes d’utilisateurs et le groupe principal sur Sophos Firewall.

Traiter Access Time, les quotas et la MFA comme des causes distinctes

Un Captive Portal inattendu ou une connexion refusée peut aussi provenir d’une plage d’accès bloquée, d’un quota Surfing ou Network Traffic épuisé, ou d’une inscription MFA manquante. Comparer ces paramètres sur l’utilisateur et son groupe effectif.

Les contrôles et procédures de rétablissement correspondants sont décrits dans Access Time pour les utilisateurs et les groupes, Surfing et Network Traffic Quota et MFA pour Sophos Firewall. Ne pas réinitialiser un quota ni élargir une stratégie Access Time avant d’avoir prouvé son attribution effective.

Si seule la MFA échoue, vérifier Issued tokens, l’état du token ainsi que l’heure du firewall et du téléphone. Synchronize token time offset permet de contrôler et de corriger une dérive d’horloge. SFOS 22 prend en charge SHA1, SHA256 et SHA512 ; l’application d’authentification doit accepter l’algorithme configuré. Changer d’algorithme ou supprimer un token n’est pas un test de diagnostic, mais une migration ou un réenrôlement planifié.

Attribuer le problème de limite User ID uniquement après avoir vu la valeur

Sous Show additional properties, il est possible d’afficher le User ID. Une valeur supérieure à 65535 se trouve hors de la plage prise en charge ; l’utilisateur ne peut alors ni s’authentifier ni devenir un Live User. Le nombre d’utilisateurs visibles ne suffit pas à établir ce diagnostic, car les groupes partagent la même plage d’identifiants.

Si l’identifiant est valide ou si l’utilisateur est toujours totalement absent, poursuivre le diagnostic général. Purge AD users ne s’applique qu’à un cas de nettoyage démontré. La procédure spécialisée et sûre se trouve dans Vérifier la limite User ID de Sophos Firewall.

Approfondir uniquement la méthode utilisée

Une fois le service et le niveau d’échec connus, approfondir seulement la méthode concernée. Le diagnostic reste ainsi ciblé et n’altère pas plusieurs systèmes d’authentification à la fois.

Connexion classique et Captive Portal

Pour une connexion manuelle, vérifier l’URL directe du portail, Device Access, la méthode d’authentification sélectionnée, le statut utilisateur, le mot de passe et la MFA. Pour le Captive Portal, vérifier également que la connexion inconnue atteint la règle prévue avec Use web authentication for unknown users et que le DNS fonctionne avant la connexion. Le nom d’utilisateur et le mot de passe ne peuvent pas dépasser 50 caractères chacun.

La configuration complète, y compris le port 8090, Live Users, la règle utilisateur et la déconnexion, est décrite dans Configurer et tester le Captive Portal de Sophos Firewall.

AD SSO avec Kerberos ou NTLM

Un test de connexion AD réussi ne suffit pas pour SSO. Le nom d’hôte ou FQDN, la résolution DNS, Redirection Location, le certificat, la confiance du navigateur, le Domain Join et, pour Kerberos, le SPN HTTP correspondant doivent également être corrects. Si Kerberos bascule vers NTLM ou Captive Portal, vérifier d’abord ce chemin de nommage et de confiance.

nasm.log est pertinent pour les erreurs NTLM et Kerberos. Ne pas modifier le SPN ou le Domain Join à l’aveugle ; sauvegarder d’abord l’état existant sur le firewall et le contrôleur de domaine.

Si /log/nasm.log affiche une erreur KVNO, le client peut encore détenir un ticket Kerberos avec l’ancienne version de clé après une nouvelle jonction du firewall au domaine. Verrouiller puis déverrouiller d’abord le client Windows, ou déconnecter puis reconnecter l’utilisateur, afin d’obtenir un nouveau ticket. Si l’erreur persiste, vérifier le Key Version Number, l’objet ordinateur du firewall et le SPN sur le contrôleur de domaine ; une nouvelle jonction au domaine n’est pas la première étape.

STAS, SATC et hôtes multi-utilisateurs

Avec Synchronized User ID Authentication, l’identité de domaine Windows et l’IP client arrivent via Security Heartbeat. L’état de l’endpoint, le domaine UPN, sAMAccountName, la validation AD et Live users doivent alors correspondre ; un heartbeat vert ne prouve pas à lui seul la règle utilisateur.

Avec STAS, la même IP client doit être suivie dans les événements Windows, STA Agent, Collector et le firewall. Si l’utilisateur manque uniquement dans Live Users, vérifier l’accessibilité du Collector, les réseaux surveillés, l’Exclusion List et Client Authentication. La procédure complète se trouve dans Configurer STAS sur Sophos Firewall.

Le Legacy SATC Client n’est plus pris en charge. Sophos recommande de migrer les installations SATC vers Sophos Server Protection dans Sophos Fusion. Avant le diagnostic, déterminer quel client SATC est réellement installé ; modifier les règles firewall ou les groupes ne réparera pas un ancien client obsolète.

Plusieurs utilisateurs simultanés derrière une seule IP de serveur Terminal nécessitent un modèle de session. SATC pour Remote Desktop Services peut associer plusieurs protocoles à une session. En revanche, Per-Connection AD SSO pour les hôtes multi-utilisateurs s’applique uniquement aux connexions HTTP et HTTPS via le Direct Web Proxy. Une association IP normale ne peut pas distinguer de façon fiable plusieurs utilisateurs derrière la même adresse.

RADIUS SSO, Entra ID et VPN

RADIUS SSO exige des événements d’accounting avec la bonne IP client ; un test d’accès RADIUS réussi ne prouve pas ce chemin d’accounting. RADIUS SSO avec accounting décrit la configuration et le contrôle de Framed-IP-Address. Le VPN Portal ne prend pas en charge l’authentification RADIUS avec MFA basée sur un challenge ; le rejet d’un tel échange n’indique donc pas un défaut d’ordre des serveurs.

SFOS 22 : Avec Microsoft Entra ID SSO, vérifier également le flux OAuth propre au service. Captive Portal, VPN Portal et WebAdmin utilisent des Redirect URIs, des méthodes d’authentification et des fichiers journaux différents. Une connexion réussie à l’un de ces services ne prouve pas le fonctionnement des autres.

SFOS 23.0 : Sous Authentication > Servers, le type de serveur est OpenID Connect ; IdP vendor distingue Microsoft Entra ID et Google Workspace. Pour le service réellement concerné, utiliser les procédures de validation par version pour Entra WebAdmin, Entra VPN Portal et accès distant ou Google Workspace OIDC. Redirect URI, attribution au service, groupes ou mappage administrateur, MFA et tests positifs, négatifs et d’accès local de secours restent des contrôles distincts. Une connexion réussie à l’IdP n’accorde pas automatiquement des droits d’administrateur.

Pour le VPN, vérifier après l’authentification que l’utilisateur ou son groupe se trouve dans la bonne stratégie d’accès distant. Un état de tunnel vert ne prouve pas encore l’accès aux destinations internes.

L’authentification réussit, mais le trafic reste bloqué

Lorsque l’utilisateur est visible sous Live users avec l’IP attendue, déplacer le diagnostic vers l’autorisation et le chemin des paquets. Un flux de test réel doit montrer :

1. Quelle Firewall Rule ID traite la connexion ?
2. Cette règle contient-elle l’utilisateur attendu ou un groupe pris en charge ?
3. Log firewall traffic est-il activé ?
4. La règle sélectionne-t-elle la bonne stratégie web, Application, IPS ou Traffic Shaping ?
5. La destination, le service, le NAT, la route et le chemin de retour correspondent-ils ?

Une règle IP générale placée au-dessus de la règle utilisateur peut déjà traiter le trafic. De même, la bonne règle utilisateur peut correspondre alors que la stratégie web, TLS Inspection, le DNS, le routage ou le système de destination bloque l’accès par la suite. Une modification d’authentification ne doit donc pas servir à corriger une erreur de routage ou de stratégie démontrée.

Tester correctement une règle Sophos Firewall explique la validation complète avec Log Viewer, Policy tester et Packet Capture.

Corréler Log Viewer et les fichiers journaux

Dans Log viewer, contrôler le module Authentication avec l’utilisateur noté, l’IP source et une période de test étroite. Rechercher ensuite le même instant dans le module firewall ou VPN. Cela permet de déterminer si la connexion elle-même échoue ou si seul le flux de données ultérieur est bloqué.

Pour l’authentification, l’autorisation et l’accounting classiques, access_server.log est le premier fichier à contrôler. Dans l’Advanced Shell, les commandes suivantes sont en lecture seule :

cd /log
tail -n 200 access_server.log

Ajouter uniquement le fichier correspondant à la méthode :

tail -n 200 nasm.log

Les exemples de lecture Entra propres à chaque service ci-dessous s’appliquent uniquement à SFOS 22, pas à SFOS 23 :

tail -n 200 oauth_sso_captive.log
tail -n 200 oauth_sso_webadmin.log
tail -n 200 oauth_sso_vpn.log

• nasm.log concerne NTLM et Kerberos.
• SFOS 22 : oauth_sso_captive.log concerne le flux Entra SSO du Captive Portal.
• SFOS 22 : oauth_sso_webadmin.log concerne Entra SSO pour WebAdmin.
• SFOS 22 : oauth_sso_vpn.log concerne Entra SSO pour VPN Portal, IPsec et SSL VPN.

SFOS 23.0 : Contrôler le flux de connexion OIDC dans /log/oauth_sso_svc.log. Pour Entra, une erreur TLS de Test connection relève en revanche de /log/sfos-macro-cfg.log. Dans Log viewer, utiliser Admin pour WebAdmin et Authentication pour Captive Portal, VPN Portal, IPsec et SSL VPN. Les procédures des fournisseurs liées ci-dessus adaptent la validation et le diagnostic au service réel ; ce diagnostic en lecture seule ne nécessite aucun redémarrage.

Ces commandes lisent uniquement les 200 dernières lignes. Elles n’activent pas le débogage et ne redémarrent aucun service. Ajouter des fichiers tels que vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log ou csd.log seulement après avoir sélectionné la méthode. Journaux des services Sophos Firewall explique leur attribution.

Dans un cluster HA, chaque nœud conserve uniquement les journaux et rapports du trafic qu’il traite. Noter le rôle, l’heure du test et le nœud de traitement, puis contrôler les fichiers sur ce nœud. Un fichier vide sur l’autre appareil ne réfute pas l’erreur.

Diagnostiquer selon le symptôme

Test connection réussit, mais SSO ne fonctionne pas

Le serveur d’authentification et ses identifiants sont joignables. Vérifier ensuite Authentication > Services, Device Access, Live Users et le chemin SSO propre à la méthode. Pour AD, cela inclut notamment le DNS, le FQDN, Redirection Location, le SPN, la confiance du navigateur, le Domain Join et nasm.log.

Captive Portal apparaît au lieu de la connexion transparente

Déterminer d’abord si AD SSO ou STAS devrait identifier l’utilisateur avant l’accès web. Contrôler ensuite Client Type sous Live Users, le module Authentication, Access Time, les quotas et les identifiants. Le portail est le symptôme d’une identité absente ou refusée, pas automatiquement une erreur de portail.

Le nom de l’ordinateur apparaît au lieu du nom d’utilisateur

Un service système peut envoyer les identifiants NTLM du terminal alors qu’aucun utilisateur n’est encore connecté de manière interactive. Connecter un véritable utilisateur, ouvrir une nouvelle session de navigateur et répéter le test. Si le nom de l’ordinateur demeure, vérifier le chemin du navigateur ou du proxy, la méthode SSO et nasm.log.

L’utilisateur manque dans Live Users

Vérifier d’abord la sélection du service, Device Access et la méthode concrète. Pour STAS, le Collector et le firewall doivent voir la même IP ; pour Captive Portal, la connexion doit réellement aboutir ; pour les serveurs externes, l’enregistrement utilisateur local n’est créé qu’après une connexion réussie. Ne contrôler le User ID, la Sign-in Restriction et les quotas que si un enregistrement utilisateur correspondant existe.

L’utilisateur est visible, mais le groupe ou la stratégie est incorrect

Sous Authentication > Users, comparer le groupe principal, Other group memberships et les dérogations propres à l’utilisateur. Vérifier ensuite si la fonction concernée prend en charge plusieurs groupes. Ne modifier l’ordre des groupes que dans une fenêtre de maintenance planifiée, car cela peut également déplacer la MFA, les quotas, Access Time, le VPN et d’autres stratégies.

La connexion réussit, mais Internet ou la destination VPN reste inaccessible

L’authentification n’est plus le premier niveau en défaut. Vérifier la Firewall Rule ID, l’ordre des règles, la journalisation, la stratégie web ou VPN, le NAT, la route et le chemin de retour à l’aide d’un flux réel. L’identité de l’utilisateur et le chemin des paquets doivent tous deux être corrects.

L’erreur survient uniquement après un basculement HA ou de manière sporadique

Noter le build du firmware, le changement de rôle, le rôle actif du nœud, l’heure de connexion et la méthode d’authentification. Tester une nouvelle connexion utilisateur et une nouvelle connexion réseau après le basculement. Contrôler ensuite les journaux du nœud ayant traité la tentative. Ne pas considérer une session existante comme preuve d’une nouvelle authentification réussie.

Conditions d’arrêt et données pour le support

Ne plus modifier la configuration de production lorsque :

• le service ou la méthode d’authentification concerné n’est pas clairement déterminé ;
• Test connection échoue alors que le DNS, la route, le port, TLS ou les identifiants ne sont pas encore clarifiés ;
• l’utilisateur pilote apparaît avec un Client Type inattendu ou une mauvaise IP source ;
• le groupe principal, la dérogation utilisateur ou le quota ne peut pas être attribué de manière compréhensible ;
• un test négatif obtient un accès inattendu ;
• seule une autorisation Device Access ou firewall large semble faire réussir le test ;
• un problème HA ne peut pas être attribué à un nœud de traitement et à un instant précis.

Avant une escalade, recueillir au minimum :

• le modèle d’appliance, la version SFOS et le build complet ;
• en HA, les deux rôles et le nœud de traitement ;
• la source d’authentification et le service concerné ;
• l’utilisateur de test, l’IP source, le Client Type et la période ;
• l’ordre des serveurs sous Authentication > Services ;
• le résultat de Test connection avec sa portée limitée ;
• le statut, le groupe principal, les autres groupes, les dérogations et le User ID ;
• l’événement d’authentification, la Firewall Rule ID et le résultat du flux de test réel ;
• les journaux d’authentification, de portail, de VPN et de firewall correspondants.

Les noms d’utilisateur et de groupe peuvent contenir des informations sensibles. Le paquet doit être transmis uniquement par le canal de support prévu. Créer un Consolidated Troubleshooting Report et un export ciblé des journaux avant tout redémarrage de service, débogage ou nettoyage de données.

Liste de contrôle

• Le cas de test contient l’utilisateur, l’IP source, le service, l’heure et le résultat attendu.
• Le service local est joignable uniquement depuis la zone ou la source prévue.
• Le bon serveur est sélectionné sous Authentication > Services pour le service concerné.
• Test connection n’a pas été confondu avec un test SSO complet.
• Live Users affiche l’utilisateur, l’IP et le Client Type attendu.
• Le statut, le groupe principal, les autres groupes, les dérogations et le User ID ont été contrôlés.
• Access Time, les quotas, la Sign-in Restriction et la MFA ont été évalués uniquement sur le chemin utilisateur effectif.
• Le succès de l’authentification et le flux firewall, web ou VPN ultérieur ont été testés séparément.
• Log Viewer et le fichier journal correspondant ont été corrélés sur la même période.
• En HA, le nœud de traitement a été contrôlé.
• Aucun redémarrage, purge ou élargissement d’autorisation général n’a servi de solution rapide.
• Les données de support ont été recueillies avant d’autres modifications.

Questions fréquentes