Sophos Firewall SATC für Remote Desktop Services einrichten

Sophos Authentication for Thin Client, kurz SATC, hilft bei Benutzerregeln auf Remote Desktop Services. Das ist immer dann wichtig, wenn mehrere Benutzer über denselben Windows Remote Desktop Session Host ins Netzwerk oder ins Internet gehen. Klassisches STAS sieht in solchen Fällen oft nur die IP-Adresse des Terminalservers. SATC liefert der Sophos Firewall dagegen Benutzerinformationen aus den einzelnen RDS-Sitzungen.

Für normale Windows-Clients ist zuerst STAS auf Sophos Firewall einrichten relevant. SATC ist kein Ersatz für STAS in jeder Umgebung, sondern der passende Baustein für Remote Desktop Services.

Einsatz und Planung

Wann SATC sinnvoll ist

SATC passt, wenn Benutzer nicht direkt von ihrem eigenen Client durch die Firewall gehen, sondern Anwendungen oder Browser auf einem Remote Desktop Session Host verwenden.

Typische Szenarien:

• Remote Desktop Services mit mehreren gleichzeitigen Benutzern
• Terminalserver, auf denen Benutzer Webzugriff oder Anwendungszugriff brauchen
• benutzerbasierte Firewallregeln für RDS-Benutzer
• Reporting, bei dem nicht nur die IP-Adresse des RDS-Servers sichtbar sein soll
• Umgebungen, in denen STAS wegen gemeinsam genutzter Quell-IP nicht sauber reicht

SATC ist nicht der richtige Einstieg für normale Domänen-Clients, VPN-Benutzer oder reine Captive-Portal-Szenarien. Dort sollte man zuerst das Authentifizierungsmodell sauber wählen: STAS, Captive Portal, VPN-Authentifizierung, RADIUS oder Microsoft Entra ID SSO.

STAS und SATC sauber trennen

Der wichtigste Unterschied ist die IP-Zuordnung.

• Ein Windows-Client gehört typischerweise zu einem Benutzer: STAS.
• Viele Benutzer teilen dieselbe RDS-Server-IP: SATC.
• Benutzer melden sich im Browser an, damit Regeln greifen: Captive Portal.
• Benutzer kommen über Remote Access VPN: VPN-Authentifizierung oder Entra ID SSO.
• Traffic läuft ohne Benutzerbezug durch technische Server: normale Firewallregeln ohne Benutzer.

Wenn ein Terminalserver fälschlich über STAS oder Clientless User abgebildet wird, entstehen schnell falsche Erwartungen. Eine Regel scheint benutzerbasiert zu sein, tatsächlich sieht die Firewall aber nur eine gemeinsam genutzte Server-IP. SATC löst genau dieses Problem, braucht dafür aber eine eigene Konfiguration auf dem Windows Server und auf der Firewall.

Wenn STAS und SATC gleichzeitig eingesetzt werden, reicht die konzeptionelle Trennung allein nicht aus. Citrix XenApp und Windows Server RDS können bei STAS zu falscher Benutzeridentität für dieselbe Server-IP führen, wenn die IP nicht ausgeschlossen ist. Deshalb müssen die IP-Adressen der Citrix-/RDS-Server in der STAS-Konfiguration unter Login IP Address/Network Subnet mask Exclusion List und Logoff IP Address/Network Subnet mask Exclusion List eingetragen werden. Ohne diesen Ausschluss kann STAS für genau die Server-IPs, die eigentlich SATC nutzen sollen, weiterhin eigene, widersprüchliche Benutzerzuordnungen liefern.

Voraussetzungen

Vor der Einrichtung sollten diese Punkte geklärt sein:

• Sophos Server Protection ist auf dem Remote Desktop Session Host einsetzbar.
• Der Windows Server läuft als Remote Desktop Session Host.
• Windows Server 2016 oder neuer wird verwendet.
• Die Sophos Firewall ist erreichbar.
• Active Directory ist auf der Sophos Firewall angebunden.
• Die benötigten AD-Gruppen sind auf der Firewall importiert.
• Client Authentication ist unter Device Access für die Zone des RDS-Servers erlaubt.
• Firewallregeln können später mit Match known users arbeiten.
• Es gibt ein Wartungsfenster für Registry-Änderung und Neustart des RDS-Servers.

Die AD-Anbindung selbst sollte nicht nebenbei entstehen. Wenn AD noch nicht sauber eingerichtet ist, zuerst Active Directory mit Sophos Firewall verbinden prüfen.

Wichtige Grenzen

SATC hat ein paar Grenzen, die man vor dem Rollout kennen sollte:

• Standalone-SATC: wird von Sophos Firewall nicht mehr unterstützt.
• Bereitstellung: SATC läuft über Sophos Server Protection beziehungsweise den Sophos Central Server Core Agent.
• Plattform: SATC mit Sophos Server Protection ist für Windows Remote Desktop Services gedacht. Sophos nennt daneben auch Citrix XenApp als unterstütztes Szenario mit Einschränkungen; darauf verweist auch der Parametername citrix-ip im CLI-Befehl.
• Serverlimit: Sophos nennt bis zu 192 Thin-Client-Server auf der Firewall.
• Authentifizierung pro Server-IP: Wenn eine RDS-Server-IP auf der Firewall als Thin Client hinterlegt ist, funktioniert für diese IP SATC als Authentifizierungsmethode. Andere Methoden wie Clientless User greifen für diese IP nicht.

Gerade der letzte Punkt ist wichtig. Man sollte nicht testweise produktive Terminalserver-IPs eintragen, ohne das Regelwerk und den Rückweg zu verstehen. Sobald die IP als SATC-Quelle behandelt wird, ändern sich die Erwartungen an Benutzerzuordnung und Regelmatching.

Konfiguration

Ablauf im Überblick

Der technische Ablauf besteht aus fünf Teilen:

1. Sophos Server Protection auf dem RDS-Server installieren.
2. SATC per Registry auf dem RDS-Server aktivieren.
3. RDS-Server-IP in der Device Console der Sophos Firewall hinterlegen.
4. AD-Server, Gruppen und Authentifizierungsreihenfolge auf der Firewall prüfen.
5. Device Access, Firewallregel und Live Users validieren.

SATC sollte nicht nur installiert, sondern auch getestet werden. Erfolgreiche Installation auf dem Server beweist noch nicht, dass die Firewall später den richtigen Benutzer in der richtigen Regel sieht.

Sophos Server Protection installieren

Die Installation erfolgt über Sophos Central.

Vorgehen:

1. In Sophos Central anmelden.
2. Protect Devices öffnen.
3. Unter Server Protection den Windows Server Installer herunterladen.
4. Installer auf dem Remote Desktop Session Host installieren.
5. Prüfen, ob der Server in Sophos Central sauber erscheint.
6. Wartungsfenster für die SATC-Aktivierung festlegen.

Welche Installer sichtbar sind, hängt von den vorhandenen Sophos-Lizenzen ab. Wenn auf dem Server bereits Sophos Server Protection läuft, sollte man trotzdem prüfen, ob der Agent aktuell ist und ob Tamper Protection kontrolliert deaktiviert und danach wieder aktiviert werden kann.

SATC per Registry aktivieren

SATC wird auf dem RDS-Server über Registry-Werte unter diesem Pfad gesteuert:

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

Vor der Änderung zeigt dieser Read-only-Befehl, welche SATC-Werte bereits vorhanden sind:

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

Achtung: Registry-Änderungen und der anschliessende Neustart beeinflussen alle aktiven RDS-Sitzungen. Aktuelle Werte dokumentieren, ein Wartungsfenster nutzen und Tamper Protection nur kontrolliert deaktivieren. Nach der Änderung muss sie wieder aktiviert werden.

Die Grundkonfiguration kann in einer administrativen Eingabeaufforderung gesetzt werden:

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 wird durch die IP-Adresse der Sophos Firewall ersetzt, an welche der RDS-Server die SATC-Informationen senden soll. Der Standardport ist 6060.

Danach:

1. Tamper Protection wieder aktivieren.
2. RDS-Server neu starten.
3. Nach dem Neustart prüfen, ob der Sophos-Dienst läuft.
4. Den Read-only-Befehl reg query erneut ausführen und die gesetzten Werte kontrollieren.
5. Danach erst mit Firewall-Konfiguration und Tests fortfahren.

Lokale Konten und Ziele ausschliessen

Standardmässig können auch lokale Konten wie SYSTEM oder Administrator SATC-Ereignisse erzeugen. Das ist für Benutzerregeln meist nicht hilfreich und kann Logs unnötig verunreinigen.

Mit SatcExcludedUsers lassen sich Benutzer ausschliessen. Die Einträge sind case-sensitive.

Beispiel:

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

Mit SatcExcludedAddresses lassen sich Ziele ausschliessen, für die keine SATC-Informationen an die Firewall gesendet werden sollen. Das kann für lokale Management-, Update- oder Infrastrukturziele sinnvoll sein, sollte aber bewusst dokumentiert werden.

Mögliche Formate:

192.0.2.10
192.0.2.10:443
*:443

Ausnahmen sollten eng gehalten werden. Wenn zu breite Ziele ausgeschlossen werden, sieht die Firewall später weniger Benutzerkontext als erwartet.

Bei spürbarer Netzwerklatenz zwischen RDS-Server und Firewall kann zusätzlich SatcPendDurationMs gesetzt werden. Der Wert bestimmt, wie lange ausgehende IPv4-TCP-Verbindungen zurückgehalten werden, damit die Benutzerzuordnung rechtzeitig vorliegt. Fehlt der Registry-Wert, verwendet SATC 100 Millisekunden; 0 deaktiviert nur diesen Verbindungsaufschub, nicht SATC. Den Wert nur bei tatsächlichen Latenzproblemen anpassen, nicht vorsorglich.

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

Wie bei den anderen Registry-Änderungen ist danach ein Neustart des RDS-Servers nötig.

RDS-Server auf der Firewall eintragen

Die Firewall muss wissen, welche Server SATC-Informationen liefern. Das erfolgt in der Device Console, nicht in der Advanced Shell.

Vorgehen:

1. An der Sophos Firewall per Konsole oder SSH anmelden.
2. Option 4. Device Console öffnen.
3. Vorhandene Einträge anzeigen:

system auth thin-client show

4. RDS-Server-IP nur hinzufügen, wenn sie noch nicht aufgeführt ist:

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

<RDS-SERVER-IP> wird durch die IP-Adresse des Remote Desktop Session Hosts ersetzt.

Wenn mehrere RDS-Server vorhanden sind, jeden Server einzeln und dokumentiert eintragen. Danach sollte klar sein:

• welche Server als SATC-Quellen gelten
• welche Zone diese Server verwenden
• welche Firewallregeln Benutzer dieser Server auswerten
• wer Änderungen an der RDS-Serverliste freigibt

Wenn eine falsche IP eingetragen wurde, die Liste erneut kontrollieren und sie dann gezielt entfernen:

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

Der Befehl entfernt nur den Thin-Client-Eintrag auf der Firewall; Registry-Werte und Sophos Server Protection auf dem RDS-Server bleiben bestehen. Bei einer produktiven IP fällt damit die SATC-Zuordnung weg, sodass benutzerbasierte Regeln nicht mehr matchen können. Sophos dokumentiert nicht, wie bereits bestehende Sitzungen reagieren. Deshalb nur im Wartungsfenster und mit vorbereitetem Rückweg löschen.

Active Directory und Gruppen prüfen

SATC liefert Benutzerinformationen. Damit die Firewall diese Informationen in Regeln verwenden kann, müssen AD-Anbindung und Gruppen stimmen.

Prüfen:

1. Authentication > Servers öffnen.
2. AD-Server mit Test connection prüfen.
3. Gruppenimport kontrollieren.
4. Authentication > Groups öffnen.
5. Relevante Gruppen suchen.
6. Authentication > Services öffnen.
7. AD-Server in der richtigen Reihenfolge der Firewall authentication methods prüfen.

Wenn Benutzer im Live-User-Bereich auftauchen, aber Regeln nicht greifen, liegt die Ursache häufig nicht in SATC selbst, sondern in Gruppenimport, Standardgruppe, Regelkriterium oder Regelposition.

Device Access und Firewallregel setzen

Damit die Firewall Client Authentication aus der Serverzone annimmt, muss Client Authentication für diese Zone erlaubt sein.

Pfad:

Administration > Device access

Unter Client Authentication die Zone des RDS-Servers aktivieren. Dabei sollte nicht blind WAN oder eine breite unsichere Zone geöffnet werden. Device Access steuert lokale Dienste der Firewall und gehört zur Management-Härtung.

Danach braucht der eigentliche Traffic eine Firewallregel.

Typischer Ablauf:

1. Rules and policies > Firewall rules öffnen.
2. Passende Regel für Traffic vom RDS-Server oder aus der Serverzone erstellen.
3. Source zone und Destination zone passend setzen.
4. Match known users aktivieren.
5. Benötigte AD-Benutzer oder AD-Gruppen auswählen.
6. Logging aktivieren, damit der Test später nachvollziehbar ist.
7. Regel speichern.
8. Testtraffic von einer RDS-Sitzung erzeugen.

Für die spätere Fehlersuche ist Logging wichtig. Wenn eine Benutzerregel ohne Logging erstellt wird, ist schwerer zu erkennen, ob SATC, Gruppenmatching, Regelreihenfolge oder ein anderer Pfad das Problem ist.

Validierung und Betrieb

Validierung nach der Einrichtung

Nach der Konfiguration sollte man nicht nur prüfen, ob ein Benutzer Internetzugriff hat. Entscheidend ist, ob die Firewall den richtigen Benutzer sieht und die richtige Regel matcht.

Praktischer Test:

1. Benutzer an einer RDS-Sitzung anmelden.
2. Definierten Testtraffic erzeugen, zum Beispiel eine erlaubte HTTPS-Verbindung.
3. In der Sophos Firewall Current activities > Live users öffnen.
4. Prüfen, ob der Benutzer mit Client type Thin client erscheint.
5. IP-Adresse des RDS-Servers und Session-Zuordnung kontrollieren.
6. Log Viewer öffnen.
7. Nach Source IP des RDS-Servers, Benutzer und Regel filtern.
8. Prüfen, ob die erwartete benutzerbasierte Regel greift.

Für eine tiefere Analyse in der Advanced Shell sind firewall_rule.log für den Regelmatch und access_server.log für Authentifizierung und Autorisierung relevant. Der Log Viewer bleibt der schnellere erste Prüfweg.

Wenn Traffic nicht wie erwartet läuft, hilft zusätzlich Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Wenn zwar Benutzer sichtbar sind, aber Gruppen oder einzelne Benutzer nicht matchen, passt Sophos Firewall Regel matcht nicht als nächster Prüfpfad.

Betrieb und Dokumentation

SATC sollte wie ein produktiver Authentifizierungsbaustein betrieben werden, nicht wie ein einmaliger Registry-Hack.

Dokumentieren:

• RDS-Server und IP-Adressen
• verwendete Firewall-IP und SATC-Port
• gesetzte Registry-Werte
• ausgeschlossene Benutzer und Ziele
• betroffene Firewallregeln
• AD-Gruppen und Owner
• Testbenutzer und erwarteter Regelmatch
• Wartungsfenster und Neustartzeitpunkt

Nach Updates von Sophos Server Protection, Windows Server, Sophos Firewall oder AD sollte man SATC gezielt mit einem Testbenutzer prüfen. Authentifizierung ist oft erst dann auffällig, wenn Benutzerregeln plötzlich zu breit oder gar nicht mehr greifen.

Troubleshooting

Kein Thin-Client-Benutzer sichtbar

Prüfen:

• RDS-Server wurde nach Registry-Änderung neu gestartet.
• SendSatcEvents ist gesetzt und ungleich 0.
• SatcDestinationAddr zeigt auf die richtige Firewall-IP.
• SatcDestinationPort passt zum erwarteten Port.
• Netzwerkpfad vom RDS-Server zur Firewall ist offen.
• RDS-Server-IP wurde per system auth thin-client add citrix-ip auf der Firewall hinterlegt.
• Zone des RDS-Servers erlaubt Client Authentication unter Device Access.

Benutzer bleibt wegen eines Quellport-Konflikts unauthentifiziert

Proxy- oder Security-Software auf dem RDS-Server kann den Source Port verändern. Dadurch erkennt die Firewall einen Port-Mismatch und behandelt den Traffic als unauthentifiziert. Diesen Source Port nicht mit SatcDestinationPort verwechseln: Der Registry-Wert legt den Zielport für SATC-Nachrichten fest, standardmässig 6060. Solche Software kontrolliert testen oder für den SATC-Pfad passend konfigurieren; Schutzfunktionen nicht pauschal deaktivieren.

Benutzer erscheint, aber Regel matcht nicht

Prüfen:

• Benutzer oder Gruppe ist auf der Firewall importiert.
• Regel verwendet Match known users.
• Richtige AD-Gruppe ist in der Regel ausgewählt.
• Regelposition passt.
• Es gibt keine frühere Regel, die denselben Traffic ohne Benutzerbezug matcht.
• Log Viewer zeigt denselben Benutzer, dieselbe Source IP und denselben Dienst.

Lokale Konten tauchen in Logs auf

SatcExcludedUsers prüfen und technische Konten ergänzen. Häufige Kandidaten sind lokale Administratoren, Dienste und Systemkonten. Die Liste sollte aber nicht so breit werden, dass echte Benutzer versehentlich ausgeschlossen werden.

Einzelne Ziele bekommen keinen Benutzerkontext

SatcExcludedAddresses prüfen. Wenn ein Ziel oder Port ausgeschlossen wurde, sendet SATC dafür keine Authentifizierungsinformationen an die Firewall. Das kann beabsichtigt sein, führt aber bei Benutzerregeln leicht zu Verwirrung.

Nach dem Eintrag der Server-IP greift ein alter Clientless User nicht mehr

Das ist erwartbar. Wenn die RDS-Server-IP als Thin-Client-Server hinterlegt wurde, sollte SATC für diese IP das Authentifizierungsmodell sein. Alte Workarounds mit Clientless Usern sollten entfernt oder bewusst ersetzt werden.

Kein Internetzugriff nach einem Upgrade auf SFOS 22.0 GA

Wenn der Benutzer als Thin client erscheint, aber seit dem Upgrade keinen Internetzugriff hat, zuerst Firmwarestand, Regelmatch und firewall_rule.log sowie access_server.log sichern. Sophos bestätigt den Fehler NC-178903 für Upgrades auf SFOS 22.0 GA und behebt ihn mit SFOS 22.0 MR2 Build 546. Eine eindeutige Logsignatur oder einen separaten Workaround nennt Sophos nicht. Die Einordnung zum Release steht im Überblick zu SFOS 22.0 MR2.

Checkliste

• RDS-Szenario passt wirklich zu SATC und nicht zu normalem STAS.
• Sophos Server Protection ist auf dem Remote Desktop Session Host installiert.
• Windows Server Version und RDS-Rolle sind geprüft.
• Tamper Protection wurde nur kontrolliert deaktiviert und danach wieder aktiviert.
• SendSatcEvents, SatcDestinationAddr und SatcDestinationPort sind gesetzt.
• RDS-Server wurde neu gestartet.
• RDS-Server-IP wurde in der Device Console auf der Firewall hinterlegt.
• AD-Server und AD-Gruppen sind auf der Firewall geprüft.
• Client Authentication ist für die richtige Zone unter Device Access erlaubt.
• Firewallregel verwendet Match known users und hat Logging aktiv.
• Benutzer erscheint unter Current activities > Live users mit Client type Thin client.
• Log Viewer zeigt den erwarteten Benutzer und die erwartete Regel.

FAQ