Configurer TACACS+ pour les administrateurs Sophos Firewall

TACACS+ permet de vérifier la connexion d’administrateurs nominatifs de Sophos Firewall auprès d’un serveur central. Cela simplifie les politiques de mot de passe et le départ des utilisateurs, mais ne transforme pas automatiquement le pare-feu en équipement réseau entièrement piloté par TACACS+ : l’affectation du Device access profile reste locale dans SFOS.

La procédure sûre sépare donc trois niveaux : l’accessibilité et le Shared Secret du serveur TACACS+, l’authentification externe réussie de l’utilisateur et le rôle d’administrateur local sur le pare-feu. Un résultat positif de Test connection ne prouve que le premier niveau.

Important : Avant la modification, le compte de super-administrateur local admin, une seconde voie de gestion fonctionnelle et une session d’administration locale ouverte doivent être disponibles. TACACS+ ne devient pas l’unique méthode avant que la connexion pilote, le test négatif et la voie de secours fonctionnent.

TACACS+ en dix étapes

1. Tester positivement le compte admin local, le processus MFA ou de récupération et l’accès de gestion.
2. Documenter le serveur TACACS+, l’adresse source du pare-feu, le port TCP, le Shared Secret et le compte pilote.
3. Autoriser le chemin TACACS+ uniquement via un réseau de gestion de confiance ou un tunnel protégé.
4. Ajouter un TACACS+ server sous Authentication > Servers > Add.
5. Utiliser Test connection pour vérifier les identifiants et l’accessibilité, puis enregistrer.
6. Authentifier une fois l’utilisateur pilote via un service du pare-feu déjà autorisé afin de créer son objet utilisateur.
7. Sous Authentication > Users, transformer de manière contrôlée l’utilisateur pilote en administrateur et lui attribuer un Device Access Profile minimal.
8. Sous Authentication > Services > Administrator authentication methods, ajouter TACACS+, définir l’ordre et conserver Local comme solution de repli volontaire.
9. Tester WebAdmin positivement dans une fenêtre de navigation privée et négativement avec un utilisateur non autorisé.
10. Ensuite seulement, ajouter d’autres administrateurs, vérifier les logs et tester de manière contrôlée une panne du chemin TACACS+.

Ce que SFOS contrôle avec TACACS+

Sophos Firewall utilise le serveur TACACS+ configuré comme méthode d’authentification pour les services sélectionnés. Sous Authentication > Services, SFOS indique PAP et CHAP pour TACACS+. La méthode réellement adaptée doit être convenue avec le serveur distant et confirmée dans son log.

L’aide actuelle de SFOS 22 ne documente aucune association automatique d’un attribut TACACS+ à un profil d’administrateur Sophos. Un utilisateur provenant d’un serveur externe apparaît comme utilisateur standard lors de sa première connexion et ne reçoit des droits d’administrateur qu’après une affectation locale. Microsoft Entra ID SSO constitue une exception explicitement documentée avec un mapping de rôles ou de groupes.

La capacité générale du protocole TACACS+ à fournir Authorization et Accounting n’équivaut pas non plus à une autorisation de commandes documentée dans SFOS. Pour ce runbook :

• TACACS+ vérifie l’identité externe et le mot de passe.
• SFOS définit localement le type d’utilisateur et le Device Access Profile.
• configuration-audit.log reste la preuve des modifications de configuration sur le pare-feu.
• Une autorisation TACACS+ seule ne donne pas accès à WebAdmin.

Pour planifier les rôles locaux, consulter Configurer en toute sécurité les administrateurs et profils Sophos Firewall.

Exemple et prérequis

L’exemple utilise :

• Server name: TACACS-HQ
• Server IP: 10.20.30.15
• Port: 49
• Utilisateur pilote : fw-noc-pilot
• Device Access Profile : NOC-ReadOnly
• Réseau de gestion : 10.20.40.0/24

10.20.30.15 et 10.20.40.0/24 sont des valeurs privées de documentation à remplacer par l’adresse réelle du serveur et le réseau de gestion autorisé. TCP 49 est le port standard enregistré pour TACACS+, mais le port saisi dans SFOS doit correspondre exactement au serveur distant. Le Shared Secret ne doit pas apparaître dans les captures, les tickets ni cet exemple.

Avant la configuration, les points suivants doivent être clarifiés :

• Le serveur TACACS+ connaît l’adresse source réelle du pare-feu comme client ou Network Access Server.
• Le routage et le chemin réseau entre le pare-feu et le serveur fonctionnent dans les deux sens.
• Le compte pilote est actif sur le serveur TACACS+ et autorisé pour le type d’authentification prévu.
• Un Device Access Profile dédié avec None, Read-only et uniquement les droits Read-write nécessaires est préparé.
• WebAdmin n’est accessible que depuis le réseau de gestion prévu.
• Le compte local admin fonctionne indépendamment de TACACS+.
• La sauvegarde, la fenêtre de maintenance et la voie de secours sont documentées.

Le formulaire SFOS actuel documente une adresse IP, un port et un Shared Secret pour TACACS+, mais aucun commutateur TLS. Le TACACS+ classique ne protège pas le contenu des paquets comme une connexion TLS moderne. Le chemin vers le serveur ne doit donc pas traverser Internet ou un réseau tiers sans protection. Si seul un transport non sécurisé est disponible, le déploiement en production est arrêté.

Ajouter le serveur TACACS+ au pare-feu

Chemin de menu :

Authentication > Servers > Add

Procédure :

1. Définir Server type sur TACACS+ server.
2. Saisir un Server name explicite, par exemple TACACS-HQ.
3. Saisir la véritable Server IP et le Port configuré sur le serveur.
4. Enregistrer le même Shared secret que sur le serveur TACACS+ distant.
5. Utiliser le compte pilote autorisé pour Test connection.
6. Enregistrer uniquement après un test réussi.

Le test de connexion vérifie les identifiants de l’utilisateur et la connexion au serveur. Il ne prouve pas que l’utilisateur possède déjà un profil d’administrateur, que WebAdmin est accessible depuis son réseau ni qu’une véritable connexion d’administrateur fonctionne.

En cas d’échec, vérifier d’abord l’adresse IP du serveur, la route, le port, le Shared Secret, la définition du client et le log du serveur. Les méthodes d’authentification et les rôles d’administrateur ne sont pas modifiés sans preuve.

Transformer en toute sécurité un utilisateur externe en administrateur

Les utilisateurs de serveurs externes deviennent visibles sous Authentication > Users après leur première connexion réussie à un service du pare-feu. Pour le pilote, utiliser un service déjà autorisé, par exemple User Portal ou VPN Portal. Si aucun chemin de ce type n’existe, ne pas créer une large exposition WAN uniquement pour générer l’objet utilisateur.

La procédure reste limitée :

1. Autoriser le portail ou le service d’authentification choisi uniquement depuis le réseau de gestion.
2. Ajouter TACACS+ précisément à cette méthode d’authentification sans supprimer les solutions de repli existantes.
3. Connecter une fois l’utilisateur pilote avec succès.
4. Sous Authentication > Users, vérifier que l’objet utilisateur externe est apparu.
5. Ouvrir l’utilisateur et définir User type sur Administrator.
6. Affecter le profil préparé, par exemple NOC-ReadOnly.
7. Rétablir l’état antérieur documenté des autorisations temporaires de portail ou de méthode devenues inutiles.

Un utilisateur externe ne reçoit pas par précaution le profil complet Administrator. Tester d’abord un rôle en lecture seule ou strictement limité. Seuls les comptes dont la mission nécessite réellement des droits d’écriture les reçoivent.

Modifier Administrator authentication methods

Chemin de menu :

Authentication > Services > Administrator authentication methods

Ajouter TACACS+ à la liste des serveurs sélectionnés. Si plusieurs serveurs sont choisis, SFOS transmet la demande dans l’ordre affiché. Cet ordre fait donc partie du modèle de sécurité et n’est pas une valeur cosmétique.

Pour le pilote :

1. Ajouter TACACS+ à la liste sélectionnée.
2. Déplacer le serveur à la position prévue.
3. Conserver Local comme solution de repli volontaire pour les administrateurs locaux nominatifs.
4. Sélectionner Apply.
5. Garder ouverte la session admin existante.

Les Administrator authentication methods ne s’appliquent explicitement pas au super-administrateur local admin. Ce compte reste la voie de secours indépendante et est protégé séparément par un mot de passe robuste, la MFA et un accès réseau restreint.

Set authentication methods same as firewall associe la connexion des administrateurs aux méthodes utilisées pour l’authentification du pare-feu. Cette option n’est utilisée que si cette association est volontaire et documentée. Pour un pilote d’administrateurs clair, une liste explicite est plus facile à vérifier et à restaurer.

Valider WebAdmin et le rôle

Une validation réussie contrôle plus que la boîte de dialogue du mot de passe :

1. Garder ouverte la session locale admin.
2. Connecter le pilote via le FQDN WebAdmin prévu dans une fenêtre de navigation privée.
3. Vérifier le profil affecté : les menus attendus sont visibles et les zones non autorisées sont absentes.
4. Avec Read-only, une modification contrôlée ne doit pas pouvoir être enregistrée.
5. Pour un rôle d’écriture prévu, utiliser une modification de test sans risque avec un rollback documenté.
6. Un utilisateur TACACS+ valide sans rôle d’administrateur local ne doit pas pouvoir ouvrir WebAdmin.
7. Un mot de passe incorrect doit être refusé.
8. Le compte admin local doit toujours pouvoir se connecter dans une seconde fenêtre privée.
9. Corréler temporellement le log du serveur TACACS+, Log Viewer et configuration-audit.log.

L’accessibilité de WebAdmin est contrôlée séparément sous Administration > Device access ou au moyen d’une exception Local Service ACL précise. TACACS+ et la MFA ne justifient pas une large exposition WAN. Le chemin réseau sécurisé est décrit dans Device Access et Local Service ACL.

Vérifier les logs et la HA

Dans Log viewer, filtrer sur l’utilisateur pilote, l’adresse IP source et l’heure du test. Pour une analyse approfondie, utiliser :

• access_server.log pour l’authentification, l’autorisation et l’Accounting dans SFOS
• configuration-audit.log pour les modifications, l’administrateur et l’heure
• syslog.log pour les événements système et déclenchés par un administrateur
• le log du serveur TACACS+ pour l’adresse du client, l’utilisateur, la méthode et le résultat

Dans un cluster HA, ne pas supposer qu’une session WebAdmin existante survit sans interruption à un failover. Après un changement de rôle planifié, effectuer une nouvelle connexion et vérifier quelle adresse source du pare-feu apparaît réellement sur le serveur TACACS+. Si le serveur autorise les clients selon leur adresse source, toutes les adresses réellement présentes dans le chemin HA doivent être explicitement autorisées.

Les logs se trouvent sur le nœud qui a traité l’événement. Dans un cas HA dont l’heure est incertaine, vérifier les deux nœuds ou une vue consolidée.

Analyser les erreurs selon le symptôme

Test connection échoue

Vérifier l’adresse IP du serveur, la route, le port TCP, le Shared Secret, la définition du client et l’état du serveur. Une capture de paquets peut montrer si le pare-feu atteint le serveur et quelle adresse IP source il utilise. En l’absence de réponse ou avec une adresse source inattendue, ne pas poursuivre avec les rôles utilisateur.

Test connection réussit, mais WebAdmin refuse l’utilisateur

Ce comportement est compatible avec l’absence d’un profil d’administrateur local. Sous Authentication > Users, vérifier que l’utilisateur existe, que User type: Administrator est défini et que le bon Device Access Profile lui est affecté. Contrôler ensuite l’ordre sous Administrator authentication methods et l’ACL de WebAdmin.

Le serveur accepte le mot de passe, mais le mauvais profil s’applique

Dans ce flux SFOS, TACACS+ n’affecte pas automatiquement le profil Sophos local. Vérifier l’objet utilisateur et le profil sur le pare-feu. Ne pas inventer d’attributs serveur ni attribuer le profil Administrator complet comme test rapide.

La connexion fonctionne uniquement jusqu’à un failover HA

Vérifier sur le serveur TACACS+ l’adresse IP source réelle de la nouvelle connexion. Contrôler ensuite la route, le port, la définition du client et le Shared Secret pour le chemin actif. Une ancienne session de navigateur ne prouve pas le succès ; utiliser une nouvelle session.

Toutes les connexions d’administrateurs externes échouent

Se connecter avec le compte admin local, vérifier l’état du serveur et l’ordre des méthodes, puis retirer TACACS+ de la liste des administrateurs de façon contrôlée si nécessaire. Ne pas élargir Device Access à Any et ne pas redémarrer le service d’authentification en première mesure.

Pour un diagnostic commun aux méthodes, consulter Diagnostiquer systématiquement l’authentification Sophos Firewall.

Départ d’un utilisateur et rollback

Lors du départ d’un utilisateur, commencer par le bloquer sur le serveur TACACS+. Vérifier ensuite sur le pare-feu si une session existante est encore active et si l’objet utilisateur externe local possède toujours un profil d’administrateur. Un blocage côté serveur ne garantit pas l’arrêt immédiat de toutes les sessions WebAdmin existantes.

Après le test négatif, supprimer le profil d’administrateur local ou désactiver l’utilisateur. Documenter les logs d’audit et du serveur avec le ticket et l’heure. Le compte de super-administrateur admin ne fait pas partie de ce processus normal de départ.

Rollback après un pilote échoué :

1. Utiliser la session d’administration locale restée ouverte.
2. Retirer TACACS+ des Administrator authentication methods ou rétablir sa position antérieure documentée.
3. Restaurer l’état précédent des autorisations temporaires de portail et de Device Access.
4. Retirer le rôle d’administrateur local de l’utilisateur pilote ou désactiver cet utilisateur.
5. Tester une nouvelle connexion d’administrateur local et le chemin d’authentification normal.
6. Ensuite seulement, supprimer l’entrée du serveur TACACS+ si aucune autre fonction ne l’utilise.

Liste de contrôle

• compte admin local, MFA et voie de récupération testés
• adresse source réelle du pare-feu connue sur le serveur TACACS+
• port TCP et Shared Secret identiques
• chemin serveur situé dans un réseau de confiance ou protégé
• Test connection réussi sans le confondre avec une preuve WebAdmin
• utilisateur pilote visible comme objet utilisateur externe
• User type: Administrator et profil minimal affectés localement
• Local conservé comme solution de repli volontaire
• tests WebAdmin positif et négatif réussis
• WebAdmin accessible uniquement depuis le réseau de gestion prévu
• access_server.log, log serveur et Audit Trail corrélés
• HA ou failover testé avec une nouvelle connexion
• départ et rollback documentés

Questions fréquentes