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.

Le 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.

Distinguer les limites finies de l’API et Unlimited : La documentation de l’ancienne API XML pour SFOS 22 et SFOS 23 indique, pour MaximumSessionTimeoutMinutes, une plage finie de 3–1440 minutes et, pour SimultaneousLogins, une plage de 1–99 connexions simultanées. L’exemple présente en revanche Unlimited/{minutes} et Unlimited/{count} ; le tableau comporte, en plus des lignes numériques INTEGER, des lignes STRING distinctes pour Unlimited. L’option sans limite ne permet pas de déduire un attribut Unlimited ni une charge utile prête à être envoyée. Les suites séparées par des barres obliques ne sont pas des valeurs littérales à utiliser en production. Des colonnes de valeurs par défaut vides ou des champs facultatifs ne permettent de déduire ni un comportement précis en cas d’omission, ni que zéro ou une valeur vide signifie Unlimited. Lire d’abord la sélection réellement enregistrée et les limites effectives des utilisateurs ; la limite globale de connexions continue de s’appliquer uniquement aux utilisateurs créés après sa définition. Avant toute opération d’écriture en production, faire clarifier par le support toute ambiguïté d’automatisation pour le build concerné.

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.

NTLM : comparer les minutes et les octets. La documentation de l’ancienne API pour SFOS 22 et SFOS 23 indique, pour NTLMInActivtyTime, une valeur par défaut de 6 minutes et une plage de 6–1440 minutes, et, pour NTLMDataTransferThreshold, une valeur par défaut de 1024 octets. Pour le seuil en octets, elle indique uniquement un maximum de dix chiffres, sans plage numérique complète ; aucun minimum ni maximum numérique n’en est déduit. L’orthographe InActivty est reprise littéralement de l’API, tout comme NTLMChallegeRedirect pour la redirection du challenge : ne pas les remplacer silencieusement par des clés supposées correctes. Ces valeurs documentées ne sont pas des valeurs lues sur votre propre firewall et ne justifient ni de rétablir les valeurs par défaut en production ni de désactiver HTTP challenge redirect on intranet zone.

Client web iOS : utiliser sa propre plage documentée. Pour iOSWebClientInActivtyTime, la même documentation de l’ancienne API indique une valeur par défaut de 6 minutes et une plage de 6–1440 minutes ; pour iOSWebClientDataTransferThreshold, une valeur par défaut de 1024 octets et une plage de 1–4294967295 octets. Les minutes ne sont pas des secondes, et les octets ne sont pas des kilooctets. Ici aussi, l’orthographe API InActivty reste inchangée. L’opération iOS ne prouve pas que les clés ou les plages numériques sont identiques pour Android ou les clients API, même si l’interface graphique regroupe ces types de clients dans le même bloc de paramètres du client web.

Pour ces limites, commencer par comparer, uniquement en lecture seule, l’état enregistré sous Authentication > Services, le Client Type réel, les unités et, en cas de tentative API échouée, la requête et la réponse correspondante, après suppression des secrets. Une valeur rejetée ne prouve pas qu’elle a été enregistrée ; une valeur par défaut documentée ne prouve pas qu’elle est actuellement définie. À l’aide d’une nouvelle connexion avec le compte pilote, du trafic corrélé dans le temps et des journaux Authentication décrits ci-dessous, vérifier si la déconnexion correspond au couple durée/seuil en octets réellement enregistré. Avant toute correction approuvée, sauvegarder les valeurs précédentes et vérifier un accès d’administration local indépendant du chemin d’authentification externe étudié. Ensuite, contrôler de nouveau l’état enregistré, la connexion du compte pilote, le Client Type, le test négatif et la correspondance avec la règle. En cas d’effet inattendu, restaurer uniquement les valeurs concernées telles qu’elles ont été documentées, puis relire l’état ; ne pas utiliser globalement Reset to default. Comparer ces limites avec l’aide du build installé avant chaque opération.

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 les listes d’authentification VPN dans l’API XML

Lors de modifications automatisées, vérifier séparément la sélection du service et la liste des serveurs. Les chemins XML suivants concernent la source d’authentification, et non la robustesse du protocole VPN, le chiffrement ou la configuration MFA.

• Pour SSL VPN, le sélecteur se trouve sous SSLVPNAuthentication/SSLVPNAuthenticationMethods. Dans SFOS 22 et SFOS 23, l’exemple et le tableau des paramètres concordent : SameAsVPN, SameAsFirewall et Custom sont les valeurs documentées. Les deux premières reprennent respectivement la liste d’authentification VPN et celle du firewall ; Custom correspond à une sélection de serveurs propre à SSL VPN sous SSLVPNAuthentication/SSLVPNAuthenticationServerList/AuthenticationServer.
• Pour les autres authentifications VPN, l’exemple sous VPNAuthentication/VPNAuthenticationMethods indique en revanche SameAsFirewall/Custom, avec la liste des serveurs sous VPNAuthentication/VPNAuthenticationServerList/AuthenticationServer. Cependant, le tableau des paramètres regroupe VPNAuthenticationMethods/UserPortalAuthenticationMethods et n’autorise que les tokens écrits sous la forme ''on'' et ''off''. Cette contradiction existe dans les deux versions. Elle ne permet de déduire aucune conversion vérifiée entre les valeurs de l’exemple et celles du tableau ; elle ne démontre pas non plus l’existence d’un alias ou d’une compatibilité des sélecteurs avec le User Portal. Ne pas modifier automatiquement un sélecteur VPN en production sur la base de cette correspondance ; faire clarifier le conflit par le support pour le build concerné.

Pour les deux listes de serveurs, le tableau décrit AuthenticationServer comme un ARRAY facultatif de type STRING, pouvant contenir plusieurs valeurs. Les noms des serveurs doivent correspondre à votre configuration. Le sélecteur SSL VPN est indiqué comme un SCALAR facultatif, tandis que l’entrée combinée VPN/User Portal du tableau est indiquée comme un SCALAR obligatoire. Les colonnes de valeurs par défaut sont vides ; cela ne confirme aucun comportement pour les champs omis ou laissés vides. Les suites de choix séparés par des barres obliques dans l’exemple ne sont pas des valeurs prêtes à être envoyées telles quelles.

Avant toute modification approuvée, sauvegarder la sélection actuelle, l’ordre, la liste effectivement héritée et l’accès local de secours testé. Ensuite, vérifier l’état enregistré sous Authentication > Services, effectuer une nouvelle connexion avec le compte pilote, contrôler le Client Type, réaliser un test négatif et vérifier la correspondance réelle avec la règle. En cas de résultat inattendu, examiner l’état enregistré et les journaux correspondants au lieu de réécrire à l’aveugle ; si nécessaire, restaurer uniquement la configuration concernée telle qu’elle a été documentée. Contrôler séparément la requête, la réponse de l’opération et l’état réel de l’objet.

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 et SFOS 23 prennent 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, Web client, 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.

Valider l’API avant de diagnostiquer le réseau d’accounting : La documentation de l’ancienne API XML pour SFOS 22 et SFOS 23 limite SharedSecret à 50 caractères. Un secret généré plus long peut donc expliquer le rejet d’une configuration, mais pas une erreur réseau d’accounting. ClientIP y est documenté comme un ARRAY à plusieurs valeurs, de type de données IPADDRESS, avec un maximum de 15 caractères ; le champ de l’interface graphique est RADIUS client IPv4. Cela ne prouve pas la prise en charge d’IPv6. La description iOS copiée sur la page de l’API RADIUS est une erreur de documentation, et non une indication de compatibilité RADIUS/iOS. Comparer d’abord l’émetteur réel à l’IP client autorisée enregistrée et vérifier de manière sûre que la configuration du secret correspond des deux côtés ; ne jamais afficher de véritables secrets ni les inclure dans des journaux, des captures d’écran ou des paquets de support. Ne pas raccourcir, affaiblir ou renouveler les secrets de production à des fins de diagnostic. En cas d’erreur API, lire la réponse expurgée et l’état réellement enregistré au lieu de réécrire à l’aveugle. Un changement d’identifiants nécessaire constitue une modification distincte, à approuver séparément et à coordonner des deux côtés, avec un accès d’administration local sécurisé et une procédure de retour arrière documentée ; contrôler ensuite la configuration enregistrée, l’événement d’accounting, l’utilisateur et son IP sous Live users, ainsi que la correspondance avec la règle.

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.

Contrôles propres à chaque méthode avant de modifier la configuration

AD SSO : heure, DNS et diagnostic sécurisé

Comparez les horloges du client, du pare-feu et du contrôleur de domaine. Les tickets Kerberos ont une durée de validité limitée ; la tolérance par défaut est de cinq minutes, mais la stratégie du domaine configurée fait référence. Vérifiez la résolution de _ldap._tcp.dc._msdcs.<AD domain> et les requêtes de recherche AD. Lire les groupes de l’annuaire et joindre le pare-feu au domaine nécessitent des droits différents : conservez un compte disposant des droits délégués appropriés pour une nouvelle jonction après un changement HA, une mise à niveau ou un changement de serveur. Ne faites pas du compte de test un Domain Admin.

Les instructions de dépannage proposent d’utiliser temporairement Plaintext sur le port 389, alors que la configuration AD prend en charge STARTTLS sur 389 ou SSL/TLS sur 636. Ne désactivez pas le chiffrement d’un chemin d’authentification en production pour isoler une panne. Vérifiez plutôt la chaîne TLS, le nom, le port et les journaux AD ; transmettez au support tout échec de connexion sécurisée non résolu. Dans Authentication > Services, examinez HTTP challenge redirect on intranet zone plutôt que de le désactiver pour contourner la confiance du navigateur. Diagnostiquez le nom de redirection et la confiance intranet avec la procédure AD.

SATC et STAS : distinguer enregistrement et accessibilité

Pour SATC, l’option 4. Device Console fournit ce contrôle d’enregistrement en lecture seule :

system auth thin-client show

Comparez les adresses affichées aux serveurs de terminaux. Si un serveur manque, suivez la procédure de configuration et de récupération SATC, sans modifier l’enregistrement de manière improvisée. Vérifiez le serveur AD sélectionné, la destination des événements SATC et si un proxy ou un logiciel de sécurité modifie les ports source. Une discordance de ports peut laisser le trafic non authentifié malgré l’enregistrement de l’adresse.

Pour STAS, vérifiez que l’hôte Collector et son service fonctionnent, que UDP 6060 et 6677 sont autorisés uniquement sur les chemins nécessaires, qu’aucun logiciel de sécurité n’interfère et qu’un Collector à plusieurs interfaces réseau est lié à la bonne interface. À travers IPsec, vérifiez la source SNAT du trafic généré par le système. SFOS peut rejeter le trafic de l’utilisateur inconnu en attendant son identification par le Collector. Un délai de deux minutes avant le portail peut correspondre à la période d’apprentissage par défaut de 120 secondes. Ne la réduisez pas sous 20 secondes comme solution rapide. Les événements DCOM Windows 10009 ou 10028, ou les associations LogonType: 1 issues de réseaux non surveillés, nécessitent un contrôle de WMI et de la concordance des filtres de sous-réseaux Agent/Collector. Suivez le diagnostic et la récupération contrôlée STAS ; relevez les anciens filtres et temporisations avant toute modification et retestez un utilisateur pilote après tout redémarrage nécessaire.

Chromebook SSO et SSL VPN

Chromebook SSO est distinct de Google Workspace OIDC. Dans Authentication > Services > Chromebook SSO, comparez Domain, Port, Certificate et Logging level à la configuration des appareils gérés. Le certificat doit avoir une clé privée, sa CA associée installée et un CN correspondant au nom de passerelle prévu pour le réseau des utilisateurs. Poursuivez avec la procédure Chromebook SSO pour le certificat, l’extension et les règles.

Pour SSL VPN, comparez les utilisateurs/groupes de la stratégie d’accès distant à Authentication > Multi-factor authentication et vérifiez l’erreur exacte du client. Les noms d’utilisateur Sophos Connect doivent utiliser ASCII ; vérifiez aussi les séquences de caractères spéciaux non prises en charge. Les instructions SSL VPN mentionnent à la fois la MFA par appel/push et <password><otp> ; il ne s’agit pas d’une procédure combinée universelle. Ajoutez un OTP uniquement pour un flux configuré mot de passe plus OTP, pas pour corriger un push ou un appel échoué. Confirmez la méthode MFA réelle et la compatibilité client/serveur avec la procédure SSL VPN, sans désactiver la MFA.

Pour les installations L2TP/PPTP existantes, comparez aussi le protocole négocié : local et RADIUS prennent en charge PAP, CHAP ou MSCHAPv2 ; AD et LDAP utilisent PAP ; TACACS+ prend en charge PAP ou CHAP. C’est un contrôle de compatibilité, pas une recommandation de déployer PPTP ou d’affaiblir le chiffrement. Après toute correction approuvée, répétez la nouvelle connexion, le contrôle du type de client, le test de refus d’accès et la correspondance de règle ; restaurez la configuration relevée si la correction échoue.

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