Configurer SATC Sophos Firewall pour Remote Desktop Services

Sophos Authentication for Thin Client, abrégé SATC, aide à appliquer des règles utilisateur sur Remote Desktop Services. C’est important chaque fois que plusieurs utilisateurs accèdent au réseau ou à Internet via le même Windows Remote Desktop Session Host. Dans ces cas, le STAS classique ne voit souvent que l’adresse IP du serveur terminal. SATC fournit au contraire à Sophos Firewall les informations utilisateur provenant des différentes sessions RDS.

Pour les clients Windows standard, il faut d’abord configurer STAS sur Sophos Firewall. SATC ne remplace pas STAS dans chaque environnement, mais constitue le bon composant pour Remote Desktop Services.

Déploiement et planification

Quand SATC est utile

SATC convient lorsque les utilisateurs ne passent pas directement à travers le pare-feu depuis leur propre client, mais utilisent des applications ou un navigateur sur un Remote Desktop Session Host.

Scénarios typiques :

• Remote Desktop Services avec plusieurs utilisateurs simultanés
• serveurs terminaux sur lesquels les utilisateurs ont besoin d’un accès web ou applicatif
• règles de pare-feu basées sur l’utilisateur pour les utilisateurs RDS
• reporting dans lequel l’adresse IP du serveur RDS ne doit pas être la seule information visible
• environnements où STAS ne suffit pas proprement à cause d’une IP source partagée

SATC n’est pas le bon point de départ pour des clients de domaine normaux, des utilisateurs VPN ou des scénarios purement Captive Portal. Dans ces cas, il faut d’abord choisir le modèle d’authentification approprié : STAS, Captive Portal, authentification VPN, RADIUS ou Microsoft Entra ID SSO.

Sur un endpoint individuel hors domaine, le Client Authentication Agent peut assurer une connexion utilisateur explicite. Il ne remplace pas SATC sur un hôte multi-utilisateurs, car plusieurs sessions partagent la même IP source.

Si un hôte multi-utilisateurs doit uniquement distinguer HTTP et HTTPS via un proxy explicite, Per-Connection AD SSO via le Direct Web Proxy peut suffire sans agent SATC. Dès que RDP, SMB ou un autre trafic sans proxy nécessite aussi une identité par session utilisateur, SATC reste la conception appropriée.

Bien séparer STAS et SATC

La différence la plus importante est l’association IP.

• Un client Windows appartient généralement à un utilisateur: STAS.
• De nombreux utilisateurs partagent la même IP de serveur RDS: SATC.
• Les utilisateurs se connectent dans le navigateur pour que les règles s’appliquent: Captive Portal.
• Les utilisateurs arrivent via Remote Access VPN: Authentification VPN ou Entra ID SSO.
• Le trafic passe par des serveurs techniques sans référence utilisateur: règles de pare-feu normales sans utilisateur.

Si un serveur terminal est représenté à tort via STAS ou Clientless User, de fausses attentes apparaissent rapidement. Une règle semble basée sur l’utilisateur, mais le pare-feu ne voit en réalité qu’une IP serveur partagée. SATC résout précisément ce problème, mais nécessite pour cela une configuration dédiée sur le serveur Windows et sur le pare-feu.

Si STAS et SATC sont utilisés en même temps, la séparation conceptuelle seule ne suffit pas. Citrix XenApp et Windows Server RDS peuvent amener STAS à fournir une identité utilisateur incorrecte pour la même IP de serveur si elle n’est pas exclue. C’est pourquoi les adresses IP des serveurs Citrix/RDS doivent être ajoutées dans la configuration STAS sous Login IP Address/Network Subnet mask Exclusion List et Logoff IP Address/Network Subnet mask Exclusion List. Sans cette exclusion, STAS peut continuer à fournir sa propre association utilisateur contradictoire précisément pour les IP de serveur censées utiliser SATC.

Prérequis

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

• Sophos Server Protection peut être utilisé sur le Remote Desktop Session Host.
• Le serveur Windows fonctionne comme Remote Desktop Session Host.
• Windows Server 2016 ou une version ultérieure est utilisé.
• Sophos Firewall est accessible.
• Active Directory est connecté à Sophos Firewall.
• Les groupes AD nécessaires sont importés sur le pare-feu.
• Sous Administration > Device access, la zone du serveur RDS est autorisée dans la ligne Clients.
• Le serveur RDS peut atteindre l’adresse IP du pare-feu via UDP 6060 ; tout pare-feu hôte ou réseau intermédiaire autorise ce chemin.
• Les règles de pare-feu pourront ensuite utiliser Match known users.
• Une fenêtre de maintenance existe pour la modification Registry et le redémarrage du serveur RDS.

La connexion AD doit être correctement configurée avant la mise en place de SATC. Si AD n’est pas encore prêt, il faut d’abord vérifier Connecter Active Directory à Sophos Firewall.

Limites importantes

SATC a quelques limites qu’il faut connaître avant le déploiement :

• Standalone-SATC: N’est plus supporté par Sophos Firewall.
• Déploiement: SATC fonctionne via Sophos Server Protection ou le Sophos Fusion Server Core Agent.
• Plateforme : selon Sophos, la configuration actuelle avec Sophos Server Protection prend uniquement en charge Windows Remote Desktop Services. L’ancienne présentation mentionne encore Citrix XenApp dans le contexte du conflit avec STAS, et le paramètre CLI s’appelle toujours citrix-ip. Aucun de ces éléments ne constitue une preuve actuelle de prise en charge pour un nouveau déploiement Citrix. Un environnement Citrix existant doit donc être confirmé auprès de Sophos Support avant toute modification et ne doit pas être recréé à partir de ce guide RDS.
• Services système : SATC attribue une identité d’annuaire uniquement aux connexions créées par des processus utilisateur. Les processus lancés par les services système Windows restent sans identité utilisateur et nécessitent une règle machine distincte et étroitement limitée avec Match known users désactivé. Cette règle ne doit pas servir de règle de secours large pour le reste du trafic RDS.
• Limite serveur: Sophos indique jusqu’à 192 serveurs Thin Client sur le pare-feu.
• Authentification par IP serveur: Lorsqu’une IP de serveur RDS est enregistrée sur le pare-feu comme Thin Client, SATC fonctionne comme méthode d’authentification pour cette IP. Les autres méthodes comme Clientless User ne s’appliquent pas à cette IP.

Le dernier point est particulièrement important. Il ne faut pas enregistrer à titre d’essai des IP de serveurs terminaux productifs sans comprendre les règles et le chemin de retour. Dès que l’IP est traitée comme source SATC, les attentes changent pour l’association utilisateur et le matching des règles.

Configuration

Vue d’ensemble du déroulement

Le déroulement technique comprend cinq parties :

1. Installer Sophos Server Protection sur le serveur RDS.
2. Activer SATC par Registry sur le serveur RDS.
3. Enregistrer l’IP du serveur RDS dans la Device Console de Sophos Firewall.
4. Vérifier le serveur AD, les groupes et l’ordre d’authentification sur le pare-feu.
5. Valider Device Access, la règle de pare-feu et Live Users.

SATC ne doit pas seulement être installé, mais aussi testé. Une installation réussie sur le serveur ne prouve pas encore que le pare-feu verra ensuite le bon utilisateur dans la bonne règle.

Installer Sophos Server Protection

L’installation se fait via Sophos Fusion (anciennement Sophos Central).

Procédure :

1. Se connecter à Sophos Fusion.
2. Ouvrir Protect Devices.
3. Télécharger le Windows Server Installer sous Server Protection.
4. Exécuter le programme d’installation sur le Remote Desktop Session Host.
5. Vérifier si le serveur apparaît correctement dans Sophos Fusion.
6. Définir une fenêtre de maintenance pour l’activation de SATC.

SATC fait partie du Sophos Fusion Server Core Agent et, selon Sophos, est disponible avec toute licence Server Protection. Les installateurs réellement visibles dans Sophos Fusion dépendent néanmoins des licences disponibles. Si Sophos Server Protection fonctionne déjà sur le serveur, il faut également vérifier si l’agent est à jour et si Tamper Protection peut être désactivé de manière contrôlée, puis réactivé ensuite.

Activer SATC par Registry

SATC est contrôlé sur le serveur RDS par des valeurs Registry sous ce chemin :

HKLM\Software\Sophos\Sophos Network Threat Protection\Application

Avant la modification, cette commande en lecture seule affiche les valeurs SATC déjà présentes :

reg query "HKLM\Software\Sophos\Sophos Network Threat Protection\Application"

Attention : Les modifications du registre et le redémarrage qui suit affectent toutes les sessions RDS actives. Documenter les valeurs actuelles, utiliser une fenêtre de maintenance et ne désactiver Tamper Protection que de manière contrôlée. La réactiver après la modification.

La configuration de base peut être définie dans une invite de commandes administrative :

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationAddr /t REG_SZ /d FIREWALL-IP /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationPort /t REG_DWORD /d 6060 /f

Remplacer FIREWALL-IP par l’adresse IPv4 de Sophos Firewall accessible depuis la zone du serveur RDS. Sophos documente UDP 6060 pour SATC ; 6060 reste donc inchangé dans l’exemple. Ne pas utiliser une adresse WAN publique lorsque le serveur et le pare-feu communiquent via une interface interne.

Recommandation Avanet : Commencer par connecter un seul hôte RDS et autoriser UDP 6060 uniquement entre cet hôte et le pare-feu. Une erreur reste ainsi limitée au serveur pilote avant l’ajout d’autres Session Hosts.

Ensuite :

1. Réactiver Tamper Protection.
2. Redémarrer le serveur RDS.
3. Après le redémarrage, vérifier si le service Sophos fonctionne.
4. Exécuter à nouveau la commande en lecture seule reg query et contrôler les valeurs définies.
5. Poursuivre seulement ensuite avec la configuration du pare-feu et les tests.

Exclure les comptes locaux et les destinations

Par défaut, des comptes locaux comme SYSTEM ou Administrator peuvent aussi générer des événements SATC. Ce n’est généralement pas utile pour des règles utilisateur et peut polluer inutilement les journaux.

SatcExcludedUsers permet d’exclure des utilisateurs. Les entrées sont sensibles à la casse ; les noms doivent donc reprendre exactement la graphie utilisée sur le système.

Exemple :

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0administrator" /f

SatcExcludedAddresses permet d’exclure des destinations pour lesquelles aucune information SATC ne doit être envoyée au pare-feu. Cela peut être pertinent pour des destinations locales de gestion, de mise à jour ou d’infrastructure, mais doit être documenté consciemment.

SatcExcludedAddresses est une valeur de chaînes multiples (MULTISTRING / REG_MULTI_SZ). Pour définir plusieurs destinations avec reg add dans l’invite de commandes Windows, séparer les entrées de l’argument de données /d par \0, et non par des virgules. Les étapes de maintenance, de protection contre les modifications, de vérification et de retour arrière décrites plus haut s’appliquent aussi à ce changement.

Formats possibles :

192.0.2.10
192.0.2.10:443
*:443

192.0.2.10 est une adresse de documentation à remplacer par l’adresse IP réelle de la destination. La deuxième entrée s’applique uniquement au port 443 de cette destination, tandis que *:443 couvre ce port pour toutes les destinations. Une exception aussi large retirerait pratiquement tout le trafic HTTPS de l’association SATC et ne convient pas aux règles utilisateur normales.

Recommandation Avanet : Commencer sans exception et n’en ajouter une qu’après un constat de journal concluant. Attribuer à chaque exception un responsable, un motif et une date de révision.

En cas de latence réseau notable entre le serveur RDS et le pare-feu, SatcPendDurationMs peut également être défini. Cette valeur détermine combien de temps les connexions TCP IPv4 sortantes sont retenues afin que l’association utilisateur soit disponible à temps. Si la valeur de registre est absente, SATC utilise 100 millisecondes ; 0 désactive uniquement ce délai de connexion, pas SATC. Modifier la valeur seulement en cas de problème de latence réel, pas par précaution.

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /t REG_DWORD /d 300 /f

300 est un exemple de diagnostic adaptable, pas un nouveau défaut recommandé. Il augmente le délai par rapport au défaut documenté de 100 millisecondes pour chaque connexion TCP IPv4 sortante concernée. Mesurer avant et après avec le même utilisateur et la même destination. Si ce réglage n’apporte rien, la commande administrative suivante rétablit le défaut en supprimant la valeur facultative :

reg delete "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /f

Comme pour les autres modifications Registry, un redémarrage du serveur RDS est ensuite nécessaire.

Enregistrer le serveur RDS sur le pare-feu

Le pare-feu doit savoir quels serveurs fournissent les informations SATC. Cela se fait dans la Device Console, pas dans l’Advanced Shell.

Procédure :

1. Se connecter à Sophos Firewall par console ou SSH.
2. Ouvrir l’option 4. Device Console.
3. Afficher les entrées existantes :

system auth thin-client show

4. Ajouter l’IP du serveur RDS uniquement si elle ne figure pas encore dans la liste :

system auth thin-client add citrix-ip <RDS-SERVER-IP>

<RDS-SERVER-IP> est remplacé par l’adresse IP du Remote Desktop Session Host.

Si plusieurs serveurs RDS existent, enregistrer chaque serveur individuellement et de manière documentée. Ensuite, les points suivants doivent être clairs :

• quels serveurs sont considérés comme sources SATC
• quelle zone ces serveurs utilisent
• quelles règles de pare-feu évaluent les utilisateurs de ces serveurs
• qui valide les modifications de la liste des serveurs RDS

Si une adresse IP incorrecte a été ajoutée, contrôler à nouveau la liste, puis la supprimer de manière ciblée :

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

Cette commande supprime uniquement l’entrée Thin Client sur le pare-feu ; les valeurs de registre et Sophos Server Protection restent en place sur le serveur RDS. Pour une adresse IP en production, l’association SATC disparaît et les règles basées sur l’utilisateur peuvent ne plus correspondre. Sophos ne documente pas la réaction des sessions existantes. Il faut donc supprimer l’entrée uniquement pendant une fenêtre de maintenance et avec une procédure de retour en arrière préparée.

Vérifier Active Directory et les groupes

SATC fournit des informations utilisateur. Pour que le pare-feu puisse utiliser ces informations dans les règles, la connexion AD et les groupes doivent être corrects.

Vérifier :

1. Ouvrir Authentication > Servers.
2. Vérifier le serveur AD avec Test connection.
3. Contrôler l’import des groupes.
4. Ouvrir Authentication > Groups.
5. Rechercher les groupes pertinents.
6. Ouvrir Authentication > Services.
7. Vérifier le serveur AD dans le bon ordre des firewall authentication methods.

Uniquement si AD doit être interrogé en premier : Avant toute modification, documenter l’ordre actuel et vérifier l’ordre d’authentification souhaité ainsi que le plan de retour arrière ; ne pas réorganiser aveuglément l’authentification en production. Sous Authentication > Services > Firewall authentication methods, sélectionner le serveur AD concerné, le déplacer en première position dans la liste des serveurs sélectionnés et cliquer sur Apply. En cas d’effets indésirables, rétablir l’ordre précédent documenté et cliquer sur Apply.

Pour l’affectation aux groupes AD, Sophos indique que l’authentification associe les utilisateurs à leurs groupes AD importés sur le pare-feu ; les groupes sont évalués et actualisés à chaque connexion. Ce n’est que si aucun groupe AD de l’utilisateur n’existe sur le pare-feu que celui-ci reçoit le Default group configuré sous Authentication > Services > Firewall authentication methods. Ce mécanisme de repli ne remplace pas l’import des groupes manquants.

Contradiction entre sources lors de la première connexion : La description de configuration de SATC indique une affectation automatique au groupe par défaut lors de la première connexion au pare-feu, tandis que la description des groupes AD prévoit un repli conditionnel. Il n’est pas établi qu’il s’agisse d’un état initial propre à SATC. Ne supposer ni une affectation générale au groupe par défaut ni une priorité de groupes particulière à SATC.

Avant le déploiement en production : Vérifier les groupes importés sous Authentication > Groups et la valeur réellement configurée de Default group, avec les paramètres hérités, sous Authentication > Services. Demander à un utilisateur de test de se reconnecter, contrôler son affectation effective aux groupes sous Authentication > Users et utiliser du trafic de test RDS dans Log Viewer pour vérifier la règle prévue ainsi que les accès autorisés et bloqués. Si le repli doit être utilisé, le tester aussi avec un compte de test dont les groupes AD ne sont pas présents sur le pare-feu, sans supprimer de groupes de production. L’appartenance au groupe par défaut ne suffit pas à prouver que la règle souhaitée s’applique. En cas d’affectation inattendue, arrêter le déploiement et clarifier la situation avec Sophos Support ; ne pas élargir les groupes d’utilisateurs ou les règles pour contourner le problème.

Si les utilisateurs apparaissent dans la zone Live Users, mais que les règles ne s’appliquent pas, la cause n’est souvent pas SATC lui-même, mais l’import des groupes, le groupe par défaut, le critère de règle ou la position de la règle.

Définir Device Access et la règle de pare-feu

Pour que le pare-feu accepte les messages SATC de la zone serveur, le service local Clients doit être autorisé pour cette zone. SFOS 22 documente UDP 6060 à cet effet ; Clients couvre aussi STAS et Client Authentication Agent sur son propre port.

Chemin :

Administration > Device access

Activer la zone du serveur RDS dans la ligne Clients. Il ne faut pas ouvrir aveuglément WAN ou une zone large et non sûre. Device Access contrôle les services locaux du pare-feu et fait partie du durcissement de gestion.

Ensuite, le trafic proprement dit a besoin d’une règle de pare-feu.

Déroulement typique :

1. Ouvrir Rules and policies > Firewall rules.
2. Créer une règle adaptée au trafic du serveur RDS ou de la zone serveur. Comme exemple adaptable, la règle RDS-Web-Users peut d’abord autoriser uniquement le service HTTPS nécessaire depuis l’objet hôte RDSH-01, de LAN vers WAN.
3. Adapter Source zones, Source networks and devices, Destination zones et Services à la topologie. RDSH-01, LAN, WAN et HTTPS sont des exemples, pas des exigences du produit.
4. Activer Match known users.
5. Sélectionner les utilisateurs AD ou groupes AD nécessaires.
6. Activer la journalisation pour que le test soit ensuite traçable.
7. Enregistrer la règle.
8. Générer du trafic de test depuis une session RDS.

Recommandation Avanet : Rendre la règle pilote plus restrictive que la future règle de production et la placer juste au-dessus d’une règle de blocage documentée. N’élargir les services ou groupes d’utilisateurs qu’après un test réussi avec deux utilisateurs RDS distincts.

La journalisation est importante pour le dépannage ultérieur. Si une règle utilisateur est créée sans journalisation, il est plus difficile de savoir si SATC, le matching des groupes, l’ordre des règles ou un autre chemin est le problème.

Validation et exploitation

Validation après la configuration

Après la configuration, il ne faut pas seulement vérifier si un utilisateur a accès à Internet. Le point décisif est de savoir si le pare-feu voit le bon utilisateur et matche la bonne règle.

Test pratique :

1. Connecter un utilisateur à une session RDS.
2. Générer un trafic de test défini, par exemple une connexion HTTPS autorisée.
3. Ouvrir Current activities > Live users dans Sophos Firewall.
4. Vérifier si l’utilisateur apparaît avec Client type Thin client.
5. Vérifier que l’adresse IP du serveur RDS apparaît avec un identifiant de session unique pour chaque utilisateur.
6. Ouvrir Log Viewer.
7. Filtrer par Source IP du serveur RDS, utilisateur et règle.
8. Vérifier si la règle basée sur l’utilisateur attendue s’applique.

Répéter le test avec un deuxième utilisateur et la même connexion de destination. Le succès ne signifie pas seulement que les deux connexions sont autorisées : Live users doit afficher deux identités avec la même IP de serveur RDS, mais des ID de session différents, et Log Viewer doit montrer le bon utilisateur dans chaque cas. Tester aussi un service système documenté si une règle machine distincte a été créée ; ce trafic ne doit pas être attribué à tort à un utilisateur connecté.

Pour une analyse plus approfondie dans l’Advanced Shell, firewall_rule.log est pertinent pour la correspondance des règles et access_server.log pour l’authentification et l’autorisation. Le Log Viewer reste le moyen de contrôle initial le plus rapide.

Si le trafic ne fonctionne pas comme prévu, consultez également Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture. Si les utilisateurs sont visibles, mais que les groupes ou certains utilisateurs ne matchent pas, La règle Sophos Firewall ne matche pas est le prochain chemin de vérification adapté.

Exploitation et documentation

SATC doit être exploité comme un composant d’authentification productif, pas comme une modification Registry ponctuelle.

Documenter :

• serveurs RDS et adresses IP
• IP de pare-feu utilisée et port SATC
• valeurs Registry définies
• utilisateurs et destinations exclus
• règles de pare-feu concernées
• groupes AD et responsable
• utilisateur de test et matching de règle attendu
• fenêtre de maintenance et heure de redémarrage

Après des mises à jour de Sophos Server Protection, Windows Server, Sophos Firewall ou AD, SATC doit être vérifié de manière ciblée avec un utilisateur de test. Les problèmes d’authentification ne deviennent souvent visibles que lorsque les règles utilisateur deviennent soudainement trop larges ou ne s’appliquent plus du tout.

Retour arrière dans une fenêtre de maintenance

Sophos documente que SendSatcEvents n’active SATC que si la valeur existe et n’est pas égale à 0, et que l’entrée Thin Client remplace les autres méthodes d’authentification pour cette IP serveur. Cela fournit une procédure de retour planifiée, mais ne rétablit pas automatiquement la méthode d’identité précédente.

1. Consigner auparavant la requête Registry, la sortie de system auth thin-client show, les règles concernées et le modèle d’authentification précédent.
2. Déconnecter les sessions RDS actives pendant la fenêtre de maintenance, désactiver Tamper Protection de manière contrôlée, puis désactiver SendSatcEvents dans une invite de commandes administrative :

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 0 /f

3. Réactiver Tamper Protection et redémarrer le serveur RDS.
4. Dans la Device Console, contrôler l’entrée avec system auth thin-client show, puis la supprimer de manière ciblée :

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

5. Rétablir le modèle de règles et d’authentification précédemment documenté, puis le valider avec un utilisateur de test. Ne pas activer sans test un Clientless User ou une règle machine large en guise de remplacement.

Recommandation Avanet : Ne pas supprimer toutes les valeurs Registry avant d’avoir identifié la cause. La valeur 0 conserve l’adresse de destination et les listes d’exclusion pour une réactivation contrôlée ; un export Registry conserve en plus l’état initial exact.

Troubleshooting

Aucun utilisateur Thin Client visible

Vérifier :

• Le serveur RDS a été redémarré après la modification Registry.
• SendSatcEvents est défini et différent de 0.
• SatcDestinationAddr pointe vers la bonne IP du pare-feu.
• SatcDestinationPort correspond au port attendu.
• Le chemin réseau du serveur RDS vers le pare-feu est ouvert pour UDP 6060.
• L’IP du serveur RDS a été enregistrée sur le pare-feu avec system auth thin-client add citrix-ip.
• La zone du serveur RDS est autorisée dans la ligne Clients sous Device Access.

L’utilisateur reste non authentifié en raison d’un conflit de port source

Un proxy ou un logiciel de sécurité sur le serveur RDS peut modifier le port source d’une connexion. Le pare-feu détecte alors une différence de port et traite le trafic comme non authentifié. Il ne faut pas confondre ce port source avec SatcDestinationPort : cette valeur de registre définit le port de destination des messages SATC, soit 6060 par défaut. Tester ce logiciel de manière contrôlée ou le configurer correctement pour le chemin SATC ; ne pas désactiver globalement les fonctions de protection.

L’utilisateur apparaît, mais la règle ne matche pas

Vérifier :

• L’utilisateur ou le groupe est importé sur le pare-feu.
• La règle utilise Match known users.
• Le bon groupe AD est sélectionné dans la règle.
• La position de la règle est correcte.
• Aucune règle précédente ne matche le même trafic sans référence utilisateur.
• Le Log Viewer montre le même utilisateur, la même Source IP et le même service.

Des comptes locaux apparaissent dans les journaux

Vérifier SatcExcludedUsers et ajouter les comptes techniques. Les candidats fréquents sont les administrateurs locaux, les services et les comptes système. La liste ne doit toutefois pas devenir si large que de vrais utilisateurs sont exclus par erreur.

Certaines destinations ne reçoivent aucun contexte utilisateur

Vérifier SatcExcludedAddresses. Si une destination ou un port a été exclu, SATC n’envoie aucune information d’authentification au pare-feu pour cet élément. Cela peut être intentionnel, mais entraîne facilement de la confusion avec des règles utilisateur.

Un ancien Clientless User ne fonctionne plus après l’enregistrement de l’IP serveur

C’est attendu. Si l’IP du serveur RDS a été enregistrée sur le pare-feu comme serveur Thin Client, SATC doit être le modèle d’authentification pour cette IP. Les anciens contournements avec Clientless User doivent être supprimés ou remplacés de manière planifiée.

Aucun accès Internet après une mise à niveau vers SFOS 22.0 GA

Si l’utilisateur apparaît comme Thin client, mais n’a plus accès à Internet depuis la mise à niveau, relever d’abord la version du firmware et la correspondance de règle, puis collecter firewall_rule.log et access_server.log. Les notes de version officielles de SFOS 22.0 répertorient NC-178903 sous SFOS 22.0 MR2 Build 546 comme correction d’un problème affectant les mises à niveau vers SFOS 22.0 GA. Sophos ne fournit ni signature de journal unique ni solution de contournement distincte. Le résumé de SFOS 22.0 MR2 fournit le contexte de la version.

Checklist

• Le scénario RDS correspond réellement à SATC et pas au STAS normal.
• Sophos Server Protection est installé sur le Remote Desktop Session Host.
• La version Windows Server et le rôle RDS sont vérifiés.
• Tamper Protection a été désactivée seulement de manière contrôlée, puis réactivée.
• SendSatcEvents, SatcDestinationAddr et SatcDestinationPort sont définis.
• Le serveur RDS a été redémarré.
• L’IP du serveur RDS a été enregistrée dans la Device Console sur le pare-feu.
• Le serveur AD et les groupes AD sont vérifiés sur le pare-feu.
• Clients est autorisé pour la bonne zone sous Device Access et UDP 6060 est accessible.
• La règle de pare-feu utilise Match known users et a la journalisation active.
• L’utilisateur apparaît sous Current activities > Live users avec Client type Thin client.
• Le Log Viewer montre l’utilisateur attendu et la règle attendue.

FAQ