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.
• Client Authentication est autorisé sous Device Access pour la zone du serveur RDS.
• 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 Central Server Core Agent.
• Plateforme: SATC avec Sophos Server Protection est prévu pour Windows Remote Desktop Services. Sophos mentionne également Citrix XenApp comme scénario pris en charge avec des limitations ; cela se reflète aussi dans le nom du paramètre citrix-ip de la commande CLI.
• 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 Central.

Procédure :

1. Se connecter à Sophos Central.
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 Central.
6. Définir une fenêtre de maintenance pour l’activation de SATC.

Les installateurs visibles dépendent des licences Sophos disponibles. Si Sophos Server Protection fonctionne déjà sur le serveur, il faut tout de même 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

FIREWALL-IP est remplacé par l’adresse IP de Sophos Firewall à laquelle le serveur RDS doit envoyer les informations SATC. Le port standard est 6060.

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.

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.

Formats possibles :

192.0.2.10
192.0.2.10:443
*:443

Les exceptions doivent rester étroites. Si des destinations trop larges sont exclues, le pare-feu verra plus tard moins de contexte utilisateur que prévu.

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

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.

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 Client Authentication depuis la zone serveur, Client Authentication doit être autorisé pour cette zone.

Chemin :

Administration > Device access

Activer la zone du serveur RDS sous Client Authentication. 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 pour le trafic du serveur RDS ou de la zone serveur.
3. Définir correctement Source zone et Destination zone.
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.

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. Contrôler l’adresse IP du serveur RDS et l’association de session.
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.

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.

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.
• 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 autorise Client Authentication 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. Sophos confirme le problème NC-178903 pour les mises à niveau vers SFOS 22.0 GA et le corrige dans SFOS 22.0 MR2 Build 546. 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.
• Client Authentication est autorisé pour la bonne zone sous Device Access.
• 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