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.

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.

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 :

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 ?

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, une session normale existante peut être déconnectée sous Live users. 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. Les Clientless Users ne sont pas déconnectés ici avec Disconnect ; il faut les passer à Inactive sous Authentication > Clientless users.

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.

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.

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.

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.

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 nécessite des événements d’accounting contenant 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.

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.

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
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.
• oauth_sso_captive.log concerne le flux Entra SSO du Captive Portal.
• oauth_sso_webadmin.log concerne Entra SSO pour WebAdmin.
• oauth_sso_vpn.log concerne Entra SSO pour VPN Portal, IPsec et SSL VPN.

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