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.

Varje användare får då ett ID som är kopplat till användarens AD-användarnamn. För varje utgående anslutning från en användarprocess meddelar serveragenten brandväggen vilket användar-ID anslutningen tillhör. Det är mer än en engångsinloggning för serverns IP-adress: brandväggen ska kunna skilja mellan två samtidigt aktiva användare på samma värd. En lyckad RDP-inloggning är därför inte i sig ett funktionstest av SATC; för det krävs utgående trafik från respektive session.

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.

På en enskild endpoint utanför domänen kan Client Authentication Agent ge en avsiktlig användarinloggning. Den ersätter inte SATC på en fleranvändarvärd, eftersom flera sessioner delar samma käll-IP.

Om endast HTTP och HTTPS via en explicit proxy behöver särskiljas på en fleranvändarvärd kan Per-Connection AD SSO via Direct Web Proxy räcka utan SATC-agent. Så snart även RDP, SMB eller annan trafik utanför proxyn behöver en identitet per användarsession är SATC fortfarande rätt design.

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.
• Under Administration > Device access är RDS-serverns zon tillåten på raden Clients.
• RDS-servern kan nå brandväggens IP via UDP 6060; en mellanliggande värd- eller nätverksbrandvägg tillåter denna väg.
• 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 Fusion Server Core Agent.
• Plattform: enligt Sophos stöder den aktuella konfigurationen med Sophos Server Protection endast Windows Remote Desktop Services. Den äldre översikten nämner fortfarande Citrix XenApp i samband med STAS-konflikten och CLI-parametern heter fortfarande citrix-ip. Inget av detta är ett aktuellt stödbevis för en ny Citrix-driftsättning. Bekräfta därför en befintlig Citrix-miljö med Sophos Support före ändringar och bygg inte en ny miljö utifrån denna RDS-guide.
• Systemtjänster: SATC kopplar endast anslutningar från användarbaserade processer till en katalogidentitet. Processer som startas av Windows-systemtjänster saknar användaridentitet och kräver en separat, snävt avgränsad maskinregel med Match known users avstängt. Använd inte denna regel som en bred reservregel för övrig RDS-trafik.
• 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 återställningsvä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 Fusion (tidigare Sophos Central).

Förfarande:

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

SATC ingår i Sophos Fusion Server Core Agent och är enligt Sophos tillgängligt med alla Server Protection-licenser. Vilka installationsprogram som faktiskt visas i Sophos Fusion beror ändå på befintliga licenser. Om Sophos Server Protection redan körs på servern bör man även 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.

Omedelbart före skrivkommandona: Dokumentera den tidigare statusen för Tamper Protection och inaktivera Tamper Protection för just pilotservern. Använd först därefter kommandotolken med administratörsbehörighet på den servern. Följande kommandon innehåller /f: ett befintligt värde skrivs över utan bekräftelse. Spara därför utdata från reg query i förväg, inte bara det önskade nya värdet. Om behörighet eller ett kontrollerat sätt att inaktivera skyddet saknas, avbryt här; kringgå inte skyddet med en alternativ lösning.

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

Ersätt FIREWALL-IP med IPv4-adressen till den Sophos Firewall som kan nås från RDS-serverns zon. Sophos dokumenterar UDP 6060 för SATC, så 6060 lämnas oförändrat i exemplet. Använd inte en publik WAN-adress när servern och brandväggen kommunicerar via ett internt gränssnitt.

Avanet-rekommendation: Anslut först endast en RDS-värd och tillåt UDP 6060 enbart mellan denna värd och brandväggen. Då begränsas ett fel till pilotservern innan fler Session Hosts läggs till.

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, så namnen måste återges exakt som de används i systemet.

Exempel:

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

Exemplet är inte ett tillägg till en befintlig lista: /f ersätter hela värdet SatcExcludedUsers. Befintliga poster som fortfarande behövs måste finnas kvar i det nya dataargumentet. administrator är här skrivsättet från exemplet; om det faktiska kontonamnet är Administrator måste exakt den användningen av stor bokstav användas. Kontrollera hela listan med reg query efter ändringen och verifiera även en AD-testanvändare som inte är undantagen. Vid återställning ska det dokumenterade tidigare värdet återställas, i stället för att generellt ta bort alla undantag.

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.

SatcExcludedAddresses är ett värde med flera strängar (MULTISTRING / REG_MULTI_SZ). När flera mål anges med reg add i Windows kommandotolk ska posterna i dataargumentet /d skiljas åt med \0, inte med kommatecken. Stegen för underhåll, manipulationsskydd, kontroll och återställning som beskrivs ovan gäller även denna ändring.

Möjliga format:

192.0.2.10
192.0.2.10:443
*:443

192.0.2.10 är en dokumentationsadress och måste ersättas med målets faktiska IP-adress. Den andra posten gäller endast port 443 på detta mål, medan *:443 omfattar porten för alla mål. Ett så brett undantag skulle i praktiken ta bort all HTTPS-trafik från SATC-kopplingen och är olämpligt för normala användarregler.

Avanet-rekommendation: Börja utan undantag och lägg till ett först efter ett tydligt loggfynd. Ge varje undantag en ansvarig, ett syfte och ett granskningsdatum.

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

300 är ett anpassningsbart diagnostikexempel, inte en rekommenderad ny standard. Det ökar fördröjningen jämfört med det dokumenterade standardvärdet på 100 millisekunder för varje berörd utgående IPv4-TCP-anslutning. Mät före och efter med samma användare och mål. Om värdet inte ger någon nytta ska det tidigare dokumenterade tillståndet återställas. Endast om SatcPendDurationMs inte fanns före försöket återställer följande kommando, som körs med administratörsbehörighet, standardvärdet genom att ta bort det valfria värdet. Om ett värde redan var satt tidigare ska det i stället sättas igen med reg add och det dokumenterade numeriska värdet; att ta bort det skulle då inte återställa utgångsläget.

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

Kör system auth thin-client show igen efter tillägget och kontrollera den aktuella IP-adressen. Om meddelandet Maximum Thinclient limit reached. Maximum supported Thinclients are 192. visas har den dokumenterade servergränsen nåtts. Stäm av de befintliga posterna mot den godkända serverinventeringen; ta inte bort någon IP-adress som används i produktion bara för att skapa plats för pilotservern. Klarlägg först med ansvarig administratör vilka poster som faktiskt har tagits ur drift.

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 de nödvändiga grupperna saknas öppnar man Import för rätt AD-server under Authentication > Servers. Börja med Start i Import group wizard, välj rätt Base DN och endast de AD-grupper som behövs, granska de gemensamma policyerna noggrant, kontrollera urvalet och granska resultaten. Verifiera därefter de importerade grupperna under Authentication > Groups. En lyckad Test connection bekräftar anslutningen och inloggningsuppgifterna, men inte gruppimporten eller den senare regelmatchningen. Hur AD-servern läggs till, inklusive Domain name, NetBIOS domain och Search queries, beskrivs i AD-guiden som är länkad ovan; skapa inte en andra AD-server med avvikande konfiguration enbart för SATC.

Om även Synchronized User ID och STAS används anger Sophos att den inloggningsbegäran som kommer in först är avgörande för dessa två mekanismer. Det säger inget om någon SATC-prioritet och ersätter inte RDS-undantagen i STAS. Om identiteten växlar för samma server-IP ska därför även de autentiseringsmekanismer som används parallellt kontrolleras, inte bara AD-servrarnas ordningsföljd.

Endast om AD ska frågas först: Dokumentera den nuvarande ordningen före en ändring och kontrollera den avsedda autentiseringsordningen och återställningsplanen; ändra inte produktionsautentiseringen utan eftertanke. Välj den aktuella AD-servern under Authentication > Services > Firewall authentication methods, flytta den till första positionen i listan över valda servrar och klicka på Apply. Vid oönskade effekter återställer man den dokumenterade tidigare ordningen och klickar på Apply.

För AD-grupptilldelning dokumenterar Sophos att användare vid autentisering kopplas till sina AD-grupper som importerats på brandväggen; grupperna utvärderas och uppdateras vid varje inloggning. Endast om ingen av användarens AD-grupper finns på brandväggen tilldelas användaren den Default group som konfigurerats under Authentication > Services > Firewall authentication methods. Denna reservlösning ersätter inte import av saknade grupper.

Motstridiga källor om den första inloggningen: SATC-konfigurationsbeskrivningen anger automatisk tilldelning till standardgruppen vid den första inloggningen på brandväggen, medan beskrivningen av AD-grupper anger en villkorad reservlösning. Det är inte klarlagt om detta avser ett SATC-specifikt initialt tillstånd. Utgå därför varken från generell tilldelning till standardgruppen eller från en särskild gruppprioritet för SATC.

Före driftsättning i produktion: Kontrollera de importerade grupperna under Authentication > Groups och det faktiskt konfigurerade värdet för Default group, tillsammans med de ärvda inställningarna, under Authentication > Services. Låt en testanvändare logga in igen, kontrollera den faktiska grupptilldelningen under Authentication > Users och använd RDS-testtrafik i Log Viewer för att verifiera den avsedda regelmatchningen samt både tillåten och blockerad åtkomst. Om reservlösningen ska användas, testa den även med ett testkonto vars AD-grupper inte finns på brandväggen, utan att ta bort produktionsgrupper. Medlemskap i standardgruppen bevisar inte i sig att den avsedda regeln matchar. Stoppa driftsättningen vid oväntad tilldelning och klargör situationen med Sophos Support; utöka inte användargrupper eller regler för att kringgå problemet.

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 SATC-meddelanden från serverzonen måste den lokala tjänsten Clients vara tillåten för zonen. SFOS 22 dokumenterar UDP 6060; Clients omfattar även STAS och Client Authentication Agent på dess egen port.

Sökväg:

Administration > Device access

Aktivera RDS-serverns zon på raden Clients. 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 en passande regel för trafik från RDS-servern eller serverzonen. Som ett anpassningsbart exempel kan regeln RDS-Web-Users till en början endast tillåta den nödvändiga tjänsten HTTPS från värdobjektet RDSH-01 i LAN till WAN.
3. Anpassa Source zones, Source networks and devices, Destination zones och Services till den egna topologin. RDSH-01, LAN, WAN och HTTPS är exempel, inte produktkrav.
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.

Avanet-rekommendation: Gör pilotregeln snävare än den senare produktionsregeln och placera den direkt ovanför en dokumenterad blockeringsregel. Utöka tjänster eller användargrupper först efter ett lyckat test med två olika RDS-användare.

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 att RDS-serverns IP-adress visas med ett unikt sessions-ID för varje användare.
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.

Upprepa testet med en andra användare och samma målanslutning. Framgång betyder inte bara att båda anslutningarna tillåts: Live users måste visa två identiteter med samma RDS-server-IP men olika sessions-ID:n, och Log Viewer måste visa rätt användare i varje fall. Testa även en dokumenterad systemtjänst om en separat maskinregel skapades för den; denna trafik får inte felaktigt kopplas till en inloggad användare.

Kontrollera även åtskillnaden: Logga in båda testanvändarna samtidigt på samma pilotserver. I ett kontrollerat test får användare A nå ett definierat mål via sin godkända AD-grupp, medan användare B utan denna behörighet inte får det. Skapa nya anslutningar till samma mål och tjänst från båda sessionerna. I Log Viewer måste det gå att följa respektive användare och den regelmatchning som tillåter respektive blockerar åtkomsten. Om båda användarna oväntat får åtkomst ska man först kontrollera tidigare regler utan användarkoppling och grupperna; utöka inte pilotregeln. Rulla ut till fler värdar först när både identiteten och det negativa testet är korrekta.

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.

Återställ under ett underhållsfönster

Sophos dokumenterar att SendSatcEvents endast aktiverar SATC när värdet finns och inte är 0, och att Thin-Client-posten tränger undan andra autentiseringsmetoder för denna server-IP. Det ger en planerad återställningsväg, men återställer inte den tidigare identitetsmetoden automatiskt.

1. Dokumentera först registry-frågan, utdata från system auth thin-client show, berörda regler och den tidigare autentiseringsmodellen.
2. Logga ut aktiva RDS-sessioner under underhållsfönstret, deaktivera Tamper Protection kontrollerat och deaktivera SendSatcEvents i en administrativ kommandoprompt:

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

3. Aktivera Tamper Protection igen och starta om RDS-servern.
4. Kontrollera posten i Device Console med system auth thin-client show och ta därefter bort den kontrollerat:

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

5. Återställ den tidigare dokumenterade regel- och autentiseringsmodellen och validera den med en testanvändare. Aktivera inte en Clientless User eller bred maskinregel som ersättning utan test.

Bekräfta efter borttagningen med system auth thin-client show att endast den avsedda posten saknas. Även de tidigare konfigurerade STAS-undantagen ingår i återställningen: ta inte bort dem automatiskt. Beslutet beror på vilken autentiseringsmodell som är avsedd för fleranvändarvärden efter återställningen; STAS ensamt löser inte problemet med den gemensamma käll-IP-adressen. Kontrollera avslutningsvis Tamper Protection, tillåtna och blockerade teståtkomster samt den faktiska regelmatchningen igen.

Avanet-rekommendation: Ta inte bort alla registry-värden innan orsaken har klarlagts. Värdet 0 bevarar måladressen och undantagslistorna för en kontrollerad återaktivering; en registry-export bevarar dessutom det exakta utgångsläget.

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 för UDP 6060.
• RDS-serverns IP registrerades på brandväggen med system auth thin-client add citrix-ip.
• RDS-serverns zon är tillåten på raden Clients 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. De officiella versionsanteckningarna för SFOS 22.0 listar NC-178903 under SFOS 22.0 MR2 Build 546 som ett åtgärdat problem för uppgraderingar till SFOS 22.0 GA. 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.
• Clients är tillåtet för rätt zon under Device Access och UDP 6060 är nåbart.
• 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