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.

Cet article explique quand SATC est pertinent, quelles limites s’appliquent, comment l’activer via Sophos Server Protection et comment vérifier ensuite si les utilisateurs apparaissent correctement dans Sophos Firewall.

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

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 proprement le modèle d’authentification : STAS, Captive Portal, authentification VPN, RADIUS ou Microsoft Entra ID SSO.

Bien séparer STAS et SATC

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

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.

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 elle-même ne doit pas être mise en place au passage. Si AD n’est pas encore configuré proprement, vérifiez d’abord Connecter Active Directory à Sophos Firewall.

Limites importantes

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

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.

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. Installer l’installer 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, il faut documenter les paramètres actuels. Si Tamper Protection est active sur le serveur, elle doit être désactivée de manière contrôlée pour la modification, puis réactivée ensuite.

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. 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 case-sensitive.

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.

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. Ajouter l’IP du serveur RDS :

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

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 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.

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é.

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 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 consciemment.

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 owner
• 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. L’authentification devient souvent visible seulement lorsque des règles utilisateur deviennent soudainement trop larges ou ne s’appliquent plus du tout.

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