Konfigurera Sophos Firewall Clientless SSL VPN för RDP och SSH

Med Clientless SSL VPN gör en Sophos Firewall enskilda interna RDP-, SSH-, VNC- eller filserveranslutningar tillgängliga direkt i webbläsaren. Användaren installerar ingen VPN-klient och får ingen allmän åtkomst till ett internt nätverk. I stället loggar användaren in på VPN Portal och ser endast de bookmarks som publiceras av användarens Clientless Policy.

Det liknande namnet kan lätt leda till fel konfiguration: Clientless Users kopplar internt en fast IP-adress till en identitet. Det publicerar inga bookmarks och ingår inte i denna Remote Access-procedur.

Inloggningen på VPN Portal och inloggningen på målsystemet är två separata steg. Clientless SSL VPN stöder inte Credential Passthrough: lösenordet till VPN Portal vidarebefordras inte automatiskt till Windows- eller SSH-inloggningen. Två inloggningar är därför normalt så länge inga inloggningsuppgifter för målsystemet är lagrade i bookmarken.

Huvudförloppet är kort:

Ange ett fast målsystem, port och behörig användargrupp.
Skapa en RDP- eller SSH-bookmark under Remote access VPN > Clientless SSL VPN policy > Bookmarks.
Koppla samman användargruppen och bookmarken under Policies.
Säkra VPN Portal, certifikat, autentisering, MFA och Device Access.
Testa åtkomsten externt under VPN > Clientless access connections med en behörig och en obehörig användare.

När Clientless SSL VPN passar – och när det inte gör det

Clientless Access passar särskilt bra för ett fåtal fasta mål, tillfällig åtkomst eller externa tekniker när ingen VPN-klient ska installeras på den använda enheten. RDP och SSH behöver då inte publiceras direkt på internet via DNAT. I stället är den säkrade VPN Portal offentligt tillgänglig.

Det ersätter däremot inte alla Remote Access VPN-scenarier:

Clientless SSL VPN passar för enskilda statiska RDP-, SSH-, VNC- eller filservermål som kan användas i webbläsaren.
Sophos Connect med IPsec eller SSL VPN passar bättre när en hanterad enhet behöver flera nätverk, inbyggda program, DNS eller olika protokoll. Beslutsguiden för Remote Access förklarar alternativen.
ZTNA är avsett för permanent programorienterad åtkomst med identitet, enhetsstatus och centrala policies. Grunderna finns i Vad är Zero Trust Network Access?.
RD Gateway, Jump Host eller PAM bör övervägas när privilegierad administration, personliga målkonton, sessionsinspelning eller godkännandeflöden är avgörande.

För RDP är det också viktigt att urklipp inte stöds i Clientless-sessioner sedan SFOS 19. Om copy-and-paste eller andra inbyggda RDP-funktioner är obligatoriska för arbetsflödet är en klientbaserad eller specialiserad åtkomstväg ett bättre val.

Clientless SSL VPN stöder inte dynamiska mål-IP-adresser. Ett värdnamn får användas som mål, men brandväggen måste kunna slå upp det stabilt och det måste peka på det avsedda systemet. Ett mål som ändras ofta bör inte planeras som ett Dynamic DNS-scenario som förväntas uppdateras tillförlitligt.

Webbläsaren är endast användargränssnittet: den upprättar HTTPS-anslutningen till VPN Portal, medan Sophos Firewall upprättar den andra anslutningen till målet. Popup-blockeraren måste tillåta det nya fönstret för portalens FQDN. SFOS 22 kan inte publicera valfria interna HTTP- eller HTTPS-program som Clientless-bookmarks; använd WAF eller ZTNA beroende på kraven.

Krav och exempelvärden

Före konfigurationen bör mål, identitet och portalåtkomst vara fastställda:

Målsystemet kan nås från brandväggen via routing och DNS, och den tjänst som behövs körs.
En användare eller helst en snävt avgränsad grupp finns på brandväggen eller den anslutna autentiseringsservern.
VPN Portal har ett offentligt eller internt åtkomligt FQDN och ett matchande betrott certifikat.
Under Authentication > Services har en lämplig metod valts under VPN portal authentication methods.
MFA och en oberoende återställningsåtkomst har förberetts.
Det har beslutats om inloggningsuppgifter för målsystemet får lagras i bookmarken.

Följande RDP-exempel använder:

VPN Portal: https://vpn.example.com
målserver: rdp-app01.intern.example
mål-IP: 10.20.30.25
RDP-port: 3389
bookmark: RDP-Fibu-Test
grupp: Clientless-RDP-Fibu
policy: Clientless-RDP-Fibu
RDP-säkerhet för det första testet: TLS
Automatic login: inaktiverat
Share session: inaktiverat

example.com är en reserverad exempeldomän och 10.20.30.25 är en privat exempeladress. FQDN, IP, grupp och namn måste ersättas med värden från den egna miljön. Port 3389 är endast korrekt om Windows-servern faktiskt använder RDP-standardporten.

Konfigurera RDP-bookmarken

Bookmark med TLS och personlig målinloggning

Under Remote access VPN > Clientless SSL VPN policy > Bookmarks skapas en ny bookmark med Add:

Ange RDP-Fibu-Test under Name.
Välj RDP som Type.
Ange rdp-app01.intern.example eller den fasta IP-adressen 10.20.30.25 under URL.
Använd tjänsteporten 3389. En annan port anges endast om den avsiktligt har konfigurerats annorlunda på målsystemet.
Låt Automatic login vara inaktiverat för det första testet.
Ange Windows-nätverksdomänen vid behov, till exempel CORP eller corp.example.com.
Välj TLS under Protocol security. Det tredje alternativet, RDP, använder RDP-protokollets egen säkerhet; Sophos rekommenderar i stället TLS eller NLA.
Låt Share session vara inaktiverat.
Spara med Save.

Utan Automatic login anger användaren sina inloggningsuppgifter i det öppnade RDP-fönstret. Inloggningen kan då göras med ett personligt Windows-konto, förutsatt att målsystemets säkerhetsmodell tillåter detta TLS-läge.

Certifikatet för VPN Portal och Protocol security: TLS har olika uppgifter. Portalcertifikatet skyddar webbläsarvägen till brandväggen. RDP-inställningen skyddar den efterföljande anslutningen från brandväggen till Windows-systemet. Ett giltigt portalcertifikat ersätter därför inte lämplig RDP-säkerhet.

När Windows-servern kräver NLA

Många Windows-system kräver Network Level Authentication (NLA). I så fall väljs NLA i bookmarken. SFOS aktiverar då Automatic login, och användarnamn och lösenord för målsystemet måste lagras i bookmarken.

Det är inte en ren bekvämlighetsfunktion. Alla behöriga användare av denna bookmark arbetar då på målsystemet med samma lagrade Windows-identitet. Endast ett dedikerat konto med minimala behörigheter som går att rotera bör användas för detta. Domain Admin-konton, personliga administratörskonton och brett behöriga tjänstekonton hör inte hemma i en Clientless Bookmark.

NLA bör inte inaktiveras på Windows-servern enbart för att TLS-exemplet ska fungera. Om lagrade inloggningsuppgifter eller en gemensam målidentitet inte är acceptabla passar Clientless RDP inte för den här servern. En vanlig VPN, RD Gateway, PAM eller en kontrollerad Jump Host bevarar den personliga spårbarheten bättre.

Share session förblir också inaktiverat. Alternativet är avsett för ett medvetet planerat samarbetsfall. I en delad session avslutar Stop session anslutningen för alla deltagare, medan Suspend session endast pausar den aktuella användaren. En session för privilegierad administration bör inte delas.

VNC-bookmark för Linux- och UNIX-system

En VNC-bookmark följer samma grundprincip men använder Type: VNC. Under URL anges målsystemets fasta IP-adress eller ett stabilt namn som kan lösas upp. En annan VNC-port anges endast om tjänsten faktiskt lyssnar på en port som avviker från standardporten.

Med Automatic login lagrar SFOS mållösenordet i VNC-bookmarken. Om alternativet förblir inaktiverat anger användaren lösenordet när anslutningen öppnas. Inget användarnamn konfigureras i en VNC-bookmark. Share session förblir inaktiverat för normal individuell åtkomst och används endast när en delad session uttryckligen krävs.

ℹ️ Inloggningen i VPN Portal vidarebefordras inte heller till målsystemet för VNC. En lyckad portalanmälan bevisar därför varken att VNC-lösenordet är korrekt eller att brandväggen kan nå VNC-tjänsten.

Konfigurera Clientless Policy och VPN Portal

Koppla användare och bookmark i en policy

En befintlig bookmark gör inte i sig målet synligt för någon användare. Det är först policyn som kopplar samman identitet och resurs:

Öppna Remote access VPN > Clientless SSL VPN policy.
Klicka på Add under Policies.
Ange Clientless-RDP-Fibu som Name.
Välj endast gruppen Clientless-RDP-Fibu under Policy members.
Välj RDP-Fibu-Test under Published bookmarks.
Spara med Apply.

En Bookmark Group är först motiverad när samma användare behöver flera mål. För ett enskilt RDP-mål skapar den bara ett extra administrationslager.

Säkra VPN Portal

Användaren öppnar Clientless-anslutningar via VPN Portal. Standardporten är 443; port och certifikat finns under Administration > Admin and user settings > Admin console and end-user interaction. I exemplet måste certifikatet innehålla vpn.example.com som SAN och godtas av webbläsaren utan varning. Importera och tilldela certifikat på Sophos Firewall förklarar den allmänna certifikattilldelningen.

Under Administration > Device access måste VPN portal tillåtas för den åtkomst som faktiskt behövs. Om portalen ska vara åtkomlig från alla WAN-källor aktiveras WAN i matrisen. Vid kända källnätverk är den snävare varianten bättre: låt WAN vara inaktiverat i matrisen och skapa under Local service ACL exception rule en regel med Source zone: WAN, det konkreta Source Network / Host, den brandväggsadress som behövs som Destination host, Services: VPN portal och Action: Accept. Ett ytterligare Accept-undantag begränsar inte en WAN-matrisbehörighet som redan har aktiverats generellt. WebAdmin, User Portal, SSH eller SSL VPN aktiveras inte automatiskt samtidigt. Firewall Rules styr inte dessa lokala tjänster. Den säkra planeringen finns i Device Access och Local Service ACL.

⚠️ En VPN Portal som kan nås från WAN är en offentlig inloggningsyta. Den bör inte användas utan MFA, ett betrott certifikat, snävt policymedlemskap och övervakning av inloggningar. Om VPN Portal och SSL VPN använder samma port fungerar inte Login security settings. Om de även använder samma protokoll gör en SSL VPN-tillåtelse från en zon också VPN Portal åtkomlig, även om portalen är inaktiverad för zonen under Device access. Använd en unik kombination av port och protokoll för varje lokal tjänst och kontrollera åtkomsten igen efter varje portändring.

För lokal Sophos OTP används först Specific users and groups under Authentication > Multi-factor authentication. För självregistrering via en autentiseringsapp aktiveras Generate OTP token with next sign-in, VPN portal väljs under Require MFA for och inställningen sparas med Apply. Användaren kan sedan skanna QR-koden i VPN Portal. SFOS 22 stöder SHA1, SHA256 och SHA512, och Sophos rekommenderar SHA256 eller SHA512. Appen måste dock stödja den valda algoritmen: Intercept X for Mobile och Google Authenticator fungerar; Microsoft Authenticator kan skanna en kod med SHA256 eller SHA512, men den efterföljande inloggningen misslyckas. Vid ett algoritmbyte raderas befintliga tokens under Issued tokens, varefter användarna skannar QR-koden igen. Pilotfasen och återställningsvägen finns i Aktivera MFA för Sophos Firewall. VPN Portal stöder inte challenge-baserad RADIUS-MFA. En befintlig RADIUS-metod måste därför testas specifikt för denna portalinloggning. Om portalen i stället ska använda Microsoft Entra ID SSO och Conditional Access beskriver Entra ID SSO för Sophos Connect och VPN Portal hela identitetskedjan.

Under Authentication > Services kan högst 20 servrar väljas per autentiseringsmetod. De globala inställningarna Maximum session timeout och Simultaneous logins gäller inte bara VPN Portal. SFOS kontrollerar behörigheten var tredje minut, och begränsningen av samtidiga inloggningar gäller endast användare som läggs till efter att värdet har ställts in. Dessa gränser ska därför inte betraktas som omedelbara, portalspecifika åtkomstkontroller.

Testa åtkomst utifrån

Testet bör utföras från ett verkligt externt nätverk, till exempel via en mobil hotspot. Ett test från LAN bevisar inte att DNS, certifikat, Device Access och en framförliggande router fungerar korrekt från internet.

Öppna https://vpn.example.com i ett privat webbläsarfönster.
Kontrollera certifikatnamn, certifikatkedja och webbläsarstatus.
Logga in som medlem i Clientless-RDP-Fibu och slutför MFA.
Kontrollera under VPN > Clientless access connections att RDP-Fibu-Test visas.
Klicka på Connect. Sessionen måste öppnas i ett nytt webbläsarfönster.
När Automatic login är inaktiverat anger man de personliga Windows-inloggningsuppgifterna och testar RDP-inloggningen.
Logga ut korrekt från sessionen på Windows-systemet och lämna sedan VPN Portal.
Testa med en användare utanför gruppen. Bookmarken får inte visas där.
Ta tillfälligt bort testanvändaren från policygruppen och kontrollera att åtkomsten försvinner efter en ny inloggning.

Ett lyckat resultat innebär inte bara att ett skrivbord visas. Den behöriga användaren ser exakt de avsedda bookmarks, den obehöriga användaren ser inga, MFA tillämpas, certifikatet är betrott, målinloggningen fungerar och sessionen avslutas spårbart på både portalen och målsystemet.

Använd sessions- och tangentbordskontroller i webbläsaren

I RDP-, VNC-, SSH- och Telnet-sessioner flyttar man pekaren till överkanten av den fjärranslutna skärmen för att visa sessionsalternativen. Under Connection finns Stop session och Suspend session. Efter Suspend session återupptar samma användare sessionen nästa gång de klickar på Connect i VPN Portal. Andra deltagare i en delad session fortsätter att arbeta; Stop session avslutar däremot sessionen för alla.

För RDP- och VNC-anslutningar kan användare under Keyboard välja tangentbordsgenvägar och ändra tangentbordsspråk. För att använda ett språk i listan som inte är engelska kräver det dokumenterade förfarandet att målserverns språk är inställt på US English. Detta krav gäller språkvalet under Keyboard, inte urklipp.

Alternativ för SSH, VNC och filservrar

SSH-bookmark med verifierad Host Key

För SSH väljs SSH som Type under Bookmarks > Add. Ett exempel använder srv-linux01.intern.example, port 22 och användaren clientless-test.

Public host key måste tillhöra den förväntade servern. På ett Linux-mål kan den offentliga Host Key visas direkt i den betrodda serverkonsolen och dess fingerprint dokumenteras:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Dessa kommandon körs på Linux-målservern, inte på Sophos Firewall. Om servern använder en annan Host Key-typ måste filnamnet anpassas. En nyckel från en overifierad webbläsarvarning eller en godtycklig nätverksskanning får inte användas utan kontroll.

Det första kommandot visar den offentliga ED25519 Host Key som ska infogas under Public host key i bookmarken. Det andra kommandot visar endast fingerprint för den dokumenterade jämförelsen. Fingerprint ska inte kopieras till fältet i stället för nyckeln.

Därefter skapas hela SSH-bookmarken:

Ange exempelvis SSH-Linux-Test under Name.
Välj SSH som Type.
Ange srv-linux01.intern.example under URL och port 22.
Ange clientless-test eller den avsedda målanvändaren under Username.
Låt Automatic login vara inaktiverat om användaren ska ange mållösenordet själv.
Infoga den offentliga Host Key som har verifierats direkt på målsystemet under Public host key.
Låt Share session vara inaktiverat och spara med Save.
Lägg till bookmarken i Clientless Policy under Published bookmarks och spara med Apply.
Klicka på Connect under VPN > Clientless access connections i VPN Portal, ange mållösenordet och kontrollera att förväntad Terminal Prompt visas. Avsluta sedan SSH-sessionen korrekt.

Utan Automatic login anger användaren mållösenordet när anslutningen upprättas. Användarnamnet förblir en del av bookmarken. Olika personliga SSH-användarnamn kräver därför separata bookmarks eller en annan åtkomstväg. Med Automatic login kan SFOS använda lösenord eller Private Key. Privilegierade eller brett använda Private Keys bör inte lagras i en gemensamt publicerad bookmark.

Filservrar med FTP, FTPS, SFTP eller SMB

Bookmarks för filservrar skapas också under Remote access VPN > Clientless SSL VPN policy > Bookmarks > Add. Under Type finns FTP, FTPS, SFTP och SMB. URL innehåller en fast IP-adress eller ett stabilt hostname; Clientless SSL VPN stöder inte dynamiska måladresser. Under Init remote folder kan man valfritt ange den mapp där användaren börjar efter anslutningen.

Metoderna skiljer sig främst åt genom transport och autentisering mot målet:

FTP, FTPS och SMB kan användas med eller utan Automatic login. Utan lagrade inloggningsuppgifter loggar användaren in på målsystemet efter att bookmarken har öppnats. FTP överför data okrypterat och bör inte användas för nya externa workflows.
För SMB går det också att valfritt ange den Windows-nätverksdomän som målkontot och målsystemet tillhör, till exempel CORP, corp.example eller corp.example.com. Ersätt dessa exempel med den faktiska domänen i den egna miljön.
FTPS skyddar FTP-anslutningen med TLS. Under Public host key lagras dessutom det förväntade servercertifikatet i .pem-format. Certifikatet och namnet verifieras direkt på det hanterade målsystemet och hämtas inte från en overifierad anslutning.
SFTP använder SSH. Bookmarken innehåller målanvändaren och antingen ett lösenord eller en Private Key. Under Public host key lagras serverns verifierade offentliga Host Key. Användarens privata nyckel och serverns offentliga Host Key har olika uppgifter och får inte förväxlas.

Med Automatic login lagras målsystemets användarnamn och lösenord i bookmarken för FTP, FTPS och SMB. Alla behöriga användare använder då denna lagrade målidentitet, så samma krav på minsta möjliga behörighet och rotation gäller som i NLA-exemplet. Detta är inte Credential Passthrough från VPN Portal.

I detta SFTP-förfarande autentiserar SFOS automatiskt med de inloggningsuppgifter för målet som lagras i bookmarken. Användaren uppmanas inte att ange mållösenordet; den valfria interaktiva inloggningen för SSH, FTP, FTPS och SMB gäller inte för SFTP.

I webbläsaren kan användare i FTP-, FTPS- och SFTP-sessioner överföra filer, skapa mappar och navigera mellan kataloger. SFOS startar hämtningar utan ytterligare fråga och sparar dem i endpointens standardmapp för hämtningar. Därför bör behörigheter, startmapp och ett test med icke-känsliga filer verifieras före produktionsanvändning. En filserver-bookmark skapar ingen vanlig Windows-nätverksenhet och ersätter inte personlig behörighetskontroll på målservern.

Knapparna uppe till höger i FTP-, FTPS- och SFTP-sessioner används för att stoppa sessionen, ladda upp en fil, skapa en mapp och gå till den överordnade mappen.

Telnet finns fortfarande som terminaltyp men krypterar inte transporten. Det bör inte användas för nya åtkomster. HTTP- och HTTPS-bookmarks ingår inte i de Clientless-typer som för närvarande dokumenteras för SFOS 22. För interna webbapplikationer är Web Application Firewall eller ZTNA en lämpligare arkitektur, beroende på skyddsbehovet.

Om en äldre enhet tillfälligt kräver Telnet väljer du Type: Telnet under Bookmarks > Add, anger den fasta värden under URL och ställer bara in porten om den avviker från standarden. Share session är valfritt. Begränsa denna okrypterade åtkomst till en liten grupp och ett isolerat hanteringsmål och ersätt den sedan med SSH.

När samma mål ska tilldelas flera policies skapas en grupp under Bookmark groups > Add och befintliga bookmarks läggs till med Add new item. Policyn publicerar sedan gruppen i stället för varje mål separat. En Bookmark Group utökar inte behörigheterna på målsystemet; den förenklar endast tilldelningen i SFOS.

När en grupp skapas eller ändras via XML API heter entiteten SSLBookmarkGroup. API-dokumentationen för SFOS 23.0 tillåter UTF-8-tecken i dess Name, förbjuder kommatecken och behåller gränsen på 50 tecken. Dokumentationen för SFOS 22.0 anger redan denna gräns men inte de två ytterligare teckenreglerna; det visar inte hur äldre builds tillämpar dem. Ett giltigt exempelnamn är Clientless-München, som i <Name>Clientless-München</Name>; anpassa namnet till den egna miljön. Kontrollera efter API-anropet statuskoden och meddelandet i XML-svaret och läs tillbaka den sparade gruppen: namnet och dess bookmarks måste motsvara den avsedda tilldelningen. Denna anmärkning gäller gruppnamnet i API:et och är ingen generell regel för enskilda bookmarknamn; följ fältkraven för den installerade builden i gränssnittet som beskrivs ovan.

Felsöka vanliga problem

VPN Portal kan inte nås: Kontrollera den offentliga DNS-posten, porten, framförliggande NAT, Administration > Device access och en möjlig Port Sharing-effekt.
Portalens inloggning misslyckas: Kontrollera VPN Portal-autentisering under Authentication > Services samt användarstatus, MFA och access_server.log.
Clientless access connections saknas: Användaren har inte tilldelats någon Clientless Policy eller så publicerar policyn ingen bookmark.
Bookmarken visas för fel användare: Kontrollera Policy members, gruppmedlemskap och Published bookmarks. Vid flera matchande grupper kan Clientless SSL VPN kombinera behörigheterna från de tillhörande policies. Vilka bookmarks en verklig användare därmed ser ska ingå i det positiva och negativa testet.
Bookmarken öppnas men målet kan inte nås: Kontrollera DNS-upplösningen ur brandväggens perspektiv, den statiska måladressen, routing, målporten, tjänstens status och värdbrandväggen.
Inloggningen på VPN Portal fungerar men inte Windows-inloggningen: Portal- och målinloggning är separata. Kontrollera domän, målkonto, lösenord samt TLS eller NLA.
NLA aktiverar Automatic login: Detta är det dokumenterade beteendet. Inaktivera inte NLA oplanerat, utan ompröva konto- och åtkomstmodellen.
SSH visar en annan Host Key: Stoppa anslutningen och kontrollera ändringen direkt på målsystemet eller med den ansvariga operatören. En oväntad nyckel kan tyda på en ominstallation, ett felaktigt mål eller en attack.

Under Diagnostics > Tools > Troubleshooting logs hjälper olika filer i olika faser:

vpnportal.log för VPN Portal;
access_server.log för autentisering och auktorisering;
clientless_access.log för Clientless-anslutningar och anslutningen till målet;
oauth_sso_vpn.log för inloggningar på VPN Portal med SSO.

Testtidpunkt, användare, bookmark och mål bör dokumenteras tillsammans. Då kan portal-, identitets- och målproblem skiljas åt i loggarna. Den allmänna loggtilldelningen och åtkomst via Advanced Shell finns i Sophos Firewall-tjänsteloggar.

Drift och kända RDP-begränsningar

Dokumentera före en produktionsändring policytilldelningen, Device Access-matrisen, ACL-undantag, portalport och certifikatval. Om det positiva testet misslyckas eller den obehöriga användaren ser en bookmark tar du bort den nya tilldelningen eller publiceringen, återställer värdena till föregående tillstånd, loggar in igen och upprepar det negativa testet. Återställ endast målkonton eller Host Keys om de faktiskt ändrades.

Clientless Policies bör granskas regelbundet på samma sätt som andra Remote Access-behörigheter. Användare, bookmarks och målkonton som inte längre behövs tas bort. Lagrade lösenord eller Private Keys ska ha en owner, ett utgångsdatum och en rotationsprocess. Automatic login och Share session ska ingå i varje behörighetsgranskning.

Öppna Current activities > Remote users i administratörskonsolen för att se inloggade fjärranvändare i realtid. Anslutningar kan filtreras efter anslutningsdatum, användarnamn, käll-IP-adress och tilldelad IP-adress (leased IP). Administratören kan klicka på Disconnect för att koppla från den valda fjärranvändaren. Kontrollera först användaren och anslutningen eftersom åtgärden avbryter åtkomsten. Den ersätter inte att ta bort användaren från Clientless Policy eller att logga ut korrekt på målsystemet och garanterar inte att alla efterföljande sessioner på målsystemen avslutas.

Använd före ett firmwarebyte Avanets runbook för firmwarebeslut för att identifiera ändringar som påverkar installerad build och målversion. Ta med Clientless Access, VPN portal, RDP och den autentiseringsmetod som används i granskningen. Upprepa det fullständiga positiva och negativa testet efter uppgraderingen.

RDP har två aktuella begränsningar som inte bör behandlas som konfigurationsfel:

Urklipp stöds inte i Clientless RDP-bookmarks sedan SFOS 19. Copy-and-paste mellan den lokala enheten och RDP-sessionen är därför inte en tillförlitlig arbetsmetod.
Muspekaren kan visas som ett kryss eller X i HTML5-RDP-sessionen i stället för som en normal pil. Sophos anger för närvarande ingen lösning.

Om urklipp, inbyggda RDP-funktioner, bredare nätverksåtkomst eller personliga målkonton på en server som kräver NLA utan lagrade Credentials är obligatoriska är Clientless SSL VPN inte rätt genväg. Då bör åtkomsten avsiktligt flyttas till Sophos Connect, RD Gateway, PAM, en Jump Host eller ZTNA.