Configurer RADIUS SSO avec accounting sur Sophos Firewall

RADIUS SSO connecte un utilisateur à Sophos Firewall sans portail captif supplémentaire. L’utilisateur s’est déjà authentifié sur un réseau sans fil, un serveur d’accès réseau ou un autre système RADIUS. Le pare-feu reçoit ensuite un paquet d’accounting RADIUS contenant le nom d’utilisateur et l’adresse IP du client, puis peut utiliser cette association dans les règles basées sur les utilisateurs.

Le point décisif n’est pas seulement une connexion 802.1X réussie. Le pare-feu doit recevoir un Accounting-Start exploitable provenant exactement de l’expéditeur configuré. Pour le Wi-Fi SSO, Sophos utilise la Framed-IP-Address de ce paquet de démarrage. Si l’adresse IP du client manque, le pare-feu connaît peut-être le nom d’utilisateur, mais ne peut l’associer à aucun trafic.

⚠️ RADIUS SSO n’est pas identique à Enable accounting dans l’objet serveur RADIUS. Sous Authentication > Servers, Enable accounting signifie que le pare-feu envoie l’accounting à un serveur RADIUS. Sous Authentication > Services > SSO using RADIUS accounting request, le pare-feu reçoit au contraire l’accounting d’un client RADIUS et crée une association utilisateur-IP.

Procédure rapide

1. Vérifier que le point d’accès, le contrôleur ou le proxy RADIUS peut générer un accounting start avec le nom d’utilisateur et Framed-IP-Address.
2. Définir l’expéditeur réel, l’adresse de destination du pare-feu, le port UDP 1813 et un secret partagé robuste.
3. Sous Authentication > Services > SSO using RADIUS accounting request, saisir l’adresse IP de l’expéditeur et le secret partagé.
4. Sous Administration > Device access, autoriser le service RADIUS SSO uniquement pour cet expéditeur et la bonne adresse du pare-feu.
5. Préparer une règle utilisateur strictement limitée avec Match known users et la journalisation.
6. Connecter un vrai client et contrôler le paquet d’accounting sur le pare-feu.
7. Sous Current activities > Live users, vérifier le type de client RADIUS SSO, l’utilisateur et la bonne adresse IP du client.
8. Seulement ensuite, tester le trafic autorisé et volontairement non autorisé avec le Firewall Rule ID attendu.

Quand RADIUS SSO est adapté

RADIUS SSO convient particulièrement aux réseaux Wi-Fi 802.1X ou aux systèmes d’accès réseau où l’authentification a déjà lieu en dehors du pare-feu. Celui-ci peut alors identifier l’utilisateur sans deuxième connexion dans le navigateur.

La procédure exige une relation sans ambiguïté entre l’utilisateur et une adresse IPv4. Les conditions habituelles sont les suivantes :

• Le client reçoit une adresse IPv4 que Sophos Firewall voit également comme source du trafic.
• L’expéditeur de l’accounting connaît le nom d’utilisateur et cette adresse IP client.
• L’accounting start atteint directement une adresse du pare-feu, sans modification inattendue du NAT source.
• L’expéditeur RADIUS peut fournir Framed-IP-Address dans le paquet de démarrage.
• Les objets utilisateur ou groupe et la règle de pare-feu associée sont déjà planifiés.

RADIUS SSO ne remplace pas STAS sur Sophos Firewall lorsque les événements de connexion Windows d’Active Directory constituent la source d’identité. Il ne permet pas non plus de distinguer plusieurs utilisateurs derrière la même adresse IP RDS ou Citrix. Selon le trafic, il convient d’utiliser SATC pour Remote Desktop Services ou AD SSO par connexion via le proxy Web direct.

Quand arrêter la procédure

Ne pas activer en production tant que l’un des points suivants reste ouvert :

• Le paquet d’accounting ne contient pas de nom d’utilisateur ou de Framed-IP-Address.
• L’adresse indiquée dans le paquet diffère de l’adresse IP source que le pare-feu voit ensuite dans le trafic utile.
• Plusieurs utilisateurs partagent la même adresse IP client.
• Le véritable expéditeur ou l’adresse de destination du pare-feu n’est pas clairement défini en raison du NAT, de la HA ou du routage.
• Le client RADIUS ne peut utiliser qu’un réseau entier non fiable au lieu d’une adresse source fixe.
• La stratégie de règles existante pour les utilisateurs inconnus ou qui ne sont plus connectés n’est pas définie.

Comprendre le chemin de l’accounting

Avec l’authentification RADIUS classique, le pare-feu envoie un Access-Request au serveur RADIUS. Avec RADIUS SSO, le sens est inversé :

1. Un client s’authentifie auprès du point d’accès, du contrôleur Wi-Fi ou du serveur d’accès réseau.
2. Après l’attribution de l’adresse, cette infrastructure génère un accounting start ou le transmet via un proxy RADIUS.
3. Sophos Firewall reçoit le paquet sur son service RADIUS SSO.
4. Si l’adresse IP de l’expéditeur correspond à RADIUS client IPv4 et que le secret partagé est correct, le pare-feu traite le message.
5. Le nom d’utilisateur et Framed-IP-Address apparaissent comme association sous Live users.
6. Seul le trafic utile qui suit peut correspondre à une règle avec Match known users.

L’envoi direct du contrôleur Wi-Fi au pare-feu ou la retransmission de l’accounting par un serveur RADIUS tel que NPS dépend du produit. La configuration Sophos ne contient pas de procédure universelle pour NPS ou les contrôleurs. Le paquet qui arrive réellement au pare-feu est déterminant. Une indication du fabricant telle que « RADIUS Accounting pris en charge » ne suffit pas tant que le nom d’utilisateur et l’adresse IP du client n’ont pas été vérifiés dans l’accounting start.

Exemple de bout en bout

Ce guide utilise les valeurs d’exemple suivantes :

• Expéditeur RADIUS ou d’accounting : 10.10.20.15
• Adresse du pare-feu pour RADIUS SSO : 10.10.20.1
• Client Wi-Fi : 10.30.40.50
• Port de destination de l’accounting : UDP 1813
• Utilisateur : EXAMPLE\alex.muster
• Règle utilisateur : RADIUS-SSO-WiFi-Out

Ces adresses proviennent de réseaux privés d’exemple et doivent être remplacées par les véritables réseaux de gestion, de serveurs et de clients. Pour RADIUS client IPv4, ne pas saisir automatiquement l’adresse IP du serveur d’authentification, mais l’adresse IP source réellement visible dans la capture de paquets sur le pare-feu.

Préparer le système distant

Sur le point d’accès, le contrôleur, le serveur d’accès réseau ou le proxy RADIUS, l’authentification et l’accounting doivent être vérifiés séparément. Une connexion réussie ne prouve pas que l’accounting est généré ou transmis à Sophos Firewall.

Préparer au minimum le système distant comme suit :

1. Activer l’accounting pour l’accès 802.1X ou réseau concerné.
2. Définir l’adresse prévue du pare-feu 10.10.20.1 comme destination de l’accounting.
3. Utiliser UDP 1813 ou le port d’accounting explicitement convenu entre les deux parties.
4. Configurer un secret partagé distinct et robuste pour ce chemin.
5. Envoyer l’accounting start uniquement lorsque l’adresse IP du client est connue.
6. S’assurer que le nom d’utilisateur et Framed-IP-Address sont inclus.
7. Documenter l’adresse IP source, le routage et toute traduction NAT vers l’interface du pare-feu.

Un accounting stop ou une mise à jour peut améliorer la gestion de session sur certains produits. Toutefois, l’aide publique de Sophos indique explicitement l’adresse IP de l’accounting start comme base de connexion pour Wi-Fi SSO. Une mise à jour ultérieure ne doit donc pas remplacer un paquet de démarrage complet comme critère de réussite.

Dans les installations APX administrées par SFOS, le timing DHCP peut jouer un rôle. Sophos documente le paramètre radius_accounting_start_delay avec une plage de 0 à 60 secondes. Ne pas modifier cette valeur sur simple soupçon : une capture doit d’abord montrer que l’accounting start est généré avant l’attribution de l’adresse IP. La configuration générale du Wi-Fi est décrite dans Configurer Wireless Network sur Sophos Firewall.

Pour AP6, les notes de mise à jour de 1.5.2167 MR5 indiquent le correctif WIFIX-5189 pour un cas où la framed IP manquait dans accounting start et accounting update. Pour un AP6 exécutant une version de firmware ancienne ou inconnue, mettre d’abord à jour vers un firmware actuel pris en charge, puis vérifier à nouveau le paquet. Ce correctif ne prouve pas automatiquement que chaque combinaison de contrôleur, proxy ou NPS transmet correctement les attributs.

Configurer RADIUS SSO sur Sophos Firewall

Saisir l’expéditeur et le secret partagé

Le chemin de menu est le suivant :

Authentication > Services > SSO using RADIUS accounting request

Procédure :

1. Sous RADIUS client IPv4, ajouter l’adresse IP de l’expéditeur 10.10.20.15 attendue dans la capture.
2. Saisir le Shared secret convenu pour ce chemin.
3. N’ajouter d’autres expéditeurs que sous forme d’entrées distinctes et documentées.
4. Sélectionner Apply.

Seuls les paquets provenant des adresses IPv4 configurées sont pris en compte pour RADIUS SSO. Un réseau entier ou une adresse source quelconque ne constitue pas un substitut raisonnable à une planification manquante de l’expéditeur.

Cette configuration ne crée pas de serveur RADIUS sous Authentication > Servers et ne remplace pas la configuration générale d’un serveur RADIUS sur Sophos Firewall. L’article sur le serveur traite les requêtes que le pare-feu envoie à NPS, MFA ou à un autre serveur RADIUS. RADIUS SSO traite les messages d’accounting entrants.

Autoriser Device Access de manière restrictive

RADIUS SSO est un service local du pare-feu. Une règle LAN-to-WAN ou WiFi-to-WAN normale n’ouvre pas ce chemin de réception.

Sous Administration > Device access, deux options propres sont possibles :

• Si la zone de l’expéditeur est petite et entièrement fiable, activer RADIUS SSO dans la matrice des zones.
• Si un seul système distant fixe est prévu, laisser l’accès de zone désactivé et créer une Accept Local service ACL exception rule ciblée pour l’adresse IP de l’expéditeur, l’adresse du pare-feu utilisée et le service RADIUS SSO.

Une exception accept supplémentaire ne restreint pas un accès de zone déjà actif. Pour obtenir une exception réellement étroite, RADIUS SSO doit donc rester désactivé dans la zone concernée. La procédure complète est expliquée dans Device Access et Local Service ACL.

Préparer la règle utilisateur

Une règle de production large n’est pas nécessaire pour le premier test. Une règle étroite fournit des résultats plus clairs :

1. Sous Rules and policies > Firewall rules, créer une règle au-dessus des règles WiFi ou LAN plus générales.
2. Limiter Source Zone et Source Network au véritable réseau client.
3. Sélectionner uniquement l’utilisateur pilote ou un groupe pilote préparé.
4. Activer Match known users.
5. Autoriser seulement un service de test inoffensif ou une destination clairement définie.
6. Activer Log firewall traffic.
7. Définir une deuxième combinaison d’utilisateur ou de destination volontairement non autorisée pour le test négatif.

RADIUS SSO fournit une identité, pas une autorisation réseau générale. Créer des règles de pare-feu sur Sophos Firewall explique l’interaction entre utilisateurs, groupes, services et journalisation.

Valider RADIUS SSO de manière contrôlée

1. Vérifier le paquet d’accounting sur le pare-feu

Sous Diagnostics > Packet capture, définir un filtre pour l’adresse IP de l’expéditeur 10.10.20.15, l’adresse du pare-feu 10.10.20.1 et UDP 1813. Reconnecter ensuite exactement un client pilote.

La capture doit au minimum confirmer les points suivants :

• L’adresse IP source est le RADIUS client IPv4 configuré.
• La destination est l’adresse prévue du pare-feu.
• Le port de destination est le port d’accounting configuré.
• Un accounting start apparaît pour l’utilisateur pilote.
• Framed-IP-Address correspond à l’adresse IP actuelle du client 10.30.40.50.

L’accounting RADIUS contient des données d’identité et de session qui peuvent être visibles dans le paquet. Traiter les fichiers de capture comme des journaux d’authentification, ne les conserver que brièvement et ne pas les transmettre sans protection. Le fonctionnement général est décrit dans Packet Capture sur Sophos Firewall.

2. Vérifier Live User

Sous Current activities > Live users, l’utilisateur, l’adresse IP client et le type de client doivent correspondre. Pour cette procédure, le type de client attendu est RADIUS SSO.

Un utilisateur visible avec une mauvaise adresse IP ne constitue pas un succès partiel. Les règles utilisateur correspondent ensuite à la source réelle du trafic et non à l’association Wi-Fi souhaitée.

3. Corréler le journal d’authentification

Dans Log Viewer, rechercher l’utilisateur pilote et l’heure de l’incident. Pour une analyse approfondie, access_server.log est pertinent, car Sophos y traite l’authentification, l’autorisation et l’accounting des utilisateurs.

En HA, chaque nœud ne stocke que les journaux du trafic qu’il a lui-même traité. Vérifier le nœud qui a reçu l’accounting au moment du test. Vérifier les services et journaux de Sophos Firewall via la CLI explique comment lire et sauvegarder access_server.log sans redémarrage incontrôlé du service.

4. Effectuer les tests positif et négatif

Quatre éléments sont testés séparément avec le client pilote :

1. Une destination autorisée correspond au Firewall Rule ID attendu et affiche le bon utilisateur.
2. Une destination volontairement non autorisée reste bloquée.
3. Un utilisateur non affecté n’obtient pas l’accès pilote.
4. Après une nouvelle connexion ou une itinérance contrôlée, l’association entre l’utilisateur, l’adresse IP et la règle reste correcte.

Le test doit utiliser du trafic utile réel. Une entrée Live User ne prouve à elle seule ni la correspondance de règle, ni le routage, ni le chemin retour. Tester les règles de pare-feu de manière fiable décrit la procédure reproductible.

Isoler les erreurs par symptôme

Aucun paquet d’accounting n’atteint le pare-feu

Vérifier d’abord l’adresse IP de destination, le port UDP, le routage et la configuration du système distant. Contrôler ensuite Device Access ou la Local Service ACL Exception Rule. Une connexion RADIUS réussie sur NPS ou sur le réseau Wi-Fi ne prouve pas l’existence du chemin d’accounting séparé vers le pare-feu.

Si le paquet arrive avec une autre adresse IP source, rechercher précisément cette cause. Ne pas autoriser trop rapidement un réseau entier comme client RADIUS. Avec le NAT ou la HA, documenter et autoriser de manière ciblée l’adresse stable de l’expéditeur réellement visible.

L’accounting arrive, mais Live Users reste vide

Vérifier ensemble le secret partagé, l’adresse IP de l’expéditeur et le contenu du paquet. L’accounting start, le nom d’utilisateur et Framed-IP-Address sont particulièrement importants. Si l’adresse IP client manque, corriger d’abord le point d’accès, le contrôleur ou le proxy RADIUS. Le redémarrage d’un service du pare-feu ne peut pas créer un attribut manquant.

Ce n’est que lorsque le paquet est complet et que access_server.log ne traite toujours pas l’événement qu’il faut sauvegarder l’heure, la capture, le CTR et les journaux du nœud pour Sophos Support. Ne pas supprimer la base de données d’authentification ni nettoyer Live Users sur simple soupçon.

L’utilisateur apparaît avec une mauvaise adresse IP

Cela indique souvent un message d’accounting envoyé trop tôt, une ancienne association DHCP, une itinérance ou un autre chemin NAT. Déconnecter le client, relever le bail actuel et capturer une seule nouvelle connexion. L’adresse IP figurant dans le nouvel accounting start est déterminante.

Avec le Wi-Fi administré par SFOS, ne modifier radius_accounting_start_delay qu’après cette preuve et en documentant la valeur précédente. Les points d’accès ou contrôleurs tiers utilisent leurs propres mécanismes d’accounting et DHCP ; un paramètre Wi-Fi Sophos ne modifie pas ces équipements.

Live User est correct, mais la règle ne correspond pas

Le chemin d’accounting est alors plus avancé que la stratégie. Vérifier Source Zone, Source Network, l’utilisateur ou le groupe, Match known users, l’ordre des règles, Firewall Rule ID et l’adresse IP réelle du trafic. Si la règle #0 ou une règle générale correspond, corriger la stratégie plutôt que de modifier le secret partagé.

L’utilisateur reste visible après sa déconnexion

Vérifier d’abord si le système distant envoie un accounting stop et si ce paquet concerne la même session et la même association utilisateur. Corréler ensuite Live User, le trafic client actuel et access_server.log. Une déconnexion manuelle peut corriger temporairement l’état, mais ne prouve pas que le processus automatique fonctionne correctement.

Sécurité, HA et exploitation

L’accounting RADIUS utilise UDP et ne protège pas le transport comme TLS. Le secret partagé authentifie le chemin RADIUS, mais ne chiffre pas tous les attributs d’identité et de session. L’accounting doit donc se trouver dans un réseau de gestion ou de serveurs fiable et ne doit pas traverser des réseaux tiers sans protection.

Les limites suivantes s’appliquent en exploitation :

• Utiliser un secret partagé distinct et robuste ainsi qu’un responsable documenté pour chaque expéditeur.
• Autoriser RADIUS SSO uniquement depuis les zones nécessaires et, si possible, seulement depuis des hôtes fixes.
• Traiter les fichiers de capture, les journaux RADIUS et access_server.log comme des données d’exploitation à caractère personnel.
• Terminer chaque modification du DHCP, du contrôleur Wi-Fi, de NPS, du proxy RADIUS ou du NAT par un nouveau test de bout en bout.
• En HA, ne pas promettre le maintien sans interruption de l’association utilisateur. Après un basculement planifié, vérifier un nouvel accounting start, Live User et le trafic réel sur le nœud de traitement.
• Gérer les utilisateurs inconnus ou les associations manquantes avec une règle par défaut sûre, et non avec une règle allow large.

Rollback

Le retour arrière s’effectue dans un ordre qui ne laisse pas le service d’accounting ouvert et n’accorde pas involontairement l’accès aux utilisateurs :

1. Restaurer la stratégie d’authentification et de règles précédente pour le réseau pilote.
2. Désactiver la règle pilote et effectuer un test négatif avec un utilisateur inconnu.
3. Supprimer la destination d’accounting sur le point d’accès, le contrôleur ou le proxy RADIUS, ou rétablir son état précédent documenté.
4. Supprimer l’expéditeur sous SSO using RADIUS accounting request.
5. Retirer l’exception ACL RADIUS SSO ou l’accès de zone temporaire.
6. Vérifier à nouveau Live Users, Firewall Rule ID et le trafic client normal.

Documenter dans le changement la configuration d’origine, la responsabilité du secret partagé et le retour testé à l’ancienne méthode d’identification des utilisateurs. La simple suppression d’une entrée Live User ne constitue pas un rollback complet.

FAQ