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.

Op een afzonderlijk endpoint buiten het domein kan de Client Authentication Agent een bewuste gebruikersaanmelding verzorgen. Deze vervangt SATC niet op een multi-userhost, omdat meerdere sessies hetzelfde source-IP delen.

Als op een multi-userhost uitsluitend HTTP en HTTPS via een expliciete proxy moeten worden onderscheiden, kan Per-Connection AD SSO via de Direct Web Proxy zonder SATC-agent volstaan. Zodra ook RDP, SMB of ander non-proxyverkeer per gebruikerssessie een identiteit nodig heeft, blijft SATC het juiste ontwerp.

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.
• Onder Administration > Device access is de zone van de RDS-server toegestaan in de rij Clients.
• De RDS-server kan het firewall-IP via UDP 6060 bereiken; een tussenliggende host- of netwerkfirewall staat dit pad toe.
• 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 Fusion Server Core Agent.
• Platform: volgens Sophos ondersteunt de huidige configuratie met Sophos Server Protection uitsluitend Windows Remote Desktop Services. Het oudere overzicht noemt Citrix XenApp nog bij het STAS-conflict en de CLI-parameter heet nog steeds citrix-ip. Geen van beide is actueel bewijs voor ondersteuning van een nieuwe Citrix-uitrol. Laat een bestaande Citrix-omgeving daarom vóór wijzigingen door Sophos Support bevestigen en bouw geen nieuwe omgeving op basis van deze RDS-handleiding.
• Systeemservices: SATC koppelt alleen verbindingen uit gebruikersprocessen aan een directory-identiteit. Processen die door Windows-systeemservices worden gestart, blijven zonder gebruikersidentiteit en vereisen een afzonderlijke, nauw begrensde machineregel met Match known users uitgeschakeld. Gebruik deze regel niet als brede fallback voor het overige RDS-verkeer.
• 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 Fusion (voorheen Sophos Central).

Werkwijze:

1. Aanmelden bij Sophos Fusion.
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 Fusion verschijnt.
6. Onderhoudsvenster voor de SATC-activering vastleggen.

SATC maakt deel uit van de Sophos Fusion Server Core Agent en is volgens Sophos beschikbaar met elke Server Protection-licentie. Welke installers daadwerkelijk in Sophos Fusion zichtbaar zijn, hangt desondanks af van de aanwezige licenties. Wanneer op de server al Sophos Server Protection draait, moet men ook 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

Vervang FIREWALL-IP door het IPv4-adres van Sophos Firewall dat vanuit de zone van de RDS-server bereikbaar is. Sophos documenteert UDP 6060 voor SATC; daarom blijft 6060 in het voorbeeld ongewijzigd. Gebruik geen openbaar WAN-adres wanneer server en firewall via een interne interface communiceren.

Avanet-advies: Sluit eerst slechts één RDS-host aan en sta UDP 6060 uitsluitend tussen deze host en de firewall toe. Zo blijft een fout beperkt tot de pilotserver voordat verdere Session Hosts worden toegevoegd.

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; de namen moeten daarom exact dezelfde schrijfwijze hebben als op het systeem.

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.

SatcExcludedAddresses is een waarde met meerdere tekenreeksen (MULTISTRING / REG_MULTI_SZ). Bij het instellen van meerdere doelen met reg add in de Windows-opdrachtprompt worden de vermeldingen in het gegevensargument /d gescheiden met \0, niet met komma’s. De hierboven beschreven stappen voor onderhoud, tamper protection, controle en terugdraaien gelden ook voor deze wijziging.

Mogelijke formaten:

192.0.2.10
192.0.2.10:443
*:443

192.0.2.10 is een documentatieadres en moet door het werkelijke doel-IP worden vervangen. De tweede vermelding geldt alleen voor poort 443 op dit doel, terwijl *:443 deze poort voor elk doel omvat. Zo’n brede uitzondering zou vrijwel al het HTTPS-verkeer uit de SATC-koppeling halen en is ongeschikt voor normale gebruikersregels.

Avanet-advies: Begin zonder uitzonderingen en voeg er pas een toe na een duidelijke logbevinding. Geef elke uitzondering een eigenaar, doel en controledatum.

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

300 is een aanpasbaar diagnostisch voorbeeld, geen aanbevolen nieuwe standaard. Het verhoogt de vertraging ten opzichte van de gedocumenteerde standaard van 100 milliseconden voor elke betrokken uitgaande IPv4-TCP-verbinding. Meet voor en na de wijziging met dezelfde gebruiker en hetzelfde doel. Als de waarde niet helpt, herstelt de volgende administratieve opdracht de standaard door de optionele waarde te verwijderen:

reg delete "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /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.

Alleen als AD eerst moet worden geraadpleegd: Leg vóór een wijziging de huidige volgorde vast en controleer de beoogde authenticatievolgorde en het terugdraaiplan; wijzig productieauthenticatie niet zomaar. Selecteer onder Authentication > Services > Firewall authentication methods de betreffende AD-server, verplaats deze naar de eerste positie in de lijst met geselecteerde servers en klik op Apply. Herstel bij ongewenste gevolgen de vastgelegde vorige volgorde en klik op Apply.

Voor AD-groepstoewijzing documenteert Sophos dat gebruikers bij authenticatie worden gekoppeld aan hun AD-groepen die op de firewall zijn geïmporteerd; bij elke aanmelding worden de groepen geëvalueerd en bijgewerkt. Alleen als geen van de AD-groepen van de gebruiker op de firewall bestaat, krijgt de gebruiker de Default group die onder Authentication > Services > Firewall authentication methods is ingesteld. Deze fallback vervangt geen ontbrekende groepsimport.

Tegenstrijdige bronnen over de eerste aanmelding: De SATC-configuratiebeschrijving noemt automatische toewijzing aan de standaardgroep bij de eerste firewallaanmelding, terwijl de beschrijving van AD-groepen een voorwaardelijke fallback beschrijft. Het is niet duidelijk of hiermee een SATC-specifieke begintoestand wordt bedoeld. Ga daarom niet uit van algemene toewijzing aan de standaardgroep of een speciale groepsprioriteit voor SATC.

Vóór de productie-uitrol: Controleer de geïmporteerde groepen onder Authentication > Groups en de werkelijk ingestelde Default group met de overgenomen instellingen onder Authentication > Services. Laat een testgebruiker opnieuw aanmelden, controleer de effectieve groepstoewijzing onder Authentication > Users en gebruik RDS-testverkeer in Log Viewer om de beoogde regelmatch en zowel toegestane als geblokkeerde toegang te controleren. Als de fallback moet worden gebruikt, test deze dan ook met een testaccount waarvan de AD-groepen niet op de firewall aanwezig zijn, zonder productiegroepen te verwijderen. Lidmaatschap van de standaardgroep alleen bewijst niet dat de gewenste regel wordt toegepast. Stop bij een onverwachte toewijzing de uitrol en vraag Sophos Support om opheldering; verruim geen gebruikersgroepen of regels als workaround.

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 SATC-berichten uit de serverzone te laten aannemen, moet de lokale dienst Clients voor deze zone zijn toegestaan. SFOS 22 documenteert hiervoor UDP 6060; Clients omvat ook STAS en de Client Authentication Agent op diens eigen poort.

Pad:

Administration > Device access

In de rij Clients 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. Een passende regel voor verkeer van de RDS-server of uit de serverzone maken. Als aanpasbaar voorbeeld kan regel RDS-Web-Users aanvankelijk alleen de benodigde dienst HTTPS toestaan vanaf hostobject RDSH-01 in LAN naar WAN.
3. Source zones, Source networks and devices, Destination zones en Services aan de eigen topologie aanpassen. RDSH-01, LAN, WAN en HTTPS zijn voorbeelden, geen productvereisten.
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.

Avanet-advies: Maak de pilotregel nauwer dan de latere productieregel en plaats hem direct boven een gedocumenteerde blokkeerregel. Breid diensten of gebruikersgroepen pas uit na een geslaagde test met twee verschillende RDS-gebruikers.

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. Controleren of het IP-adres van de RDS-server voor elke gebruiker met een unieke sessie-ID verschijnt.
6. Log Viewer openen.
7. Filteren op Source IP van de RDS-server, gebruiker en regel.
8. Controleren of de verwachte gebruikersgebaseerde regel werkt.

Herhaal de test met een tweede gebruiker en dezelfde doelverbinding. Succes betekent meer dan dat beide verbindingen zijn toegestaan: Live users moet twee identiteiten met hetzelfde RDS-server-IP maar verschillende sessie-ID’s tonen, en Log Viewer moet telkens de juiste gebruiker laten zien. Test ook een gedocumenteerde systeemdienst wanneer daarvoor een afzonderlijke machineregel is gemaakt; dit verkeer mag niet ten onrechte aan een aangemelde gebruiker worden gekoppeld.

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.

Terugdraaien in een onderhoudsvenster

Sophos documenteert dat SendSatcEvents SATC alleen activeert wanneer de waarde bestaat en niet 0 is, en dat de Thin-Client-vermelding andere authenticatiemethoden voor dit server-IP verdringt. Dit biedt een gepland terugkeerpad, maar herstelt de vorige identiteitsmethode niet automatisch.

1. Leg vooraf de registry-query, uitvoer van system auth thin-client show, betrokken regels en het vorige authenticatiemodel vast.
2. Meld actieve RDS-sessies in het onderhoudsvenster af, deactiveer Tamper Protection gecontroleerd en deactiveer SendSatcEvents in een administratieve opdrachtprompt:

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

3. Activeer Tamper Protection opnieuw en herstart de RDS-server.
4. Controleer in de Device Console de vermelding met system auth thin-client show en verwijder deze daarna gericht:

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

5. Herstel het eerder gedocumenteerde regel- en authenticatiemodel en valideer het met een testgebruiker. Activeer niet zonder test een Clientless User of brede machineregel als vervanging.

Avanet-advies: Verwijder niet alle registry-waarden voordat de oorzaak bekend is. De waarde 0 behoudt het doeladres en de uitsluitingslijsten voor een gecontroleerde heractivering; een registry-export bewaart bovendien de exacte uitgangssituatie.

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 voor UDP 6060.
• RDS-server-IP is via system auth thin-client add citrix-ip op de firewall geregistreerd.
• Zone van de RDS-server is in de rij Clients onder Device Access toegestaan.

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. De officiële SFOS 22.0-releaseopmerkingen vermelden NC-178903 onder SFOS 22.0 MR2 Build 546 als opgelost probleem bij upgrades naar SFOS 22.0 GA. 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.
• Clients is voor de juiste zone onder Device Access toegestaan en UDP 6060 is bereikbaar.
• 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