Configurer STAS sur Sophos Firewall

STAS signifie Sophos Transparent Authentication Suite. Cette fonction transmet à Sophos Firewall les connexions Windows issues d’Active Directory avec l’IP cliente correspondante. Les utilisateurs et groupes AD peuvent ainsi être utilisés dans les règles de pare-feu sans connexion supplémentaire dans le navigateur ou le portail.

Une connexion Windows uniquement locale, sans connexion au domaine, ne produit pas l’authentification AD nécessaire à STAS. Sans autre association configurée, le pare-feu considère cet utilisateur comme non authentifié et applique la règle de secours ou d’authentification prévue. La connexion au portail captif n’est l’étape suivante que si la configuration le prévoit.

Pour les endpoints individuels hors domaine qui nécessitent une connexion utilisateur explicite, utiliser plutôt le parcours du Client Authentication Agent. STAS reste la voie sans client pour les domaines Windows.

Procédure rapide

1. Préparer les événements d’audit AD, le compte de service et les connexions requises.
2. Configurer Active Directory comme méthode d’authentification principale sur le pare-feu.
3. Installer et configurer STA Agent et STA Collector.
4. Activer STAS sur le pare-feu, ajouter le Collector et autoriser Client Authentication pour les zones clientes.
5. Reconnecter un utilisateur sur un client du domaine et vérifier l’association sous Advanced > Show live users et Current activities > Live users.
6. Tester une règle de pare-feu basée sur les utilisateurs avec journalisation.

Les Sophos Techvids suivants présentent l’architecture et la configuration avec SFOS 21. Le principe reste valable ; certaines interfaces diffèrent légèrement sous SFOS 22.

Planification et prérequis

STAS convient aux clients Windows d’un domaine AD lorsqu’une IP cliente correspond normalement à un seul utilisateur. Le pare-feu doit voir la même IP cliente que celle transmise par STAS. Le NAT, les systèmes proxy ou d’autres passerelles entre le client et le pare-feu peuvent rendre cette association inutilisable.

eDirectory ne convient pas à une nouvelle architecture STAS : STAS ne prend pas en charge les connexions LDAP via SSL/TLS avec eDirectory. SFOS 23 supprime en outre le type de serveur eDirectory natif et eDirectory SSO. Les installations existantes doivent donc suivre la procédure contrôlée de migration d’eDirectory, plutôt que d’être intégrées dans une nouvelle architecture STAS.

Pour les postes de travail Windows 10 administrés avec Sophos Endpoint, Synchronized User ID Authentication peut transmettre l’identité de domaine via Security Heartbeat. Ce chemin ne remplace pas STAS pour Server Protection, les autres versions de Windows ou les environnements sans heartbeat correspondant.

Si l’association utilisateur-IP est créée lors d’une connexion 802.1X sur un contrôleur Wi-Fi ou un network access server, RADIUS SSO avec accounting peut être plus adapté. Ce chemin exige un accounting start avec le nom d’utilisateur et Framed-IP-Address, et non les événements de connexion Windows utilisés par STAS.

Avant la configuration, vérifier les points suivants :

• Active Directory est accessible depuis le pare-feu et le DNS, l’heure et le routage sont corrects.
• Les contrôleurs de domaine enregistrent les événements de connexion réussis.
• Les clients Windows sont membres du domaine.
• Le pare-feu, les Agents et les Collectors communiquent via des adresses IP stables et correctement configurées.
• Sous Administration > Device access > Local service ACL, les zones concernées sont cochées à la ligne Clients de la section Authentication services. Pour plus de détails, consulter Device Access sur Sophos Firewall.
• Le compte de service, les changements de mot de passe et les comptes techniques de l’Exclusion List sont documentés.

STAS 2.5 et les versions ultérieures prennent en charge Windows Server 2008 R2, 2012 R2, 2016, 2019, 2022 et 2025, avec une installation sur un contrôleur de domaine ou dans une architecture documentée avec serveur membre. Il ne faut toutefois plus prévoir d’anciennes versions de serveur pour de nouvelles installations.

Agent, Collector et redondance

Le STA Agent lit les événements de connexion AD. Le STA Collector traite les associations utilisateur-IP et les envoie au pare-feu. Dans l’architecture classique, un Agent s’exécute sur chaque contrôleur de domaine concerné ; depuis STAS 2.5, un serveur membre pris en charge peut pointer vers le contrôleur de domaine. Un Agent peut servir plusieurs Collectors et un Collector plusieurs pare-feu.

Dans les petits environnements, SSO Suite peut installer l’Agent et le Collector sur le même système. En production ou dans les environnements plus importants, un Collector distinct est souvent plus simple à surveiller et génère moins de trafic supplémentaire sur le contrôleur de domaine.

Un groupe de Collectors contient au maximum cinq Collectors. Le premier est principal et les autres servent de secours. Les Collectors du même domaine doivent appartenir au même groupe ; utiliser des groupes distincts pour les sous-domaines ou les domaines séparés.

RDS, Citrix et SATC

Le STAS classique ne peut pas distinguer plusieurs utilisateurs derrière la même IP RDS, de serveur de terminaux ou Citrix. SATC via Sophos Server Protection associe toutes les connexions prises en charge issues des sessions individuelles. Si seuls HTTP et HTTPS via un proxy explicite doivent être évalués par utilisateur, Per-Connection AD SSO pour les hôtes multi-utilisateurs constitue l’alternative la plus légère. L’ancien client SATC legacy autonome n’est plus pris en charge. Lorsque STAS et SATC fonctionnent en parallèle, les IP des serveurs concernés doivent figurer dans les exclusions de connexion et déconnexion de STAS.

Ports et connectivité

Les trois connexions principales sont simples :

Les connexions supplémentaires dépendent des fonctions utilisées :

Pour WMI ou Registry Read Access, les services RPC, RPC Locator, DCOM, WMI ou Registry correspondants doivent être accessibles sur les clients. Les règles Windows Firewall doivent être limitées aux adresses IP des Collectors.

Depuis le Collector, tester les deux ports TCP d’un client de test comme suit :

Test-NetConnection -ComputerName 10.10.20.25 -Port 135
Test-NetConnection -ComputerName 10.10.20.25 -Port 445

TcpTestSucceeded : True confirme uniquement le chemin TCP. Le compte et les accès DCOM, WMI ou Registry doivent ensuite être testés avec WMI Verification ou Registry Read Verification dans STAS.

Préparer Active Directory

Activer les événements de connexion

Sur chaque contrôleur de domaine équipé d’un STA Agent, ouvrir secpol.msc et accéder au chemin suivant :

Security Settings > Local Policies > Audit Policy

Ouvrir Audit account logon events.

Activer Success et Failure, puis enregistrer le paramètre.

Sous Windows Server 2008 et les versions ultérieures, l’événement de sécurité ID 4768 constitue un indicateur rapide d’une authentification de domaine réussie que le STA Agent peut détecter.

Configurer le compte de service STAS

Utiliser un compte documenté pour le service STAS. Il n’a pas besoin d’être Domain Admin, mais nécessite selon l’architecture :

• Domain Users et Event Log Readers sur le contrôleur de domaine
• des autorisations de lecture et d’écriture sur C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\
• Remote Desktop Users, Distributed COM Users et des autorisations WMI sur Root\CIMV2 avec Execute Methods et Remote Enable sur les endpoints
• le droit utilisateur Log on as a service

Les autorisations des endpoints peuvent être distribuées par stratégie de groupe. Si Workstation Polling n’est pas utilisé, ne pas accorder d’autorisations inutilement étendues.

Configurer les autorisations indiquées pour le compte STAS documenté aux emplacements suivants :

1. Sur le contrôleur de domaine, ouvrir dsa.msc. Pour l’utilisateur STAS, choisir Properties > Member of > Add, ajouter Domain Users et Event Log Readers, puis confirmer avec OK.
2. Dans l’Explorateur de fichiers, sous C:\Program Files (x86)\Sophos\, ouvrir Properties > Security du dossier Sophos Transparent Authentication Suite. Accorder Read et Write au compte STAS et enregistrer avec OK.
3. Sur les endpoints concernés, ouvrir lusrmgr.msc. Sous Groups, ouvrir Properties > Add pour Remote Desktop Users et Distributed COM Users, ajouter le compte STAS et confirmer avec OK.
4. Pour l’interrogation WMI sur les endpoints, ouvrir wmimgmt.msc. Choisir WMI Control (Local) > Properties > Security, développer Root > CIMV2 et ouvrir Security. Autoriser Execute Methods et Remote Enable pour le compte STAS et confirmer avec OK.

La distribution des modifications de WMI Control par GPO nécessite un script PowerShell ou de connexion intégré à cette GPO ; l’appartenance aux groupes ne définit pas à elle seule ces autorisations WMI. Vérifier d’abord la mise en œuvre sur un client pilote avec WMI Verification, plutôt que d’accorder des autorisations supplémentaires sans validation.

Le droit utilisateur se trouve sous :

Security Settings > Local Policies > User Rights Assignment

Ajouter ensuite le compte STAS.

Installer et configurer STAS

Vérifier Active Directory sur le pare-feu

Un serveur Active Directory opérationnel doit être configuré sous :

Authentication > Servers

Sous Authentication > Services, définir le serveur AD comme méthode principale pour la zone concernée. Connecter Active Directory à Sophos Firewall explique le domaine NetBIOS, la base de recherche, les groupes et le test de connexion.

Téléchargement et installation

Télécharger le programme d’installation ici :

Authentication > Client downloads

Sous Single Sign-on, cliquer sur Sophos Transparent Authentication Suite (STAS).

Exécuter STAS.exe en tant qu’administrateur et installer l’Agent, le Collector ou SSO Suite selon l’architecture.

Avec plusieurs contrôleurs de domaine, chaque contrôleur concerné nécessite normalement un Agent. La version actuellement distribuée du programme d’installation n’est pas documentée publiquement ; il faut donc la vérifier directement dans le fichier téléchargé.

General

Dans l’onglet General, saisir le nom NetBIOS, le FQDN et le compte de service. Le nom NetBIOS doit être en majuscules.

Lors de la configuration initiale, conserver les valeurs par défaut des paramètres non mentionnés dans la procédure. Les exceptions propres aux versions explicitement décrites ci-dessous ont priorité ; il ne s’agit pas d’une instruction de réinitialiser les paramètres existants en production.

STA Agent

Dans l’onglet STA Agent :

• utiliser EVENTLOG comme STA Agent Mode pour la détection locale dans le journal des événements
• sous Specify the networks to be monitored, saisir uniquement les réseaux clients réels en notation CIDR
• définir Domain Controller IP uniquement dans une architecture avec serveur membre ; laisser le champ vide lorsque SSO Suite s’exécute directement sur le contrôleur de domaine
• ajouter tous les Collectors prévus dans la Collector List

STA Collector

Dans l’onglet STA Collector :

• saisir les adresses IP de pare-feu accessibles sous Sophos appliances
• choisir délibérément WMI ou Registry Read Access comme Workstation Polling Method
• activer Enable Logoff Detection uniquement si le ping et le polling conviennent au réseau client
• avec STAS 2.5.1.0, définir impérativement Dead entry timeout sur 0 en raison du Known Issue NCL-1309 ; Sophos recommande WMI pour Logoff Detection dans cette version

Avec HA, le Collector doit atteindre l’IP de pare-feu configurée via UDP 6060 ; le pare-feu doit disposer du chemin retour vers le Collector via UDP 6677. Tester séparément l’association des utilisateurs après un failover.

WMI est la valeur par défaut documentée de Workstation Polling Method. Après avoir configuré General, STA Agent et STA Collector, enregistrer avec Apply et, lors de la mise en place initiale, utiliser Start pour démarrer le service STAS. Vérifier que le service fonctionne, puis contrôler une nouvelle connexion au domaine dans les deux vues Live Users après l’intégration au pare-feu. Cela ne remplace pas une procédure de redémarrage planifiée pour une installation déjà en production.

Exclusion List

L’Exclusion List doit contenir les comptes susceptibles d’écraser les associations utilisateur normales :

• comptes de sauvegarde, de supervision, de distribution de logiciels et d’endpoint
• comptes d’administration et d’installation
• comptes qui se connectent en arrière-plan sur de nombreux clients
• systèmes sur lesquels aucun utilisateur de poste de travail normal n’est attendu

Les listes sont gérées séparément : sous Login user exclusion list, utiliser Add pour saisir le nom d’utilisateur exact et confirmer avec OK. Pour les serveurs Exchange ou d’autres adresses qui s’authentifient pour le compte d’utilisateurs, utiliser Login IP address / network subnet mask exclusion list ou Logoff IP address / network subnet mask exclusion list, selon l’événement. Choisir Add, saisir l’adresse ou le réseau en notation CIDR et confirmer avec OK ; par exemple, saisir un hôte unique sous la forme 192.168.100.100/32. Pour terminer, choisir Apply, OK, puis Yes. Une nouvelle connexion doit montrer que l’utilisateur prévu du poste de travail n’est plus remplacé.

Sans Exclusion List, un compte de service utilisant la même IP peut remplacer l’utilisateur dans Live Users peu après une connexion réelle.

Activer STAS sur le pare-feu

Sous le chemin suivant, activer Enable Sophos Transparent Authentication Suite et sélectionner Activate STAS :

Authentication > STAS

Ajouter chaque Collector avec Collector IP, Collector port et Collector group. Dans l’onglet General de STA Suite, le pare-feu doit apparaître sous Sophos appliances.

Pour cela, choisir Add new collector sous Authentication > STAS, saisir l’IP réelle du Collector et son port configuré, puis sélectionner sous Collector group un groupe nouveau ou existant correspondant au domaine concerné. Enregistrer avec Save. La limite de cinq Collectors par groupe et la séparation des différents domaines s’appliquent également ici.

Ensuite, accéder à Administration > Device access > Local service ACL et cocher chaque zone requise à la ligne Clients de la section Authentication services.

Les principales valeurs STAS sur le pare-feu sont :

STAS quarantine rejette le trafic entrant lorsque le Collector ne fournit pas d’association correspondante entre utilisateur et IP de destination. Enable user inactivity déconnecte les utilisateurs qui ne transfèrent pas assez de données pendant la période définie. Le comportement décrit et les paramètres d’inactivité doivent être adaptés au comportement des règles et des clients.

Sophos documente ces valeurs par défaut, mais le choix opérationnel dépend des règles. Avanet recommande de conserver No et de vérifier le comportement pendant la probe avec une règle de trafic non authentifié choisie explicitement. Avant de modifier le traitement du trafic pendant la vérification d’identité via Restrict client traffic during identity probe, réaliser un pilote couvrant la connexion, le changement d’utilisateur, la déconnexion et la panne du Collector.

Pour le contrôle d’inactivité après le pilote, aller sous Authentication > STAS, activer Enable user inactivity, définir Inactivity timer en minutes et Data transfer threshold comme volume minimal de données transférées en octets, puis choisir Apply. Vérifier ensuite sous Current activities > Live users qu’un utilisateur de test réellement inactif est retiré après la période configurée. Les valeurs par défaut documentées ne constituent pas une recommandation universelle pour tous les environnements de production.

⚠️ SFOS 22 / NC-181885 : Sous SFOS 22.0 MR1 Build 490, Restrict client traffic during identity probe = Yes peut provoquer des probes répétés et des interruptions de trafic. Lors d’une mise à niveau de GA ou d’une version antérieure vers MR1, la même valeur peut bloquer la tentative ou déclencher un avertissement. No est la solution temporaire documentée. Planifier le passage à la version corrigée SFOS 22.0 MR2 Build 546 avec le guide de mise à jour du firmware du firewall ; MR2 définit également No par défaut. Vérifier toute valeur existante avant et après la mise à niveau. Les autres blocages sont décrits dans le contrôle de mise à niveau SFOS 22.

Gérer l’état de STAS et les Collectors depuis la CLI

La configuration habituelle reste visible dans WebAdmin. Pour le diagnostic, un dossier Support ou une étape de récupération contrôlée, la Device Console fournit également des commandes CTA globales. Avant toute modification, consigner l’état et la liste des Collectors :

system auth cta show

Un Collector peut être ajouté ou supprimé à l’aide de son adresse IP. Continuer à vérifier son port, le groupe de Collectors et le reste de la configuration STAS dans WebAdmin :

system auth cta collector add collector-ip <COLLECTOR-IP>
system auth cta collector delete collector-ip <COLLECTOR-IP>

La fonction STAS globale peut également être activée ou désactivée :

system auth cta enable
system auth cta disable

Important : disable n’est pas un test isolé sans risque. Cette commande désactive STAS globalement et peut donc affecter les règles basées sur les utilisateurs. Effectuer une modification uniquement avec l’état initial et le chemin de rollback consignés. Vérifier ensuite system auth cta show, la connectivité du Collector, une nouvelle connexion au domaine, Live Users et une règle utilisateur journalisée.

Règle de pare-feu basée sur les utilisateurs

Créer une règle avec le groupe AD prévu et activer Log firewall traffic uniquement lorsqu’un utilisateur de test apparaît de manière stable dans Live Users.

Créer la règle sous Rules and policies > Firewall rules : sélectionner IPv4 et ouvrir Add firewall rule > New firewall rule. Associer le groupe AD prévu dans les paramètres utilisateur ; la journalisation et la vérification ultérieure avec du trafic utilisateur réel restent nécessaires.

Dans Log Viewer, le nom d’utilisateur, le groupe, l’ID de règle et l’action doivent correspondre aux attentes. L’analyse générale des règles est décrite dans Tester une règle de pare-feu avec Log Viewer, Policy Tester et Packet Capture.

Vérifier et exploiter la configuration

Tester toute la chaîne de manière contrôlée :

1. Reconnecter un utilisateur de test sur un client du domaine.
2. Vérifier l’événement de sécurité 4768 sur le contrôleur de domaine.
3. Contrôler STA Agent et STA Collector.
4. Ouvrir Advanced > Show live users dans STAS.
5. Vérifier Current activities > Live users sur le pare-feu.
6. Tester la règle basée sur les utilisateurs avec du trafic réel et la journalisation.
7. Tester la déconnexion, le changement d’utilisateur et un compte technique de l’Exclusion List.

Les outils STAS locaux se trouvent sous Advanced > Troubleshooting :

• Test Connectivity > Sophos vérifie la connexion au pare-feu.
• Test Connectivity > STAS Agent vérifie la connexion du Collector vers l’Agent.
• Test Connectivity > STAS Collector vérifie la connexion de l’Agent vers le Collector.
• STAS Polling Utilities > WMI Verification et Registry Read Verification testent l’accès à une IP cliente.

Pour chaque test de connectivité, saisir l’IP cible exacte et sélectionner Test. Si Test Connectivity > Sophos indique une réussite tout en signalant que le Collector n’est pas défini ou que STAS est désactivé, seul le transport est accessible. La chaîne SSO n’est confirmée qu’après correction de la configuration du pare-feu et apparition d’une nouvelle entrée dans Live Users.

Le journal est disponible sous Advanced > View Log et à l’emplacement suivant sur le système Windows :

C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\stas.log

Avant toute modification importante, créer une sauvegarde sous Advanced > Backup / Restore > Backup Now. Le fichier est nommé STAS_ConfigBackup_DD_MM_YYYY_THH_MM_SS.bkp et se restaure via Upload and Restore. Une restauration remplace la configuration STAS de cette installation ; il faut donc aussi relever au préalable les valeurs du firewall, les groupes de Collectors et Device Access. Pour revenir en arrière, restaurer la sauvegarde ou annuler les valeurs modifiées, puis répéter la vérification de bout en bout. Ne désactiver globalement Client Authentication ou STAS qu’après avoir validé une règle de secours qui maintient l’accès.

Pour la sauvegarde et la restauration, se connecter à l’hôte STAS concerné avec des identifiants administrateur et ouvrir STAS. Après Backup Now, sélectionner l’emplacement de sauvegarde et choisir OK. Pour restaurer, saisir le chemin du fichier .bkp prévu sous Advanced > Backup / Restore ou le sélectionner avec Browse avant de choisir Upload and Restore. Ce retour arrière n’a pas été testé ici sur le produit ; le relevé de l’état et les contrôles de bout en bout décrits précédemment restent nécessaires.

Synchroniser les configurations STAS

Plusieurs installations STAS peuvent être synchronisées de manière ciblée sous Advanced > Configuration Sync. L’opération est lancée sur le système source, puis l’adresse IP de l’installation cible est saisie. Cela duplique les paramètres des composants STAS ; la fonction ne remplace ni le groupe de collectors sur la firewall ni son test de failover.

Les combinaisons prises en charge sont SSO Suite vers SSO Suite avec les paramètres agent et collector, agent vers SSO Suite avec les seuls paramètres agent, collector vers SSO Suite avec les seuls paramètres collector, agent vers agent et collector vers collector. Sophos ne prend pas en charge les autres combinaisons. Créer d’abord une sauvegarde sur les deux systèmes ; vérifier ensuite la configuration agent et collector, les tests de connectivité et un nouveau live user.

En exploitation, maintenir le compte de service, l’Exclusion List, les réseaux surveillés et les GPO Windows Firewall. Répéter le test de bout en bout après toute mise à jour de Windows, d’un contrôleur de domaine, de STAS ou du pare-feu. Si de très nombreux objets utilisateur s’accumulent au fil des ans, ou si seuls certains utilisateurs de portail ou de VPN échouent, vérifier également la limite d’ID utilisateur de Sophos Firewall.

Dépannage

Aucun utilisateur dans Live Users

Vérifier dans cet ordre :

1. L’événement ID 4768 est-il généré sur le contrôleur de domaine ?
2. Le STA Agent s’exécute-t-il et surveille-t-il le bon contrôleur de domaine ainsi que le bon réseau client ?
3. L’Agent peut-il atteindre le Collector via TCP 5566 ?
4. UDP 6060 et 6677 fonctionnent-ils entre le Collector et le pare-feu ?
5. Client Authentication est-il autorisé pour la zone cliente ?
6. Le pare-feu voit-il la même IP cliente que STAS ?

S’il reste difficile de déterminer si l’échec concerne STAS, la sélection du service, l’enregistrement utilisateur local ou seulement la règle utilisateur, Résoudre méthodiquement les erreurs d’authentification sur Sophos Firewall guide la chaîne de contrôle commune aux différentes méthodes.

La protection des endpoints peut également bloquer les communications STAS, et plusieurs cartes réseau peuvent entraîner une liaison STAS incorrecte. Si le Collector se trouve derrière un tunnel IPsec, le trafic du pare-feu généré par le système peut nécessiter une IP SNAT adaptée.

L’utilisateur est mal associé

Vérifier si un compte de sauvegarde, de supervision, d’installation ou d’administration écrase le même client. Ajouter le compte concerné à l’Exclusion List et répéter le test avec une nouvelle connexion utilisateur. Si l’adresse IP appartient désormais à un autre appareil, comparer aussi le bail DHCP et le chemin NAT ou proxy : STAS ne peut associer l’utilisateur sans ambiguïté que si le firewall et le Collector utilisent la même IP client actuelle. Après correction, provoquer une nouvelle connexion au lieu d’attendre sur une ancienne entrée Live Users.

L’utilisateur disparaît trop vite

Avec STAS 2.5.1.0, Dead entry timeout doit être défini sur 0 en raison de NCL-1309. Vérifier ensuite Advanced > Show live users, stas.log ainsi que la vérification WMI ou Registry sur le client.

Erreurs DCOM ou réseaux incorrects

Les événements Windows 10009 ou 10028 surviennent souvent lorsque le Collector interroge des systèmes inaccessibles. Dans ce cas :

1. Dans l’onglet STA Collector, modifier le pare-feu sous Sophos appliances.
2. Activer Enable subnet based filter et saisir uniquement les réseaux clients réels.
3. Dans l’onglet STA Agent, vérifier les mêmes réseaux sous Specify the networks to be monitored.
4. Appliquer les modifications, redémarrer STAS et contrôler de nouveau stas.log.

Des utilisateurs avec LogonType: 1 issus de réseaux non surveillés signalent un filtrage absent ou inadapté. Après correction, SSOclient_filter_CR_subnet: Workstation filtered out dans stas.log confirme que STAS a exclu un poste de travail comme prévu.

La règle utilisateur ne correspond pas

Vérifier si l’utilisateur apparaît dans Live Users, si le groupe AD attendu est résolu et si Log Viewer affiche le nom d’utilisateur plutôt que la seule IP. Contrôler ensuite la position de la règle et toute règle de fallback antérieure. Utiliser l’article lié sur le test des règles pour poursuivre l’analyse.

Identity Probe et période de transition CTA

Lorsque le pare-feu détecte du trafic provenant d’une IP inconnue, il lance un Identity Probe. Avec Restrict client traffic during identity probe = Yes, le trafic est bloqué pendant le contrôle ; avec No, il continue. Si le Collector ne répond pas, le pare-feu traite ensuite l’IP comme non authentifiée pendant une heure et applique les règles correspondantes au trafic non authentifié.

Après cette heure, l’IP repasse en mode d’apprentissage pour réessayer la connexion ou l’association utilisateur. Ce nouvel Identity Probe ne correspond pas à la Drop Period configurable séparément.

La commande suivante affiche les paramètres CTA actuels dans l’option 4 de la Device Console :

system auth cta show

La valeur Drop Period distincte peut être définie de 1 à 120 secondes :

system auth cta unauth-traffic drop-period <1-120>

Exemple pour 40 secondes :

system auth cta unauth-traffic drop-period 40

Les valeurs inférieures à 20 secondes peuvent interrompre le processus d’apprentissage et rediriger les utilisateurs du domaine vers le Captive Portal. Modifier la valeur uniquement avec un scénario de test documenté, puis vérifier de nouveau system auth cta show, Live Users et le client concerné. Pour les appareils hors domaine, Clientless Users avec une IP fixe ou des règles distinctes sont généralement plus adaptés.

STAS via VPN

STAS peut détecter les utilisateurs d’une succursale via un VPN IPsec avec un contrôleur de domaine sur le site principal. Le routage, l’IP source et les réseaux surveillés doivent correspondre. Dans l’architecture de référence Sophos, les deux pare-feu sont intégrés à STAS ; le contrôleur de domaine peut se trouver uniquement sur le site principal.

Prérequis :

• La connexion IPsec et le routage via le tunnel fonctionnent.
• Le réseau de la succursale est défini comme réseau surveillé dans STA Agent.
• Le pare-feu de la succursale est configuré sous Sophos appliances dans STA Collector.
• Client Authentication est autorisé pour la zone VPN.

Sur le pare-feu du site principal, ajouter le réseau distant dans la Device Console :

system auth cta vpnzonenetwork add source-network 10.20.50.0 netmask 255.255.255.0

Remplacer le réseau d’exemple par le réseau réel de la succursale, puis tester une nouvelle connexion au domaine, Live Users et une règle utilisateur journalisée à travers le tunnel. Pour le rollback, supprimer exactement le même réseau avec delete :

system auth cta vpnzonenetwork delete source-network 10.20.50.0 netmask 255.255.255.0

La suppression de l’entrée retire uniquement l’association STAS pour ce réseau VPN. Le tunnel, le routage et les règles de pare-feu restent des configurations distinctes à contrôler séparément.