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.

La procédure Sophos actuelle confirme ce fonctionnement pour les points d’accès APX administrés par SFOS. Elle ne fournit pas d’approbation générale pour AP6 ni pour n’importe quel contrôleur tiers. Pour une autre plateforme, vérifier auprès du fabricant et, si nécessaire, de Sophos Support qu’elle prend en charge le même chemin de proxy et d’attributs avant le déploiement en production. Un paquet de test techniquement adapté n’étend pas à lui seul le périmètre de support documenté.

Procédure rapide

1. Pour le fonctionnement officiellement documenté, utiliser APX avec 802.1X et configurer le serveur d’accounting RADIUS comme proxy vers le pare-feu.
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 sur l’APX administré par SFOS auprès du serveur RADIUS sélectionné sous Wireless > Wireless settings.
2. L’APX envoie l’accounting à ce serveur via le pare-feu. Le serveur est également configuré comme proxy d’accounting et retransmet le message au pare-feu.
3. Sophos Firewall reçoit le paquet retransmis 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.

Dans le fonctionnement APX officiel, le serveur RADIUS n’est pas seulement la destination de l’authentification et de l’accounting : il sert aussi de proxy et retransmet les paquets d’accounting APX au pare-feu. NPS nécessite donc une configuration de proxy RADIUS adaptée. L’adresse IP source de ce paquet retransmis est la valeur déterminante pour RADIUS client IPv4. Une indication générale du fabricant telle que « RADIUS Accounting pris en charge » ne prouve ni la prise en charge de cette architecture, ni la présence du nom d’utilisateur et de l’adresse IP client 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

Dans l’architecture APX officiellement documentée, vérifier séparément l’authentification, l’accounting vers le serveur RADIUS et le chemin de retour du proxy vers le pare-feu. Une connexion 802.1X réussie ne prouve pas que le serveur RADIUS retransmet l’accounting à Sophos Firewall.

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

1. Configurer l’APX et le réseau Wi-Fi 802.1X sous Wireless, puis sélectionner le serveur RADIUS sous Wireless > Wireless settings.
2. Activer l’accounting sur le serveur RADIUS et le configurer comme proxy d’accounting vers l’adresse du pare-feu 10.10.20.1.
3. Utiliser UDP 1813 pour la retransmission au pare-feu.
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 radius_accounting_start_delay avec une plage de 0 à 60 secondes. L’exemple officiel pour la Device Console définit 30 secondes :

system wireless-controller global radius_accounting_start_delay 30

30 est un exemple adaptable et non une valeur par défaut universelle. Avant toute modification, exécuter system wireless-controller global show et consigner la valeur actuelle. Ne modifier le paramètre que si une capture montre que l’accounting start est généré avant l’attribution de l’adresse. Pour le rollback, exécuter la commande de réglage avec la valeur consignée. Si cette valeur était 0 (aucun délai), la commande exacte est system wireless-controller global radius_accounting_start_delay 0. Les sources officielles n’indiquent aucune valeur par défaut universelle : ne pas en déduire une si la valeur précédente est inconnue. Sophos indique également use_tunneled_reply pour FreeRADIUS ; cette option appartient au serveur FreeRADIUS et ne doit pas être transposée à NPS sans preuve. La configuration générale du Wi-Fi est décrite dans Configurer Wireless Network sur Sophos Firewall.

Les notes de mise à jour AP6 citent WIFIX-5189, un défaut corrigé concernant la framed IP dans les paquets d’accounting. La procédure RADIUS SSO limite toutefois le fonctionnement décrit à APX. Ce correctif AP6 ne prouve donc pas la prise en charge de cette configuration.

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.

Dans cette section, SFOS 22 ne propose que RADIUS client IPv4 et Shared secret ; aucun port séparé n’y est configuré. 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 du récepteur ne crée pas à elle seule de serveur RADIUS sous Authentication > Servers. Le fonctionnement APX officiel exige néanmoins d’y ajouter le serveur RADIUS externe et de le sélectionner sous Wireless > Wireless settings ; la configuration générale d’un serveur RADIUS sur Sophos Firewall explique cette partie. L’authentification et l’accounting sortants d’une part, et les messages RADIUS SSO retransmis d’autre part, restent deux chemins distincts.

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 UDP 1813.
• 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.

Après un redémarrage du pare-feu, Sophos indique que les clients APX doivent se déconnecter puis se reconnecter afin qu’un nouvel accounting start rétablisse la connexion. Si Show captive portal to unknown users est activé dans la règle utilisateur, le portail peut apparaître initialement ; dans le fonctionnement APX documenté, la connexion transparente suit après le délai d’accounting configuré sans nouvelle saisie des identifiants.

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 du serveur RADIUS la destination de retransmission du proxy vers le pare-feu, ou rétablir l’état précédent documenté du proxy. Ne pas supprimer la destination d’accounting de l’APX si le serveur RADIUS reste nécessaire à l’authentification et à l’accounting Wi-Fi.
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