Sophos Firewall SATC voor Remote Desktop Services instellen

Sophos Authentication for Thin Client, kort SATC, helpt bij gebruikersregels op Remote Desktop Services. Dat is belangrijk wanneer meerdere gebruikers via dezelfde Windows Remote Desktop Session Host naar het netwerk of internet gaan. Klassieke STAS ziet in zulke gevallen vaak alleen het IP-adres van de terminalserver. SATC levert de Sophos Firewall daarentegen gebruikersinformatie uit de afzonderlijke RDS-sessies.

Voor normale Windows-clients is STAS op Sophos Firewall instellen de eerste stap. SATC is geen vervanging voor STAS in elke omgeving, maar de passende bouwsteen voor Remote Desktop Services.

Inzet en planning

Wanneer SATC zinvol is

SATC past wanneer gebruikers niet direct vanaf hun eigen client door de firewall gaan, maar applicaties of browsers op een Remote Desktop Session Host gebruiken.

Typische scenario’s:

• Remote Desktop Services met meerdere gelijktijdige gebruikers
• terminalservers waarop gebruikers webtoegang of applicatietoegang nodig hebben
• gebruikersgebaseerde firewallregels voor RDS-gebruikers
• reporting waarbij niet alleen het IP-adres van de RDS-server zichtbaar moet zijn
• omgevingen waarin STAS niet volstaat omdat gebruikers een source-IP delen

SATC is niet de juiste instap voor normale domein-clients, VPN-gebruikers of pure Captive-Portal-scenario’s. Daar moet men eerst het juiste authenticatiemodel kiezen: STAS, Captive Portal, VPN-authenticatie, RADIUS of Microsoft Entra ID SSO.

STAS en SATC netjes scheiden

Het belangrijkste verschil is de IP-toewijzing.

• Een Windows-client hoort normaal bij een gebruiker: STAS.
• Veel gebruikers delen hetzelfde RDS-server-IP: SATC.
• Gebruikers melden zich in de browser aan zodat regels werken: Captive Portal.
• Gebruikers komen via Remote Access VPN: VPN-authenticatie of Entra ID SSO.
• Traffic loopt zonder gebruikersrelatie via technische servers: normale firewallregels zonder gebruiker.

Wanneer een terminalserver ten onrechte via STAS of Clientless User wordt afgebeeld, ontstaan snel verkeerde verwachtingen. Een regel lijkt gebruikersgebaseerd te zijn, maar in werkelijkheid ziet de firewall alleen een gedeeld server-IP. SATC lost precies dit probleem op, maar heeft daarvoor een eigen configuratie op de Windows Server en op de firewall nodig.

Als STAS en SATC tegelijk worden gebruikt, is de conceptuele scheiding alleen niet genoeg. Citrix XenApp en Windows Server RDS kunnen ertoe leiden dat STAS een onjuiste gebruikersidentiteit teruggeeft voor hetzelfde server-IP als dit niet is uitgesloten. Daarom moeten de IP-adressen van de Citrix-/RDS-servers in de STAS-configuratie worden opgenomen onder Login IP Address/Network Subnet mask Exclusion List en Logoff IP Address/Network Subnet mask Exclusion List. Zonder deze uitsluiting kan STAS voor precies de server-IP’s die SATC zouden moeten gebruiken, een eigen, tegenstrijdige gebruikerstoewijzing blijven leveren.

Vereisten

Voor de inrichting moeten deze punten duidelijk zijn:

• Sophos Server Protection kan op de Remote Desktop Session Host worden ingezet.
• De Windows Server draait als Remote Desktop Session Host.
• Windows Server 2016 of nieuwer wordt gebruikt.
• De Sophos Firewall is bereikbaar.
• Active Directory is op de Sophos Firewall gekoppeld.
• De benodigde AD-groepen zijn op de firewall geïmporteerd.
• Client Authentication is onder Device Access voor de zone van de RDS-server toegestaan.
• Firewallregels kunnen later met Match known users werken.
• Er is een onderhoudsvenster voor registry-wijziging en herstart van de RDS-server.

De AD-koppeling moet correct zijn ingericht voordat men SATC configureert. Wanneer AD nog niet gereed is, eerst Active Directory met Sophos Firewall verbinden controleren.

Belangrijke grenzen

SATC heeft enkele grenzen die men voor de rollout moet kennen:

• Standalone-SATC: Wordt door Sophos Firewall niet meer ondersteund.
• Uitrol: SATC draait via Sophos Server Protection respectievelijk de Sophos Central Server Core Agent.
• Platform: SATC met Sophos Server Protection is bedoeld voor Windows Remote Desktop Services. Sophos noemt daarnaast ook Citrix XenApp als ondersteund scenario met beperkingen; dat is ook te zien aan de parameternaam citrix-ip in het CLI-commando.
• Serverlimiet: Sophos noemt tot 192 Thin-Client-servers op de firewall.
• Authenticatie per server-IP: Wanneer een RDS-server-IP op de firewall als Thin Client is geregistreerd, werkt voor dit IP SATC als authenticatiemethode. Andere methoden zoals Clientless User gelden voor dit IP niet.

Vooral het laatste punt is belangrijk. Men moet niet zomaar productieve terminalserver-IP’s voor een test invoeren zonder het regelwerk en het retourpad te begrijpen. Zodra het IP als SATC-bron wordt behandeld, veranderen de verwachtingen aan gebruikerstoewijzing en regelmatching.

Configuratie

Werkwijze in overzicht

De technische werkwijze bestaat uit vijf delen:

1. Sophos Server Protection op de RDS-server installeren.
2. SATC per registry op de RDS-server activeren.
3. RDS-server-IP in de Device Console van de Sophos Firewall registreren.
4. AD-server, groepen en authenticatievolgorde op de firewall controleren.
5. Device Access, firewallregel en Live Users valideren.

SATC moet niet alleen worden geïnstalleerd, maar ook getest. Een succesvolle installatie op de server bewijst nog niet dat de firewall later de juiste gebruiker in de juiste regel ziet.

Sophos Server Protection installeren

De installatie gebeurt via Sophos Central.

Werkwijze:

1. Aanmelden bij Sophos Central.
2. Protect Devices openen.
3. Onder Server Protection de Windows Server Installer downloaden.
4. Installer op de Remote Desktop Session Host installeren.
5. Controleren of de server netjes in Sophos Central verschijnt.
6. Onderhoudsvenster voor de SATC-activering vastleggen.

Welke installers zichtbaar zijn, hangt af van de aanwezige Sophos-licenties. Wanneer op de server al Sophos Server Protection draait, moet men toch controleren of de agent actueel is en of Tamper Protection gecontroleerd kan worden gedeactiveerd en daarna weer geactiveerd.

SATC per registry activeren

SATC wordt op de RDS-server via registry-waarden onder dit pad gestuurd:

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

Voor de wijziging toont deze alleen-lezenopdracht welke SATC-waarden al aanwezig zijn:

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

Let op: Registry-wijzigingen en de daaropvolgende herstart beïnvloeden alle actieve RDS-sessies. Documenteer de huidige waarden, gebruik een onderhoudsvenster en deactiveer Tamper Protection alleen gecontroleerd. Activeer die na de wijziging weer.

De basisconfiguratie kan in een administratieve opdrachtprompt worden gezet:

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 wordt vervangen door het IP-adres van de Sophos Firewall waarnaar de RDS-server de SATC-informatie moet sturen. De standaardpoort is 6060.

Daarna:

1. Tamper Protection weer activeren.
2. RDS-server opnieuw starten.
3. Na de herstart controleren of de Sophos-service draait.
4. De alleen-lezenopdracht reg query opnieuw uitvoeren en de ingestelde waarden controleren.
5. Pas daarna met firewallconfiguratie en tests doorgaan.

Lokale accounts en doelen uitsluiten

Standaard kunnen ook lokale accounts zoals SYSTEM of Administrator SATC-events genereren. Dat is voor gebruikersregels meestal niet nuttig en kan logs onnodig vervuilen.

Met SatcExcludedUsers kunnen gebruikers worden uitgesloten. De vermeldingen zijn hoofdlettergevoelig.

Voorbeeld:

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

Met SatcExcludedAddresses kunnen doelen worden uitgesloten waarvoor geen SATC-informatie naar de firewall moet worden gestuurd. Dat kan voor lokale management-, update- of infrastructuurdoelen zinvol zijn, maar moet bewust worden gedocumenteerd.

Mogelijke formaten:

192.0.2.10
192.0.2.10:443
*:443

Uitzonderingen moeten nauw worden gehouden. Wanneer te brede doelen worden uitgesloten, ziet de firewall later minder gebruikerscontext dan verwacht.

Bij merkbare netwerklatentie tussen de RDS-server en de firewall kan ook SatcPendDurationMs worden ingesteld. De waarde bepaalt hoelang uitgaande IPv4-TCP-verbindingen worden tegengehouden, zodat de gebruikerstoewijzing tijdig beschikbaar is. Als de registry-waarde ontbreekt, gebruikt SATC 100 milliseconden; 0 deactiveert alleen deze verbindingsvertraging, niet SATC. Pas de waarde alleen aan bij daadwerkelijke latentieproblemen, niet uit voorzorg.

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

Zoals bij de andere registerwijzigingen is daarna een herstart van de RDS-server nodig.

RDS-server op de firewall invoeren

De firewall moet weten welke servers SATC-informatie leveren. Dat gebeurt in de Device Console, niet in de Advanced Shell.

Werkwijze:

1. Aanmelden op de Sophos Firewall via console of SSH.
2. Optie 4. Device Console openen.
3. Bestaande vermeldingen weergeven:

system auth thin-client show

4. Het RDS-server-IP alleen toevoegen als het nog niet wordt vermeld:

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

<RDS-SERVER-IP> wordt vervangen door het IP-adres van de Remote Desktop Session Host.

Wanneer meerdere RDS-servers aanwezig zijn, elke server afzonderlijk en gedocumenteerd invoeren. Daarna moet duidelijk zijn:

• welke servers als SATC-bronnen gelden
• welke zone deze servers gebruiken
• welke firewallregels gebruikers van deze servers evalueren
• wie wijzigingen aan de RDS-serverlijst goedkeurt

Als een verkeerd IP-adres is ingevoerd, de lijst opnieuw controleren en het adres daarna gericht verwijderen:

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

De opdracht verwijdert alleen de Thin-Client-vermelding op de firewall; registry-waarden en Sophos Server Protection op de RDS-server blijven bestaan. Bij een productief IP-adres verdwijnt daardoor de SATC-toewijzing, waardoor gebruikersgebaseerde regels mogelijk niet meer matchen. Sophos documenteert niet hoe bestaande sessies reageren. Verwijder de vermelding daarom alleen in een onderhoudsvenster en met een voorbereid terugvalplan.

Active Directory en groepen controleren

SATC levert gebruikersinformatie. Om de firewall deze informatie in regels te laten gebruiken, moeten AD-koppeling en groepen kloppen.

Controleren:

1. Authentication > Servers openen.
2. AD-server met Test connection controleren.
3. Groepsimport controleren.
4. Authentication > Groups openen.
5. Relevante groepen zoeken.
6. Authentication > Services openen.
7. AD-server in de juiste volgorde van de Firewall authentication methods controleren.

Wanneer gebruikers in het Live-User-gedeelte verschijnen, maar regels niet werken, ligt de oorzaak vaak niet in SATC zelf, maar in groepsimport, standaardgroep, regelcriterium of regelpositie.

Device Access en firewallregel zetten

Om de firewall Client Authentication uit de serverzone te laten aannemen, moet Client Authentication voor deze zone toegestaan zijn.

Pad:

Administration > Device access

Onder Client Authentication de zone van de RDS-server activeren. Daarbij mag niet blind WAN of een brede onveilige zone worden geopend. Device Access stuurt lokale diensten van de firewall en hoort bij management-hardening.

Daarna heeft de eigenlijke traffic een firewallregel nodig.

Typische werkwijze:

1. Rules and policies > Firewall rules openen.
2. Passende regel voor traffic van de RDS-server of uit de serverzone maken.
3. Source zone en Destination zone passend instellen.
4. Match known users activeren.
5. Benodigde AD-gebruikers of AD-groepen selecteren.
6. Logging activeren, zodat de test later navolgbaar is.
7. Regel opslaan.
8. Testtraffic vanuit een RDS-sessie genereren.

Voor latere foutanalyse is logging belangrijk. Wanneer een gebruikersregel zonder logging wordt gemaakt, is moeilijker te herkennen of SATC, groepsmatching, regelvolgorde of een ander pad het probleem is.

Validatie en beheer

Validatie na de inrichting

Na de configuratie moet men niet alleen controleren of een gebruiker internettoegang heeft. Doorslaggevend is of de firewall de juiste gebruiker ziet en de juiste regel matcht.

Praktische test:

1. Gebruiker bij een RDS-sessie aanmelden.
2. Gedefinieerde testtraffic genereren, bijvoorbeeld een toegestane HTTPS-verbinding.
3. In de Sophos Firewall Current activities > Live users openen.
4. Controleren of de gebruiker met Client type Thin client verschijnt.
5. IP-adres van de RDS-server en sessietoewijzing controleren.
6. Log Viewer openen.
7. Filteren op Source IP van de RDS-server, gebruiker en regel.
8. Controleren of de verwachte gebruikersgebaseerde regel werkt.

Voor diepere analyse in de Advanced Shell is firewall_rule.log relevant voor regelmatching en access_server.log voor authenticatie en autorisatie. De Log Viewer blijft de snelste eerste controle.

Wanneer traffic niet loopt zoals verwacht, helpt aanvullend Firewallregel testen met Log Viewer, Policy Test en Packet Capture. Wanneer gebruikers wel zichtbaar zijn, maar groepen of afzonderlijke gebruikers niet matchen, past Sophos Firewall regel matcht niet als volgend controlepad.

Beheer en documentatie

SATC moet als een productieve authenticatiebouwsteen worden beheerd, niet als een eenmalige registry-hack.

Documenteren:

• RDS-servers en IP-adressen
• gebruikte firewall-IP en SATC-poort
• gezette registry-waarden
• uitgesloten gebruikers en doelen
• betrokken firewallregels
• AD-groepen en verantwoordelijken
• testgebruiker en verwachte regelmatch
• onderhoudsvenster en herstarttijdstip

Na updates van Sophos Server Protection, Windows Server, Sophos Firewall of AD moet men SATC gericht met een testgebruiker controleren. Authenticatieproblemen vallen vaak pas op wanneer gebruikersregels plots te breed of helemaal niet meer werken.

Troubleshooting

Geen Thin-Client-gebruiker zichtbaar

Controleren:

• RDS-server is na registry-wijziging opnieuw gestart.
• SendSatcEvents is gezet en ongelijk aan 0.
• SatcDestinationAddr wijst naar het juiste firewall-IP.
• SatcDestinationPort past bij de verwachte poort.
• Netwerkpad van de RDS-server naar de firewall is open.
• RDS-server-IP is via system auth thin-client add citrix-ip op de firewall geregistreerd.
• Zone van de RDS-server staat Client Authentication onder Device Access toe.

Gebruiker blijft door een source-portconflict niet-geauthenticeerd

Proxy- of securitysoftware op de RDS-server kan de source port van een verbinding wijzigen. De firewall detecteert dan een port mismatch en behandelt de traffic als niet-geauthenticeerd. Verwar deze source port niet met SatcDestinationPort: de registry-waarde bepaalt de doelpoort voor SATC-berichten, standaard 6060. Test zulke software gecontroleerd of configureer ze passend voor het SATC-pad; schakel beveiligingsfuncties niet algemeen uit.

Gebruiker verschijnt, maar regel matcht niet

Controleren:

• Gebruiker of groep is op de firewall geïmporteerd.
• Regel gebruikt Match known users.
• Juiste AD-groep is in de regel geselecteerd.
• Regelpositie klopt.
• Er is geen eerdere regel die dezelfde traffic zonder gebruikersrelatie matcht.
• Log Viewer toont dezelfde gebruiker, hetzelfde Source IP en dezelfde dienst.

Lokale accounts verschijnen in logs

SatcExcludedUsers controleren en technische accounts aanvullen. Vaak voorkomende kandidaten zijn lokale administrators, services en systeemaccounts. De lijst mag echter niet zo breed worden dat echte gebruikers per ongeluk worden uitgesloten.

Afzonderlijke doelen krijgen geen gebruikerscontext

SatcExcludedAddresses controleren. Wanneer een doel of poort is uitgesloten, stuurt SATC daarvoor geen authenticatie-informatie naar de firewall. Dat kan bedoeld zijn, maar leidt bij gebruikersregels gemakkelijk tot verwarring.

Na het invoeren van het server-IP werkt een oude Clientless User niet meer

Dat is te verwachten. Wanneer het RDS-server-IP als Thin-Client-server is geregistreerd, moet SATC voor dit IP het authenticatiemodel zijn. Oude workarounds met Clientless Users moeten worden verwijderd of bewust worden vervangen.

Geen internettoegang na een upgrade naar SFOS 22.0 GA

Als de gebruiker als Thin client verschijnt, maar sinds de upgrade geen internettoegang heeft, eerst de firmwareversie en de regelmatch vastleggen en firewall_rule.log en access_server.log verzamelen. Sophos bevestigt probleem NC-178903 voor upgrades naar SFOS 22.0 GA en verhelpt dit in SFOS 22.0 MR2 Build 546. Sophos vermeldt geen unieke logsignatuur of aparte workaround. De samenvatting van SFOS 22.0 MR2 biedt context bij de release.

Checklist

• RDS-scenario past werkelijk bij SATC en niet bij normale STAS.
• Sophos Server Protection is op de Remote Desktop Session Host geïnstalleerd.
• Windows Server-versie en RDS-rol zijn gecontroleerd.
• Tamper Protection is alleen gecontroleerd gedeactiveerd en daarna weer geactiveerd.
• SendSatcEvents, SatcDestinationAddr en SatcDestinationPort zijn gezet.
• RDS-server is opnieuw gestart.
• RDS-server-IP is in de Device Console op de firewall geregistreerd.
• AD-server en AD-groepen zijn op de firewall gecontroleerd.
• Client Authentication is voor de juiste zone onder Device Access toegestaan.
• Firewallregel gebruikt Match known users en heeft logging actief.
• Gebruiker verschijnt onder Current activities > Live users met Client type Thin client.
• Log Viewer toont de verwachte gebruiker en de verwachte regel.

FAQ