Naar de inhoud
Avanet

Sophos Firewall SATC voor Remote Desktop Services instellen

Sophos Authentication for Thin Client, kort SATC, helpt bij gebruikersregels op Remote Desktop Services. Dat is steeds 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.

Dit artikel legt uit wanneer SATC zinvol is, welke grenzen gelden, hoe men SATC via Sophos Server Protection activeert en hoe men daarna controleert of de gebruikers correct in de Sophos Firewall verschijnen.

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

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 door een gedeeld source-IP niet netjes volstaat

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

STAS en SATC netjes scheiden

Het belangrijkste verschil is de IP-toewijzing.

ScenarioPassende aanpak
Een Windows-client hoort normaal bij een gebruikerSTAS
Veel gebruikers delen hetzelfde RDS-server-IPSATC
Gebruikers melden zich in de browser aan zodat regels werkenCaptive Portal
Gebruikers komen via Remote Access VPNVPN-authenticatie of Entra ID SSO
Traffic loopt zonder gebruikersrelatie via technische serversnormale 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.

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 zelf moet niet terloops ontstaan. Wanneer AD nog niet netjes is ingericht, eerst Active Directory met Sophos Firewall verbinden controleren.

Belangrijke grenzen

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

PuntBetekenis
Standalone-SATCWordt door Sophos Firewall niet meer ondersteund.
UitrolSATC draait via Sophos Server Protection respectievelijk de Sophos Central Server Core Agent.
PlatformSATC met Sophos Server Protection is bedoeld voor Windows Remote Desktop Services.
ServerlimietSophos noemt tot 192 Thin-Client-servers op de firewall.
Authenticatie per server-IPWanneer 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.

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 moet men de actuele instellingen documenteren. Wanneer Tamper Protection op de server actief is, moet die voor de wijziging gecontroleerd worden gedeactiveerd en daarna weer geactiveerd.

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

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.

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. RDS-server-IP toevoegen:
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

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

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

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

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 owners
  • 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. Authenticatie valt vaak pas op wanneer gebruikersregels plots te breed of helemaal niet meer werken.

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

Wanneer heeft men SATC in plaats van STAS nodig?

SATC is zinvol wanneer meerdere gebruikers hetzelfde source-IP delen, bijvoorbeeld op een Remote Desktop Session Host. STAS past beter bij normale Windows-clients, waarbij een client-IP normaal bij een gebruiker hoort.

Wordt de oude Standalone-SATC nog ondersteund?

Nee. De actuele route loopt via Sophos Server Protection respectievelijk de Sophos Central Server Core Agent op de Windows Remote Desktop Session Host.

Welke Windows Server-versie heeft SATC nodig?

Sophos noemt Windows Server 2016 of nieuwer voor SATC met Sophos Server Protection. Daarnaast moet het om een Remote-Desktop-Services-scenario gaan.

Waarom werkt een Clientless User voor het RDS-server-IP niet meer?

Wanneer het RDS-server-IP op de firewall als Thin-Client-server is geregistreerd, werkt dit IP met SATC. Andere authenticatiemethoden zoals Clientless User zijn voor dit IP dan niet de juiste route.

Hoe controleert men of SATC werkt?

Een gebruiker meldt zich bij een RDS-sessie aan, genereert testtraffic en wordt daarna onder Current activities > Live users met Client type Thin client gecontroleerd. Daarnaast moet de Log Viewer tonen welke gebruikersregel de traffic matcht.