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.

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

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

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 ett rekommenderat nytt standardvärde. Det ökar fördröjningen jämfört med det dokumenterade standardvärdet 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 hjälper återställer följande administrativa kommando standardvärdet genom att ta bort det valfria värdet:

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.

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.

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.

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.

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