Konfigurera Sophos Firewall SATC för Remote Desktop Services

Sophos Authentication for Thin Client, kort SATC, hjälper till med användarregler på Remote Desktop Services. Det är viktigt när flera användare går ut i nätverket eller på internet via samma Windows Remote Desktop Session Host. Klassisk STAS ser i sådana fall ofta bara terminalserverns IP-adress. SATC levererar däremot användarinformation från de enskilda RDS-sessionerna till Sophos Firewall.

För vanliga Windows-klienter bör man först konfigurera STAS på Sophos Firewall. SATC är inte en ersättning för STAS i varje miljö, utan rätt byggsten för Remote Desktop Services.

Användning och planering

När SATC är meningsfullt

SATC passar när användare inte går direkt genom brandväggen från sin egen klient, utan använder applikationer eller webbläsare på en Remote Desktop Session Host.

Typiska scenarier:

• Remote Desktop Services med flera samtidiga användare
• terminalservrar där användare behöver webbåtkomst eller applikationsåtkomst
• användarbaserade firewallregler för RDS-användare
• rapportering där inte bara RDS-serverns IP-adress ska synas
• miljöer där STAS inte räcker till eftersom flera användare delar samma käll-IP

SATC är inte rätt startpunkt för vanliga domänklienter, VPN-användare eller rena Captive-Portal-scenarier. Där bör man först välja rätt autentiseringsmodell: STAS, Captive Portal, VPN-autentisering, RADIUS eller Microsoft Entra ID SSO.

Skilj tydligt på STAS och SATC

Den viktigaste skillnaden är IP-tilldelningen.

• En Windows-klient hör vanligtvis till en användare: STAS.
• Många användare delar samma RDS-server-IP: SATC.
• Användare loggar in i webbläsaren så att regler träffar: Captive Portal.
• Användare kommer via Remote Access VPN: VPN-autentisering eller Entra ID SSO.
• Trafik går genom tekniska servrar utan användarkoppling: normala firewallregler utan användare.

Om en terminalserver felaktigt avbildas via STAS eller Clientless User uppstår snabbt fel förväntningar. En regel verkar vara användarbaserad, men i praktiken ser brandväggen bara en delad server-IP. SATC löser just detta problem, men kräver en egen konfiguration på Windows Server och på brandväggen.

Om STAS och SATC används samtidigt räcker inte den begreppsmässiga uppdelningen ensam. Citrix XenApp och Windows Server RDS kan göra att STAS returnerar fel användaridentitet för samma server-IP om den inte är undantagen. Därför måste IP-adresserna för Citrix-/RDS-servrarna läggas in i STAS-konfigurationen under Login IP Address/Network Subnet mask Exclusion List och Logoff IP Address/Network Subnet mask Exclusion List. Utan detta undantag kan STAS fortsätta leverera sin egen, motstridiga användarkoppling för just de server-IP:er som ska använda SATC.

Förutsättningar

Före konfigurationen bör dessa punkter vara klara:

• Sophos Server Protection kan användas på Remote Desktop Session Host.
• Windows Server körs som Remote Desktop Session Host.
• Windows Server 2016 eller senare används.
• Sophos Firewall är nåbar.
• Active Directory är anslutet till Sophos Firewall.
• Nödvändiga AD-grupper är importerade på brandväggen.
• Client Authentication är tillåtet under Device Access för RDS-serverns zon.
• Firewallregler kan senare arbeta med Match known users.
• Det finns ett underhållsfönster för registry-ändring och omstart av RDS-servern.

AD-anslutningen bör vara korrekt konfigurerad innan SATC sätts upp. Om AD ännu inte är klart bör man först kontrollera anslut Active Directory till Sophos Firewall.

Viktiga gränser

SATC har några gränser som man bör känna till före rollout:

• Standalone-SATC: Stöds inte längre av Sophos Firewall.
• Driftsättning: SATC körs via Sophos Server Protection respektive Sophos Central Server Core Agent.
• Plattform: SATC med Sophos Server Protection är avsett för Windows Remote Desktop Services. Sophos nämner även Citrix XenApp som ett scenario som stöds med begränsningar; det syns även i parameternamnet citrix-ip i CLI-kommandot.
• Servergräns: Sophos anger upp till 192 Thin-Client-servrar på brandväggen.
• Autentisering per server-IP: Om en RDS-server-IP är registrerad som Thin Client på brandväggen fungerar SATC som autentiseringsmetod för denna IP. Andra metoder som Clientless User gäller inte för denna IP.

Särskilt den sista punkten är viktig. Man bör inte testa med produktiva terminalserver-IP-adresser utan att förstå regelverket och returvägen. Så snart IP-adressen behandlas som SATC-källa ändras förväntningarna på användartilldelning och regelmatchning.

Konfiguration

Förlopp i översikt

Det tekniska förloppet består av fem delar:

1. Installera Sophos Server Protection på RDS-servern.
2. Aktivera SATC via registry på RDS-servern.
3. Registrera RDS-serverns IP i Device Console på Sophos Firewall.
4. Kontrollera AD-servrar, grupper och autentiseringsordning på brandväggen.
5. Validera Device Access, firewallregel och Live Users.

SATC bör inte bara installeras utan också testas. En lyckad installation på servern bevisar ännu inte att brandväggen senare ser rätt användare i rätt regel.

Installera Sophos Server Protection

Installationen görs via Sophos Central.

Förfarande:

1. Logga in i Sophos Central.
2. Öppna Protect Devices.
3. Ladda ned Windows Server Installer under Server Protection.
4. Installera installationsprogrammet på Remote Desktop Session Host.
5. Kontrollera att servern visas korrekt i Sophos Central.
6. Fastställ underhållsfönster för SATC-aktiveringen.

Vilka installationsprogram som visas beror på befintliga Sophos-licenser. Om Sophos Server Protection redan körs på servern bör man ändå kontrollera om agenten är aktuell och om Tamper Protection kan deaktiveras kontrollerat och därefter aktiveras igen.

Aktivera SATC via registry

SATC styrs på RDS-servern via registry-värden under denna sökväg:

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

Före ändringen visar detta kommando, som inte ändrar något, vilka SATC-värden som redan finns:

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

Varning: Registry-ändringar och den efterföljande omstarten påverkar alla aktiva RDS-sessioner. Dokumentera de aktuella värdena, använd ett underhållsfönster och deaktivera Tamper Protection endast kontrollerat. Aktivera det igen efter ändringen.

Grundkonfigurationen kan sättas i en administrativ kommandoprompt:

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 ersätts med IP-adressen till den Sophos Firewall som RDS-servern ska skicka SATC-informationen till. Standardporten är 6060.

Därefter:

1. Aktivera Tamper Protection igen.
2. Starta om RDS-servern.
3. Kontrollera efter omstarten att Sophos-tjänsten körs.
4. Kör reg query igen och kontrollera de inställda värdena.
5. Fortsätt först därefter med firewallkonfiguration och tester.

Exkludera lokala konton och mål

Som standard kan även lokala konton som SYSTEM eller Administrator skapa SATC-händelser. Det är oftast inte hjälpsamt för användarregler och kan smutsa ned loggar i onödan.

Med SatcExcludedUsers kan användare exkluderas. Posterna är skiftlägeskänsliga.

Exempel:

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

Med SatcExcludedAddresses kan mål exkluderas där ingen SATC-information ska skickas till brandväggen. Det kan vara meningsfullt för lokala management-, uppdaterings- eller infrastrukturmål, men bör dokumenteras medvetet.

Möjliga format:

192.0.2.10
192.0.2.10:443
*:443

Undantag bör hållas snäva. Om för breda mål exkluderas ser brandväggen senare mindre användarkontext än väntat.

Vid märkbar nätverkslatens mellan RDS-servern och brandväggen kan även SatcPendDurationMs ställas in. Värdet anger hur länge utgående IPv4-TCP-anslutningar hålls tillbaka så att användartilldelningen hinner bli tillgänglig. Om registry-värdet saknas använder SATC 100 millisekunder; 0 deaktiverar endast denna anslutningsfördröjning, inte SATC. Ändra värdet endast vid faktiska latensproblem, inte i förebyggande syfte.

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

Precis som vid övriga registerändringar krävs sedan en omstart av RDS-servern.

Registrera RDS-servern på brandväggen

Brandväggen måste veta vilka servrar som levererar SATC-information. Det görs i Device Console, inte i Advanced Shell.

Förfarande:

1. Logga in på Sophos Firewall via konsol eller SSH.
2. Öppna alternativ 4. Device Console.
3. Visa befintliga poster:

system auth thin-client show

4. Lägg till RDS-serverns IP endast om den inte redan finns i listan:

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

<RDS-SERVER-IP> ersätts med IP-adressen till Remote Desktop Session Host.

Om det finns flera RDS-servrar registreras varje server separat och dokumenterat. Därefter bör det vara tydligt:

• vilka servrar som räknas som SATC-källor
• vilken zon dessa servrar använder
• vilka firewallregler som utvärderar användare från dessa servrar
• vem som godkänner ändringar i RDS-serverlistan

Om en felaktig IP-adress har lagts till ska listan kontrolleras igen och adressen sedan tas bort på ett kontrollerat sätt:

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

Kommandot tar endast bort Thin-Client-posten på brandväggen; registry-värden och Sophos Server Protection på RDS-servern finns kvar. För en produktions-IP försvinner därmed SATC-tilldelningen, så användarbaserade regler kanske inte längre matchar. Sophos dokumenterar inte hur befintliga sessioner reagerar. Ta därför endast bort posten under ett underhållsfönster och med en förberedd återställningsplan.

Kontrollera Active Directory och grupper

SATC levererar användarinformation. För att brandväggen ska kunna använda informationen i regler måste AD-anslutning och grupper stämma.

Kontrollera:

1. Öppna Authentication > Servers.
2. Kontrollera AD-servern med Test connection.
3. Kontrollera gruppimporten.
4. Öppna Authentication > Groups.
5. Sök efter relevanta grupper.
6. Öppna Authentication > Services.
7. Kontrollera AD-servern i rätt ordning för Firewall authentication methods.

Om användare visas i Live-User-området men regler inte träffar ligger orsaken ofta inte i SATC själv, utan i gruppimport, standardgrupp, regelkriterium eller regelposition.

Sätt Device Access och firewallregel

För att brandväggen ska acceptera Client Authentication från serverzonen måste Client Authentication vara tillåtet för denna zon.

Sökväg:

Administration > Device access

Aktivera RDS-serverns zon under Client Authentication. Man bör inte blint öppna WAN eller en bred osäker zon. Device Access styr brandväggens lokala tjänster och hör till management-härdningen.

Därefter behöver den faktiska trafiken en firewallregel.

Typiskt förfarande:

1. Öppna Rules and policies > Firewall rules.
2. Skapa passande regel för trafik från RDS-servern eller serverzonen.
3. Sätt Source zone och Destination zone korrekt.
4. Aktivera Match known users.
5. Välj nödvändiga AD-användare eller AD-grupper.
6. Aktivera logging så att testet senare är spårbart.
7. Spara regeln.
8. Skapa testtrafik från en RDS-session.

Logging är viktigt för senare felsökning. Om en användarregel skapas utan logging är det svårare att se om SATC, gruppmatchning, regelordning eller en annan väg är problemet.

Validering och drift

Validering efter konfigurationen

Efter konfigurationen bör man inte bara kontrollera om en användare har internetåtkomst. Avgörande är om brandväggen ser rätt användare och matchar rätt regel.

Praktiskt test:

1. Logga in en användare i en RDS-session.
2. Skapa definierad testtrafik, till exempel en tillåten HTTPS-anslutning.
3. Öppna Current activities > Live users i Sophos Firewall.
4. Kontrollera om användaren visas med Client type Thin client.
5. Kontrollera RDS-serverns IP-adress och sessionstilldelning.
6. Öppna Log Viewer.
7. Filtrera efter RDS-serverns Source IP, användare och regel.
8. Kontrollera om den förväntade användarbaserade regeln träffar.

För djupare analys i Advanced Shell är firewall_rule.log relevant för regelmatchning och access_server.log för autentisering och auktorisering. Log Viewer är fortfarande den snabbaste första kontrollen.

Om trafiken inte fungerar som väntat hjälper även testa firewallregel med Log Viewer, Policy Test och Packet Capture. Om användare syns men grupper eller enskilda användare inte matchar passar Sophos Firewall-regel matchar inte som nästa kontrollväg.

Drift och dokumentation

SATC bör drivas som en produktiv autentiseringsbyggsten, inte som ett engångs-registry-hack.

Dokumentera:

• RDS-servrar och IP-adresser
• använd firewall-IP och SATC-port
• satta registry-värden
• exkluderade användare och mål
• berörda firewallregler
• AD-grupper och ansvarig
• testanvändare och förväntad regelmatchning
• underhållsfönster och omstartstidpunkt

Efter uppdateringar av Sophos Server Protection, Windows Server, Sophos Firewall eller AD bör man testa SATC riktat med en testanvändare. Autentiseringsproblem märks ofta först när användarregler plötsligt blir för breda eller inte träffar alls.

Troubleshooting

Ingen Thin-Client-användare synlig

Kontrollera:

• RDS-servern startades om efter registry-ändringen.
• SendSatcEvents är satt och inte 0.
• SatcDestinationAddr pekar på rätt firewall-IP.
• SatcDestinationPort passar till den förväntade porten.
• Nätverksvägen från RDS-servern till brandväggen är öppen.
• RDS-serverns IP registrerades på brandväggen med system auth thin-client add citrix-ip.
• RDS-serverns zon tillåter Client Authentication under Device Access.

Användaren förblir oautentiserad på grund av en källportskonflikt

Proxy- eller säkerhetsprogram på RDS-servern kan ändra en anslutnings källport. Brandväggen upptäcker då en portavvikelse och behandlar trafiken som oautentiserad. Förväxla inte denna källport med SatcDestinationPort: registry-värdet anger målporten för SATC-meddelanden, som är 6060 som standard. Testa sådan programvara kontrollerat eller konfigurera den för SATC-sökvägen; deaktivera inte skyddsfunktioner generellt.

Användare visas, men regeln matchar inte

Kontrollera:

• användare eller grupp är importerad på brandväggen.
• regeln använder Match known users.
• rätt AD-grupp är vald i regeln.
• regelpositionen passar.
• det finns ingen tidigare regel som matchar samma trafik utan användarkoppling.
• Log Viewer visar samma användare, samma Source IP och samma tjänst.

Lokala konton dyker upp i loggar

Kontrollera SatcExcludedUsers och komplettera tekniska konton. Vanliga kandidater är lokala administratörer, tjänster och systemkonton. Listan bör dock inte bli så bred att riktiga användare oavsiktligt exkluderas.

Enskilda mål får ingen användarkontext

Kontrollera SatcExcludedAddresses. Om ett mål eller en port har exkluderats skickar SATC ingen autentiseringsinformation till brandväggen för detta. Det kan vara avsiktligt, men leder lätt till förvirring vid användarregler.

Efter registrering av server-IP fungerar en gammal Clientless User inte längre

Det är väntat. Om RDS-serverns IP har registrerats som Thin-Client-server bör SATC vara autentiseringsmodellen för denna IP. Gamla workarounds med Clientless Users bör tas bort eller ersättas på ett planerat sätt.

Ingen internetåtkomst efter uppgradering till SFOS 22.0 GA

Om användaren visas som Thin client men saknar internetåtkomst sedan uppgraderingen ska man först dokumentera firmwareversionen och regelmatchningen samt samla in firewall_rule.log och access_server.log. Sophos bekräftar problemet NC-178903 för uppgraderingar till SFOS 22.0 GA och åtgärdar det i SFOS 22.0 MR2 Build 546. Sophos anger ingen unik loggsignatur eller separat workaround. Översikten över SFOS 22.0 MR2 ger sammanhang för versionen.

Checklista

• RDS-scenariot passar verkligen SATC och inte normal STAS.
• Sophos Server Protection är installerat på Remote Desktop Session Host.
• Windows Server-version och RDS-roll är kontrollerade.
• Tamper Protection deaktiverades bara kontrollerat och aktiverades därefter igen.
• SendSatcEvents, SatcDestinationAddr och SatcDestinationPort är satta.
• RDS-servern har startats om.
• RDS-serverns IP registrerades i Device Console på brandväggen.
• AD-server och AD-grupper är kontrollerade på brandväggen.
• Client Authentication är tillåtet för rätt zon under Device Access.
• Firewallregeln använder Match known users och har logging aktiv.
• Användaren visas under Current activities > Live users med Client type Thin client.
• Log Viewer visar den förväntade användaren och den förväntade regeln.

FAQ