Configurer et tester un serveur RADIUS sur Sophos Firewall

RADIUS permet de connecter Sophos Firewall à Microsoft NPS, à une passerelle MFA ou à un autre service d’authentification centralisé. Il faut d’abord préparer le serveur distant et le chemin réseau. On crée ensuite le serveur sous Authentication > Servers, puis on l’attribue uniquement aux services de connexion requis sous Authentication > Services. La validation s’effectue au moyen d’une connexion réelle, avec contrôle de l’utilisateur, du groupe et des règles.

Pour les requêtes classiques portant sur les utilisateurs et les groupes d’un domaine Windows, une connexion directe d’Active Directory à Sophos Firewall est souvent adaptée. Dans les scénarios modernes d’accès à distance, Microsoft Entra ID SSO pour Sophos Connect et VPN Portal peut constituer une architecture plus appropriée. Si le pare-feu doit identifier des utilisateurs Wi-Fi déjà authentifiés à partir de paquets d’accounting entrants, la procédure est différente : configurer RADIUS SSO avec l’accounting sur Sophos Firewall.

Quand utiliser RADIUS

Le pare-feu transmet le nom d’utilisateur et les informations d’identification au serveur RADIUS. La source d’utilisateurs, la Network Policy et, le cas échéant, la MFA déterminent alors si la réponse sera Access-Accept ou Access-Reject. Ce n’est qu’ensuite que le groupe d’utilisateurs local, la stratégie VPN et les règles de pare-feu définissent les ressources accessibles.

Dans le modèle RADIUS, les données d’authentification et d’autorisation sont stockées dans des profils utilisateur. L’autorisation d’un service suppose que la requête corresponde aux attributs prévus, par exemple à l’adresse IP du client RADIUS à l’origine de la requête. Le Shared Secret protège les mots de passe des utilisateurs ; cela n’implique pas le chiffrement de l’ensemble du transport RADIUS.

Cas d’usage courants :

• Remote Access VPN avec Microsoft NPS ou un service MFA ;
• authentification centralisée sur le User Portal, le VPN Portal ou le Captive Portal ;
• solution transitoire lorsqu’AD ou LDAP ne doit pas être directement connecté au pare-feu ;
• plusieurs équipements réseau utilisant le même service RADIUS.

Un réseau Wi-Fi d’entreprise géré par le pare-feu utilise également la sélection du serveur sous Wireless > Wireless settings. La procédure 802.1X complète est donc décrite dans Configurer le Wi-Fi directement sur Sophos Firewall.

Dans le réseau Wi-Fi d’entreprise géré par SFOS, Accounting Request et Accounting Response contiennent des informations de session et d’accounting. Ces messages sont distincts des requêtes, réponses et challenges d’accès utilisés pour la connexion. Pour ce chemin Wi-Fi, Sophos documente la prise en charge de l’accounting sur tous les appareils compatibles Wi-Fi ; le Wireless Network doit utiliser 802.1X et l’accounting doit être activé sur le serveur RADIUS. Le guide Wi-Fi lié explique la séparation des ports et l’absence d’Interim Accounting Updates. La prise en charge de l’accounting ne constitue pas une garantie de prise en charge d’un serveur RADIUS secondaire.

Consigner l’état initial et la procédure de retour arrière

Avant de modifier un service en production, consignez les éléments suivants sous Authentication > Services pour chaque section concernée :

• les serveurs sélectionnés et leur ordre ;
• l’état des options Set authentication methods same as firewall, Same as VPN ou Same as firewall ;
• le paramètre Default group utilisé jusqu’alors pour l’authentification du pare-feu ;
• un utilisateur avec lequel le fonctionnement de la méthode actuelle a été confirmé.

Pour les connexions administrateur, laissez une session WebAdmin existante ouverte pendant la modification. Vérifiez également l’accès d’un super-administrateur local par un chemin d’administration déjà autorisé. La sélection des serveurs pour les administrateurs ne s’applique pas à ce super-administrateur. Il ne faut toutefois jamais modifier une connexion d’administrateur externe sans avoir préalablement validé une solution de repli locale.

Planifier la connexion RADIUS

Rôles, chemin réseau et protocoles

Dans un environnement NPS, Sophos Firewall est le client RADIUS et NPS le serveur RADIUS. NPS évalue la requête selon sa Connection Request Policy et sa Network Policy, et généralement par rapport à Active Directory. Une stratégie VPN ou une règle de pare-feu détermine ensuite toujours l’accès effectif.

L’aide générale de SFOS 22 décrit la communication entre le pare-feu et le serveur RADIUS avec PAP. Sous Authentication > Services, Sophos répertorie toutefois PAP, CHAP et MSCHAPv2 pour les connexions L2TP et PPTP. Cette matrice de protocoles ne confirme pas la prise en charge des mêmes méthodes pour IPsec ou d’autres chemins d’authentification. Il faut donc vérifier conjointement le service, le client et la méthode autorisée sur le serveur RADIUS.

Le protocole RADIUS classique utilise UDP et l’interface SFOS documentée ne propose aucun champ TLS ou de certificat. Le trafic doit donc emprunter un chemin interne contrôlé ou protégé d’une autre manière. Un Shared secret robuste ne remplace ni la segmentation ni une règle restrictive entre le pare-feu et le serveur RADIUS.

Les anciens systèmes distants peuvent utiliser d’autres ports, tels que 1645/UDP et 1646/UDP. Les ports effectivement configurés de part et d’autre font foi, et non ces valeurs historiques.

Choisir délibérément les valeurs d’exemple

Ce guide utilise les valeurs suivantes :

• nom du serveur : NPS-HQ-RADIUS ;
• adresse IP du serveur : 10.20.30.15 ;
• port d’authentification : 1812 ;
• port d’accounting : 1813 ;
• délai d’expiration : 5 secondes ;
• nom de domaine : corp.example.

Remplacez 10.20.30.15 et corp.example par l’adresse interne et la convention de nommage de votre environnement. Cinq secondes constituent une valeur initiale pour une vérification directe du mot de passe, et non la valeur par défaut de Sophos. Pour une notification push, un appel téléphonique ou un challenge externe, la valeur doit être adaptée au fournisseur et au client réel, dans la plage de 1 à 60 secondes autorisée par SFOS.

Le Shared secret est le secret technique partagé par le client et le serveur RADIUS, et non le mot de passe d’un utilisateur. Sophos le limite à 48 caractères. Cette valeur doit être transmise par un canal séparé et protégé, stockée de manière sécurisée et saisie à l’identique des deux côtés. RADIUS ne transmet pas le secret lui-même sur le réseau.

Créer le serveur RADIUS sous Authentication

Le chemin de menu est Authentication > Servers.

1. Ouvrez Add, puis sélectionnez RADIUS server sous Server type.
2. Saisissez par exemple NPS-HQ-RADIUS sous Server name.
3. Sous Server IP, saisissez l’adresse IP interne du serveur RADIUS, soit 10.20.30.15 dans cet exemple.
4. Faites correspondre Authentication port au port du serveur, généralement 1812.
5. Définissez Time-out. Pour le premier test direct, cet exemple utilise 5 secondes.
6. Activez Enable accounting uniquement si le serveur distant doit traiter les données d’accounting. Dans ce cas, faites également correspondre Accounting port, généralement 1813.
7. Saisissez le Shared secret exactement comme sur le serveur distant.
8. Définissez éventuellement Domain name. Lorsqu’AD et RADIUS sont utilisés en parallèle, un domaine identique évite qu’une même personne apparaisse sous la forme de plusieurs objets utilisateur locaux. Avec Domain name, un objet utilisateur local au format user@domainname est automatiquement créé lors de la première connexion. Sans cette valeur, RADIUS crée un utilisateur sans domaine, tandis qu’AD crée un objet utilisateur qualifié par le domaine ; deux objets utilisateur locaux peuvent ainsi être créés pour une même personne.
9. Renseignez Group name attribute uniquement s’il est établi que le serveur distant renvoie l’attribut attendu. L’aide Sophos le décrit comme un alias du nom de groupe configuré, mais ne documente ici aucun mappage générique d’attributs NPS arbitraires vers des groupes locaux.
10. Ouvrez Enable additional settings uniquement si la stratégie l’exige. NAS-identifier identifie le Network Access Server à l’origine de la requête, par exemple au moyen d’un FQDN. NAS-port-type décrit le type de port utilisé pour la connexion.
11. Exécutez Test connection avec un utilisateur pilote dédié, puis sélectionnez Save.

Le pare-feu prend en charge au maximum 20 serveurs d’authentification configurés au total. Il est également possible de sélectionner au maximum 20 serveurs par méthode d’authentification sous Authentication > Services.

Limites de l’API pour SFOS 22 et 23

Pour l’automatisation, lisez les références API séparément de la procédure WebAdmin. Les remarques suivantes décrivent la documentation, et non un comportement testé ici sur un appliance ; elles ne constituent pas une requête Add/Edit exécutable.

• Exemple XML et tableau des paramètres : L’exemple imbrique RADIUSServer dans AuthenticationServer. Il utilise ServerAddress, Port et DomainName ; le tableau utilise en revanche ServerIP, AuthenticationPort et domainName. Ne considérez pas ces graphies comme interchangeables en supposant une normalisation des balises.
• Accounting : Le commentaire de l’exemple indique qu’il faut inclure AccountingPort pour activer l’accounting ; sans ce paramètre, il est désactivé. Cela ne démontre pas un comportement testé lorsqu’un champ est omis lors d’un Edit ou d’une mise à jour partielle. 2222 est uniquement la valeur de l’exemple XML, et non la valeur par défaut de WebAdmin 1813 ; ne supprimez pas silencieusement le port d’accounting prévu du XML généré.
• Valeurs non résolues : Pour IntegrationType, l’exemple indique LooseIntegration/TightIntegration, mais le tableau indique Only '1' are allowed. ; pour ServerType, il indique Only '4' are allowed.. N’en déduisez aucune correspondance d’énumérations ni aucune valeur de requête valide. Pour les modifications, la procédure WebAdmin ci-dessus reste la voie sûre tant que la syntaxe API de la version déployée n’est pas clarifiée.
• Limites des entrées API : ServerName est une chaîne de 50 caractères au maximum ; UTF-8 est autorisé, les virgules sont interdites. GroupNameAttribute et domainName sont des chaînes de 50 caractères au maximum chacune. AuthenticationPort est un entier de 1 à 65535, avec 5 chiffres au maximum et la valeur par défaut documentée 1812. Le tableau marque ServerIP, AuthenticationPort, SharedSecret et GroupNameAttribute avec Yes dans Mandatory ; le conseil WebAdmin ci-dessus concernant Group name attribute ne rend pas le champ API facultatif. Il s’agit de limites de la référence API, et non de restrictions de l’interface graphique nouvellement confirmées.
• Delete et identité : Delete documente également ServerName comme identifiant du serveur, avec les mêmes limites de nom. Pour la suppression prévue, utilisez le nom existant exact, et non un nom normalisé à nouveau. Bien qu’Add/Edit et Delete indiquent pour ServerName la mention Mandatory: No avec une cellule Default vide, cela ne démontre ni la suppression sans nom, ni la suppression avec caractères génériques ou en masse. Les contrôles des attributions de services et la procédure de retour arrière sécurisé décrits plus bas restent nécessaires.

Note API pour SFOS 23 : La référence API pour l’ajout et la modification des serveurs RADIUS ajoute le paramètre facultatif EmailAddressAttribute (chaîne de caractères, 50 caractères maximum) et l’inclut dans l’exemple XML de RADIUSServer. Aucune valeur par défaut n’est indiquée. Cette note concerne la documentation API, et non un champ WebAdmin supplémentaire.

Réponses API lors de la migration de SFOS 22 vers 23 : Pour les automatisations existantes, les classes de réponse documentées changent lors de l’ajout et de la modification de serveurs RADIUS. Les références API indiquent les valeurs suivantes dans la colonne Status :

Il convient donc de vérifier le traitement des réponses séparément pour chaque version de SFOS et chaque opération ; une logique reposant exclusivement sur les anciennes valeurs d’erreur ne suffit pas pour SFOS 23. Ces valeurs sont des valeurs de statut API documentées, et non une preuve de codes de statut HTTP. Les clés JavaScript de la colonne Message ne permettent pas d’établir un texte de réponse précis à l’exécution. Les tableaux ne fournissent ni correspondance univoque entre chaque ancienne erreur et une nouvelle, ni règle de nouvelle tentative.

Bien comprendre l’accounting

Avec Enable accounting, le pare-feu envoie, pour les types de clients pris en charge, un message Accounting-Start à la connexion et un message Accounting-Stop lors d’une déconnexion normale. Sophos répertorie les types suivants : Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client et API client. Les requêtes Start et Stop contiennent également l’heure de connexion et l’heure de déconnexion, respectivement.

Aucun message Accounting-Stop n’est envoyé lors de l’arrêt ou du redémarrage du pare-feu. Si une session reste ouverte sur le serveur RADIUS, comparez donc l’heure du redémarrage avec les journaux RADIUS. Cette fonction d’accounting sortant est différente de l’accounting RADIUS SSO entrant, grâce auquel le pare-feu apprend les sessions provenant d’autres systèmes.

Préparer Microsoft NPS comme serveur distant

Sophos Firewall doit être défini comme client RADIUS sur NPS. Dans la console Network Policy Server, le contrôle minimal est le suivant :

1. Ouvrez RADIUS Clients and Servers > RADIUS Clients.
2. Créez un New RADIUS Client avec un Friendly name unique, tel que Sophos-Firewall-HQ.
3. Sous Address (IP or DNS), saisissez l’adresse depuis laquelle NPS reçoit réellement la requête.
4. Sous Vendor, sélectionnez généralement RADIUS standard.
5. Saisissez le même Shared secret que sur le pare-feu.
6. Dans la Connection Request Policy et la Network Policy appropriées, vérifiez les conditions, la décision d’accès et la méthode d’authentification autorisée pour l’utilisateur pilote.
7. Préparez Event Viewer et les journaux d’accounting NPS en vue de la validation.

Avec un cluster HA, des connexions routées ou du NAT, ne déduisez pas l’adresse du client NPS à partir de la topologie. Un premier test permet de voir dans NPS quelle adresse IP source arrive réellement. Si la requête est totalement absente ou si NPS ne peut pas la valider, vérifiez d’abord le routage, l’autorisation UDP, l’adresse du client RADIUS et le Shared secret. Un Access-Reject ordinaire indique en revanche un problème lié à l’utilisateur, à la stratégie ou à la méthode d’authentification.

Attribuer RADIUS aux services appropriés

Après l’enregistrement, l’objet serveur n’est encore actif pour aucune connexion. Sous Authentication > Services, SFOS 22 propose les sections suivantes :

• Firewall authentication methods ;
• User portal authentication methods ;
• VPN portal authentication methods ;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods ;
• Administrator authentication methods ;
• SSL VPN authentication methods.

Pour le User Portal, le VPN Portal, le VPN et les administrateurs, la sélection des serveurs peut être liée à celle de l’authentification du pare-feu. SSL VPN propose Same as VPN et Same as firewall. Avant toute modification, vérifiez donc si la section concernée utilise sa propre liste ou une liste liée.

Pour un pilote limité, ajoutez NPS-HQ-RADIUS uniquement à la section requise, placez-le à la position prévue, puis sélectionnez Apply. Le pare-feu interroge plusieurs serveurs dans l’ordre affiché. Si un utilisateur peut déjà s’authentifier sur un serveur placé plus haut dans la liste, la stratégie MFA RADIUS située en aval ne sera pas sollicitée.

Captive Portal et Default Group

Le Captive Portal ne dispose d’aucune section dédiée sous Authentication > Services. Il utilise Firewall authentication methods. La zone prévue doit également autoriser Captive portal sous Administration > Device access, et une règle de pare-feu basée sur les utilisateurs doit être configurée de manière appropriée. Le test fonctionnel officiel consiste à se connecter à l’adresse https://<firewall-ip>:8090.

Le paramètre Default group sous Firewall authentication methods est important pour la sécurité. Lors de sa première connexion réussie à un service de pare-feu, un utilisateur externe est créé sous Authentication > Users. En l’absence d’une attribution à un groupe local approprié, le paramètre Default group configuré s’applique. Avant le pilote, vérifiez les stratégies de ce groupe ainsi que toutes les règles qui l’utilisent ; un Default group disposant de privilèges trop larges ne doit pas devenir un mécanisme de repli à votre insu.

Distinguer la MFA par challenge selon le service

Selon l’aide de SFOS 22, le VPN Portal ne prend pas en charge l’authentification RADIUS avec une MFA basée sur un challenge. La réussite de Test connection ne permet donc pas de conclure que ce chemin d’accès au portail fonctionne. Les notifications push, les appels, les OTP et les challenges ne sont pas non plus interchangeables : chaque client et chaque service prévu doivent être testés séparément. Pour la MFA locale de Sophos Firewall, suivez la procédure dédiée : Activer la MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access.

Valider la configuration

1. Connexion et serveur distant

Sous Authentication > Servers, ouvrez NPS-HQ-RADIUS et exécutez Test connection avec l’utilisateur pilote. Vérifiez simultanément les points suivants dans NPS ou dans les journaux de l’autre serveur distant :

• la requête provient de l’adresse attendue du pare-feu ;
• elle est traitée par la bonne stratégie ;
• le résultat est Access-Accept ;
• les attributs de réponse attendus sont présents.

Ce test confirme les informations d’identification et la communication avec le serveur. Il ne valide pas encore l’ordre des services, la stratégie VPN, le groupe local ou la règle de pare-feu.

2. Tester le service réel

Connectez-vous ensuite avec le même utilisateur via le service prévu. Les prérequis diffèrent pour le Captive Portal, SSL VPN, IPsec, le User Portal et WebAdmin. Pour WebAdmin, le profil administrateur prévu doit en outre être attribué à l’utilisateur externe ; une authentification RADIUS réussie ne confère à elle seule aucun droit d’administration. Les chemins inutiles restent inchangés. Pour SSL VPN, Configurer l’accès à distance SSL VPN sur Sophos Firewall décrit la stratégie, le Device Access et la règle de pare-feu.

Après une connexion réussie, vérifiez les éléments suivants :

1. Sous Authentication > Users, contrôlez l’utilisateur local, le domaine et le Main Group effectif.
2. Sous Current activities > Live users, contrôlez la session active ; vous pouvez, si nécessaire, y mettre fin avec Disconnect.
3. Dans le Log viewer, en haut à droite de WebAdmin, ouvrez le module Authentication et filtrez par utilisateur, adresse IP source et plage horaire de test restreinte.
4. Dans le journal du trafic, contrôlez la Firewall Rule ID effectivement utilisée et assurez-vous que seule la ressource cible autorisée est accessible.
5. Testez le cas négatif avec un utilisateur qui n’est pas autorisé par la stratégie NPS.

Si l’authentification réussit, mais que l’application reste inaccessible, vérifiez la zone, le pool d’adresses IP du VPN, le groupe, la position de la règle, le NAT et le routage. Sophos Firewall : déterminer pourquoi une règle de pare-feu ne s’applique pas décrit le diagnostic de ce chemin de données. Si l’identité, la sélection du service ou le Main Group ne sont pas clairement établis, consultez Résoudre méthodiquement les erreurs d’authentification de Sophos Firewall.

Isoler les erreurs en fonction des symptômes

Le serveur distant ne reçoit aucune requête

Vérifiez d’abord les valeurs configurées sous Server IP et Authentication port. Contrôlez ensuite le routage et l’autorisation du trafic UDP 1812 entre l’adresse source utilisée par le pare-feu et 10.20.30.15. Un objet serveur RADIUS ne crée pas automatiquement de règle de pare-feu pour le trafic en transit.

Pour un réseau sans fil géré par SFOS, Sophos documente un cas particulier strictement limité : si le serveur RADIUS est connecté au pare-feu par un tunnel IPsec, un mappage Source NAT est nécessaire pour les réseaux des points d’accès. Il traduit l’adresse IP source précisément en l’adresse IP du pare-feu par laquelle celui-ci atteint le serveur RADIUS. L’aide Wireless renvoie pour cela à une configuration via le shell avec sys-traffic-nat ; elle ne fournit toutefois pas ici de commande complète exécutable. Avant toute modification, les réseaux des points d’accès, l’adresse source réellement utilisée, l’adresse du pare-feu à utiliser pour la traduction de source, le tunnel, le chemin de retour et les journaux RADIUS doivent être établis et documentés. Sans syntaxe confirmée à cet effet, la configuration concrète du shell, y compris sa vérification et son retour arrière, doit faire l’objet d’une escalade technique ciblée. Pour les autres chemins RADIUS, ce guide Wi-Fi n’établit aucune exigence générale de NAT. Une règle LAN vers VPN ou un exemple de route Forwarding-IPsec ne remplace pas cette procédure de traitement du trafic système.

NAT du trafic système pour un chemin Wireless-IPsec confirmé

L’aide CLI distincte de SFOS 22 et 23 documente la syntaxe ci-dessous. Il s’agit d’un modèle vérifié dans la documentation, et non d’un test réalisé ici sur un appliance. Il complète le cas particulier Wi-Fi décrit plus haut ; il ne remplace ni la vérification des réseaux des AP ni la planification du tunnel et du chemin de retour.

⚠️ Avant la modification : Une modification NAT peut interrompre l’authentification et d’autres services système vers la même destination. Préparez une sauvegarde, une fenêtre de maintenance et un accès administrateur indépendant. La destination RADIUS, l’IP source observée, l’IP requise du pare-feu, les sélecteurs IPsec ou la route, le chemin de retour et l’adresse du client NPS doivent être cohérents. Si ce chemin n’est pas confirmé, une escalade technique reste nécessaire.

Connectez-vous à la Command-line console avec des droits administratifs et sélectionnez 4 – Device Console, et non Advanced Shell. Consignez d’abord la configuration existante à l’aide de cette commande en lecture seule :

show advanced-firewall

L’exemple IPv4 ci-dessous ne s’applique que si 10.20.30.15 est le serveur RADIUS et 10.40.50.1 l’adresse IP exacte du pare-feu prévue pour ce chemin. Remplacez les deux adresses. 255.255.255.255 limite la destination à un hôte ; un masque plus large englobe d’autres destinations. La commande ne comporte aucun filtre de réseau source ni de port : elle ne sélectionne pas uniquement un réseau d’AP ou UDP 1812. Sans interface, le mappage s’applique au trafic vers cette destination passant par n’importe quelle interface du pare-feu. Un paramètre interface <interface> vérifié peut limiter la portée ; ne devinez pas le nom d’une interface. N’écrasez et ne supprimez pas de mappages existants ou qui se chevauchent sans les avoir vérifiés.

Ajoutez le mappage uniquement si ces effets ont été expressément autorisés et si aucun mappage approprié n’existe déjà :

set advanced-firewall sys-traffic-nat add destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Avec un véritable client Wi-Fi de test, vérifiez ensuite 802.1X, Accounting-Start et une déconnexion normale avec Accounting-Stop. Les journaux RADIUS doivent indiquer l’IP source attendue du pare-feu, la décision Access-Accept et les données d’accounting reçues ; contrôlez aussi le tunnel, le chemin des réponses et les autres services vers la même destination. L’affichage du mappage NAT ne prouve pas à lui seul que la connexion fonctionne. En cas d’écart, n’élargissez pas les règles d’accès.

Pour annuler uniquement le mappage d’exemple nouvellement ajouté, utilisez les mêmes valeurs adaptées avec delete. Si vous avez ajouté interface, conservez le même paramètre lors de la suppression :

set advanced-firewall sys-traffic-nat delete destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Comparez avec l’état initial consigné et testez à nouveau l’authentification d’origine ainsi que les services système concernés. Une erreur de console ou une entrée ambiguë impose de s’arrêter, et non d’effectuer une réinitialisation globale.

NPS répond par Access-Reject

Un rejet indique que le chemin réseau et le port fonctionnent en principe. Vérifiez alors dans NPS le Reason Code, la Network Policy appliquée, l’état de l’utilisateur et la méthode d’authentification autorisée. Un Shared secret incorrect entraîne en revanche des réponses absentes, non valides ou invérifiables.

Test connection réussit, mais pas la connexion au service

Sous Authentication > Services, vérifiez la section appropriée, les options de liaison, l’ordre des serveurs et l’application des modifications avec Apply. Pour le Captive Portal, contrôlez également Device access et la règle de pare-feu basée sur les utilisateurs. Pour SSL VPN, l’appartenance à la stratégie, l’accès SSL VPN sous Device Access et la règle de pare-feu requise doivent être correctement configurés.

La connexion réussit, mais le mauvais groupe s’applique

Sous Authentication > Users, examinez le domaine et le Main Group. Comparez ensuite Group name attribute, les attributs renvoyés par le serveur distant et Default group. Une authentification réussie ne prouve pas que l’autorisation attendue est appliquée. Il faut donc confirmer que l’utilisateur non autorisé utilisé pour le test est bien refusé en raison de la condition de groupe ou de la condition NPS.

Une notification push ou un challenge expire

Utilisez le client réel et comparez les horodatages dans les journaux du pare-feu, de NPS et du fournisseur MFA. N’augmentez le délai d’expiration SFOS que dans la plage de 1 à 60 secondes et choisissez la valeur la plus faible couvrant de manière fiable le déroulement normal du challenge. Sur le VPN Portal, l’allongement de ce délai ne permet pas de faire fonctionner la MFA RADIUS basée sur un challenge, car Sophos ne prend pas en charge ce chemin.

Effectuer un retour arrière sécurisé

Si le pilote échoue, restaurez, dans la section concernée sous Authentication > Services, la liste de serveurs précédemment consignée, son ordre, les options de liaison et le paramètre Default group, puis sélectionnez Apply. Connectez ensuite l’utilisateur de référence avec la méthode initiale et vérifiez l’accès du super-administrateur local.

Ne retirez NPS-HQ-RADIUS des autres attributions de services qu’une fois tous les services concernés de nouveau opérationnels. Ne supprimez l’objet serveur sous Authentication > Servers que s’il n’est plus destiné à aucun usage. Sur NPS, restaurez le client, la stratégie et le Shared secret dans leur état initial documenté. Les objets utilisateur locaux déjà créés doivent être contrôlés séparément ; leur suppression ne met pas automatiquement fin à toutes les sessions existantes. Vérifiez donc également Current activities > Live users.

Exploitation

RADIUS est un service d’identité de production. Après toute modification de NPS, du fournisseur MFA, d’AD ou de l’ordre des services, la validation doit inclure un véritable test de connexion autorisée et un véritable test de connexion refusée. Le Shared secret doit être documenté de manière sécurisée et renouvelé selon un calendrier défini. Mettez en place une supervision du serveur distant et définissez la durée de conservation de ses journaux de décision. Vous pourrez ainsi déterminer si une erreur est survenue en amont du pare-feu, pendant l’authentification ou seulement lors de l’autorisation.

FAQ