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.

Der Artikel erklärt, wann SATC sinnvoll ist, welche Grenzen gelten, wie man SATC über Sophos Server Protection aktiviert und wie man danach prüft, ob die Benutzer in der Sophos Firewall korrekt auftauchen.

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.

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.

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.

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:

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.

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 sollte man die aktuellen Einstellungen dokumentieren. Wenn Tamper Protection auf dem Server aktiv ist, muss sie für die Änderung kontrolliert deaktiviert und danach 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. 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.

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. RDS-Server-IP hinzufügen:

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

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

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.

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

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.

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