Configurer Client Authentication Agent sur Sophos Firewall

Le Client Authentication Agent, ou CAA, convient aux postes Windows, macOS ou Linux individuels sur lesquels l’utilisateur se connecte volontairement au pare-feu. Après une connexion réussie, l’identité apparaît comme Authentication agent sous Current activities > Live users. Les règles de pare-feu et web basées sur des utilisateurs ou des groupes peuvent alors associer le trafic à cette identité.

L’agent ne remplace pas toutes les architectures SSO. Un serveur de terminaux avec plusieurs utilisateurs simultanés nécessite SATC, tandis que STAS peut assurer la connexion sans agent Endpoint dans un domaine Windows. CAA convient surtout à un nombre maîtrisé de postes individuels lorsque la connexion manuelle de l’utilisateur est acceptable.

Important : L’agent doit atteindre le chemin d’authentification documenté par Sophos. Les clients Windows et macOS communiquent via 1.2.3.4 et TCP 9922 ; un VPN, une autre route par défaut ou un routeur en amont peut détourner ce chemin du pare-feu. Avant un déploiement étendu, tester la route, la CA TLS, la connexion pilote et la règle réellement appliquée sur un poste.

CAA en dix étapes

1. Vérifier que le poste représente bien un seul utilisateur actif ; utiliser SATC pour RDS, Citrix ou les autres hôtes multi-utilisateurs.
2. Documenter le serveur d’authentification, le groupe d’utilisateurs, la politique de pare-feu et une méthode locale de récupération.
3. Depuis le poste pilote, vérifier le chemin vers 1.2.3.4 via Sophos Firewall et TCP 9922.
4. Télécharger l’agent approprié et sa Server CA sous Authentication > Client downloads.
5. Pour un déploiement Windows en masse, prévoir ensemble Download MSI et Download CA for MSI ; les programmes d’installation individuels incluent l’agent et la CA.
6. Installer l’agent sur un poste pilote sans encore le distribuer largement.
7. Sous Authentication > Services > Firewall authentication methods, vérifier le serveur d’authentification prévu et son ordre.
8. Se connecter avec un utilisateur pilote et confirmer le type de client Authentication agent sous Current activities > Live users.
9. Exécuter un flux autorisé et un flux bloqué, puis vérifier l’utilisateur, la politique et la Firewall Rule ID dans Log Viewer.
10. Documenter seulement ensuite le déploiement, le comportement MFA, le test HA, le processus de support et le rollback.

Quand utiliser Client Authentication Agent

CAA transmet la connexion de l’utilisateur depuis le poste vers le pare-feu. Il convient particulièrement aux cas suivants :

• postes individuels gérés mais non joints à un domaine ;
• petits environnements sans infrastructure STAS ;
• postes où un changement d’utilisateur doit volontairement déclencher une nouvelle connexion de l’agent ;
• politiques qui nécessitent un vrai nom d’utilisateur plutôt qu’une simple IP source.

L’agent n’est pas une solution générale pour plusieurs utilisateurs simultanés derrière la même IP d’hôte. SATC sur les systèmes Remote Desktop décrit l’approche par session pour Citrix, RDS et les serveurs de terminaux. Dans un environnement AD, STAS sur Sophos Firewall constitue l’alternative sans client.

CAA authentifie l’utilisateur, mais ne crée pas d’autorisation réseau. Les règles de pare-feu, Web Policies, groupes, quotas et Access-Time-Policies restent des niveaux distincts. Un Live User visible ne prouve donc pas que le trafic attendu correspond à la bonne règle.

Exemple et prérequis

Le pilote utilise :

• IP LAN du pare-feu : 10.20.30.1
• Poste pilote : 10.20.30.50
• Utilisateur pilote : fw-user-pilot
• Groupe d’utilisateurs : CAA-Pilot
• Destination de l’agent : 1.2.3.4
• Port TCP : 9922

10.20.30.1 et 10.20.30.50 sont des valeurs privées de documentation à remplacer par les adresses réelles. En revanche, 1.2.3.4 et TCP 9922 constituent le chemin de l’agent documenté par Sophos pour Windows et macOS et ne se remplacent pas comme des valeurs d’environnement ordinaires. Pour Linux, les instructions actuelles du User Portal utilisent un fichier de configuration distinct et exigent l’adresse IP réelle du pare-feu.

Avant l’installation, clarifier les points suivants :

• Le poste pilote utilise Sophos Firewall comme passerelle ou dispose d’un chemin vérifié vers la destination de l’agent.
• Aucun VPN full-tunnel ni aucune route étrangère ne détourne 1.2.3.4 de la passerelle SFOS prévue.
• L’utilisateur existe localement ou sur un serveur sélectionné sous Firewall authentication methods.
• Le groupe et les politiques sont prêts ; le pilote ne reçoit pas préventivement des droits plus larges.
• L’Authentication Server CA correspondant au programme d’installation provient uniquement du pare-feu concerné.
• Une autre méthode d’authentification fonctionnelle reste disponible pendant le pilote.
• Si MFA est activée, le token est enregistré et le comportement de l’agent testé séparément.

L’aide SFOS 22 actuelle indique comme systèmes pris en charge Windows 10 et versions ultérieures, Ubuntu 16.4 et versions ultérieures ainsi que macOS Catalina 10.15 et versions ultérieures. Il s’agit d’une limite de la documentation actuelle du produit, pas d’une garantie pour chaque future version du système d’exploitation. Tester en pilote la combinaison exacte du build SFOS, du package agent et de la version Endpoint avant le déploiement.

Préparer l’authentification sur le pare-feu

Sous Authentication > Services > Firewall authentication methods, sélectionner au moins un serveur approprié ou la base de données locale. Avec plusieurs serveurs, SFOS transmet la requête dans l’ordre affiché. Le Default Group, le groupe importé et l’état de l’utilisateur doivent donc être définis avant le test de l’agent.

Pour les comptes pilotes locaux, voir créer et tester des utilisateurs locaux en toute sécurité. Pour AD, LDAP ou RADIUS, tester d’abord le serveur concerné avec son dialogue de service normal. Un Test connection réussi ne prouve toutefois pas le futur chemin CAA depuis le poste.

Si MFA est activée pour le User portal, Sophos indique que cette exigence s’applique aussi aux Client Authentication Agents. Tester l’enregistrement et la saisie du token avec le même utilisateur pilote. Ne pas activer MFA de façon inattendue après le déploiement.

Télécharger l’agent et la Server CA

Les administrateurs téléchargent les packages ici :

Authentication > Client downloads

Sophos propose les variantes suivantes :

• Download MSI : agent Windows pour un déploiement automatisé ;
• Download CA for MSI : Authentication Server CA séparée pour le déploiement MSI ;
• Download for Windows : programme d’installation individuel avec l’agent et la CA ;
• Download for macOS : programme d’installation individuel avec l’agent et la CA ;
• Download for Linux 32 ou Download for Linux 64 : archive contenant l’agent, la configuration et la CA.

Les utilisateurs autorisés peuvent aussi télécharger eux-mêmes les packages sous Download client > Authentication clients dans le User Portal. N’autoriser le User Portal que depuis les réseaux prévus. Une large ouverture WAN uniquement pour le téléchargement n’est pas nécessaire.

Après un factory reset, le pare-feu régénère la CA. Les utilisateurs doivent alors réinstaller l’Authentication Server CA. Ne pas réparer un ancien agent avec une ancienne CA en désactivant la validation des certificats ou en introduisant une CA étrangère ; télécharger à nouveau le package actuel depuis le bon pare-feu.

Installer l’agent sur le poste pilote

Windows et macOS

Sous Windows, exécuter client_auth_agent.exe depuis le User Portal. Un déploiement MSI géré doit distribuer ensemble l’agent et Download CA for MSI. L’agent seul, sans la CA correspondante, ne met pas en œuvre le chemin TLS documenté.

Sous macOS, ouvrir Client+Authentication+Agent.dmg et déplacer l’agent dans le dossier d’applications prévu. Là aussi, la CA intégrée doit provenir du pare-feu sur lequel l’utilisateur se connectera ensuite.

Installer d’abord le pilote de manière interactive. N’automatiser la distribution du package, le démarrage automatique et les mises à niveau qu’après un test end-to-end réussi. Ne pas réutiliser un ancien agent issu de la sauvegarde d’un autre pare-feu ou d’une autre appliance.

Linux

Pour Linux, Sophos indique le chemin d’extraction suivant, en remplaçant <FILENAME> par l’archive téléchargée :

sudo tar -xzvf <FILENAME> -p -C $HOME
sudo mv ~/bin/caa /usr/local/bin

Contrôler ensuite la configuration fournie sous $HOME/.caa/caa.conf. L’aide actuelle du User Portal demande sous Linux de remplacer la valeur suivant Copernicus host par l’adresse IP réelle du pare-feu et de saisir le nom d’utilisateur et le mot de passe. Ne jamais inscrire un vrai mot de passe dans un script de déploiement, un ticket ou un exemple public. Sophos indique que l’agent chiffre au premier démarrage le mot de passe initialement stocké en clair.

Vérifier les droits du fichier, son propriétaire et le contenu de $HOME/.caa/README avant le démarrage. Exécuter ensuite caa en pilote. Les instructions Linux utilisant une valeur de destination différente du chemin général Windows et macOS, ne pas mélanger les procédures des plateformes.

Connecter le pilote et tester les politiques

Le pilote se connecte à l’agent avec le nom d’utilisateur et le mot de passe prévus pour le pare-feu. Avec une authentification externe, ce format exact doit correspondre à la configuration du serveur. Un affichage positif de l’agent ne représente que le premier test.

Vérifier ensuite sur le pare-feu :

1. fw-user-pilot apparaît sous Current activities > Live users.
2. Le type de client est Authentication agent.
3. L’IP source et le groupe correspondent au poste pilote et au mapping prévu.
4. Un flux autorisé atteint la règle attendue basée sur l’utilisateur ou le groupe.
5. Une destination volontairement non autorisée reste bloquée.
6. Le log du pare-feu affiche l’utilisateur, la règle, l’action et la Firewall Rule ID.
7. Après Disconnect sous Live users, l’agent reçoit la notification documentée et le trafic est réévalué.

Ne pas créer une large politique Any pour la règle de test. Ajouter uniquement l’utilisateur ou le groupe pilote aux règles existantes de manière contrôlée. Tester systématiquement les règles Sophos Firewall décrit la validation générale de bout en bout.

Vérifier les logs et HA

Dans Log viewer, filtrer Authentication par utilisateur, IP source et heure du test. Le champ du client doit afficher Authentication Agent. Vérifier aussi le trafic réel du pare-feu et sa Firewall Rule ID.

Pour une corrélation plus approfondie, utiliser access_server.log pour l’authentification et l’autorisation, ainsi que Log Viewer ou la destination Syslog configurée. Un seul état du client sans entrée de log correspondante sur le pare-feu ne constitue pas une validation complète.

En HA, ne pas supposer qu’une connexion existante de l’agent se poursuit sans interruption. Après un failover contrôlé, retester une nouvelle connexion, Live User, la règle appliquée et le trafic réel. Les logs se trouvent sur le node ayant traité l’événement ; si l’heure est incertaine, contrôler les deux nodes ou une vue consolidée.

Délimiter les erreurs par symptôme

L’agent n’atteint pas le pare-feu

Contrôler d’abord le chemin de routage vers la destination documentée de l’agent et TCP 9922. Une capture contrôlée avec host 1.2.3.4 and port 9922 peut montrer si le trafic Windows ou macOS atteint Sophos Firewall. Sous Linux, vérifier plutôt l’IP du pare-feu configurée dans caa.conf.

Si le problème n’apparaît qu’après la connexion d’un autre client VPN, vérifier si sa route full-tunnel prend le contrôle de la destination de l’agent. La solution n’est pas une commande de host route appliquée aveuglément : évaluer d’abord le split tunnel, le routage et l’impact de sécurité dans la topologie réelle. Arrêter le déploiement si le chemin d’authentification reste incertain.

Une erreur TLS ou CA apparaît

Le programme d’installation et la CA doivent provenir du même pare-feu actif. Après un factory reset, l’ancienne CA n’est plus valide et doit être remplacée par le package actuel. Ne pas désactiver la validation des certificats, la protection Endpoint ou TLS comme solution rapide.

Le mot de passe fonctionne sur le portail, mais pas dans l’agent

Sous Firewall authentication methods, vérifier l’ordre des serveurs, le Default Group et l’état de l’utilisateur. Contrôler ensuite l’exigence MFA, le format du nom d’utilisateur, une liaison d’IP source ou MAC et le message du log Authentication. Une connexion réussie au portail ne prouve pas automatiquement la même méthode ni le même chemin agent.

L’utilisateur est live, mais la mauvaise règle s’applique

Vérifier l’ordre des règles, Match known users, l’utilisateur ou le groupe sélectionné, le service, la destination et la Firewall Rule ID. Identifier d’abord la règle réellement appliquée ; une autorisation large ne remplace pas le diagnostic.

Une seule identité apparaît sur un serveur de terminaux

CAA n’est pas la bonne approche pour ce chemin multi-utilisateurs. Plusieurs instances parallèles de l’agent ne transforment pas l’hôte en système sensible aux sessions. Utiliser SATC pour RDS ou Citrix et le valider séparément.

Pour le diagnostic entre méthodes, voir dépanner systématiquement l’authentification Sophos Firewall.

Rollback et exploitation

En cas d’échec du pilote, arrêter ou supprimer l’agent sur le poste pilote. Rétablir les modifications temporaires d’utilisateur, de groupe, de portail et de règle à leur état antérieur documenté. Retester ensuite l’ancienne méthode d’authentification avec une nouvelle connexion et du trafic réel.

Ne pas supprimer globalement l’Authentication Server CA tant que d’autres installations CAA l’utilisent. Avant un factory reset, un reimage ou un remplacement d’appliance, prévoir la mise à jour de la CA nouvellement générée sur tous les postes concernés.

Documenter au minimum les informations d’exploitation suivantes :

• responsable du package agent et du déploiement ;
• versions de systèmes d’exploitation approuvées ;
• origine et renouvellement de l’Authentication Server CA ;
• chemin attendu vers la destination de l’agent et TCP 9922 ;
• processus MFA et mot de passe ;
• tests pilote et négatif après les modifications SFOS, Endpoint ou VPN ;
• offboarding et suppression des Live Sessions existantes.

Liste de contrôle

• poste mono-utilisateur confirmé plutôt qu’hôte multi-utilisateurs
• serveur d’authentification et ordre documentés
• chemin de l’agent via Sophos Firewall vérifié
• agent et Authentication Server CA téléchargés depuis le même pare-feu
• MSI et CA séparée planifiés ensemble
• limites des plateformes et chemin spécifique Linux pris en compte
• utilisateur pilote préparé avec un groupe et une politique minimaux
• comportement MFA testé
• Live User affiche Authentication agent
• trafic réel autorisé et bloqué testé
• utilisateur, action et Firewall Rule ID confirmés dans le log
• comportement VPN et HA testé avec une nouvelle connexion
• impact du factory reset sur la CA et rollback documentés

Questions fréquentes