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.

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.

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

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.

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 lorsqu’un serveur RADIUS se trouve derrière IPsec : le trafic est généré par le système et un NAT du trafic système peut être nécessaire. Cette documentation Wi-Fi ne permet pas de généraliser ce comportement aux autres chemins RADIUS. Dans les deux cas, vérifiez l’adresse source réellement utilisée et faites valider toute modification de routage ou de NAT, plutôt que de transposer sans contrôle la règle LAN vers VPN.

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