Sophos Protected Browser: felsöka åtkomst och inloggning

Den här runbooken hjälper till att avgränsa åtkomstproblem med Protected Browser och agentlösa ZTNA-RDP-/SSH-resurser. Öppna Meine Produkte > Protected Browser i Sophos Central och börja med det synliga symptomet. Åtgärda endast den orsak som bekräftas under kontrollerna. Omfattande ändringar av DNS, användarkatalogen eller ZTNA gör diagnostiken svårare.

Snabbväg: Om det redan misslyckas att lägga till eller redigera en resurs ska e-postadresserna för alla medlemmar i den aktuella användargruppen kontrolleras. Om en befintlig resurs inte kan nås utan ett specifikt felmeddelande ska ZTNA-användarportalen testas först, följt av DNS-namnuppslagning för ZTNA-gatewayens FQDN. Vid ”Netzwerk nicht erreichbar” eller ”Verbindung konnte nicht hergestellt werden” ska identitetsleverantören som är konfigurerad i ZTNA jämföras direkt med inloggningsmetoden för Protected Browser-sessionen. Om inloggningen till Protected Browser misslyckas ska åtkomsten till Self Service Portal och en e-postadress som är unik mellan klientorganisationerna kontrolleras. Meddelandet ”Hostschlüsselüberprüfung fehlgeschlagen” hanteras separat.

Förutsättningar och säkra arbetsgränser

De beskrivna kontrollerna kräver en redan konfigurerad Protected Browser- och ZTNA-miljö samt en tydligt identifierad berörd användare. Om menyer eller behörigheter saknas går det inte att dra slutsatsen att orsaken är en viss licens eller roll. I så fall ska kontrollen lämnas över till ansvarig Sophos Central-administratör.

För användarkontrollen i Sophos Central krävs åtkomst till Meine Umgebung > Benutzer und Gruppen > Benutzer. För anslutningstestet måste både den faktiskt konfigurerade ZTNA-gatewayens FQDN och gatewaytypen vara kända: Sophos Cloud Gateway eller lokal gateway. Ersätt platshållaren i kommandot med ZTNA-gatewayens FQDN, inte med namnet på en RDP-/SSH-målresurs.

Ändra endast ett värde i taget under diagnostiken och testa sedan igen med samma användare och samma enhet. Om en förutsättning är oklar eller åtkomst till användarhanteringen saknas ska diagnostiken stoppas och ärendet lämnas över till ansvarig administratör för Sophos Central, katalogtjänsten eller ZTNA.

Felsökning efter symptom

Det går inte att lägga till eller redigera en agentlös RDP-/SSH-resurs

Trolig orsak: Minst en medlem i den aktuella användargruppen saknar en giltig e-postadress. Det kan påverka både en ZTNA-resurs och en RDP-/SSH-resurs i en Protected Browser-programgrupp.

Kontroll:

1. Öppna Meine Umgebung > Benutzer und Gruppen > Benutzer.
2. Kontrollera alla användare i gruppen som ska tilldelas resursen eller programgruppen i kolumnen E-Mail.

Förväntat resultat: Alla användare i den berörda gruppen har en giltig e-postadress. En tom post bekräftar feltillståndet.

Säker åtgärd: Lägg till den saknade adressen i den auktoritativa katalogtjänsten. Lägg endast till den direkt i Sophos Central för användare som har skapats manuellt där. Ändra inte befintliga adresser på grundval av antaganden.

Validera igen: Försök lägga till eller redigera samma resurs igen utan att ändra gruppen. Om det fortfarande misslyckas trots att kolumnen E-Mail är fullständigt ifylld är denna orsak inte bekräftad. Ändra inte fler identitetsuppgifter, utan dokumentera resurstypen, gruppen, tidpunkten och det synliga meddelandet och eskalera ärendet.

Agentlös RDP-/SSH-resurs kan inte nås via Protected Browser

Trolig orsak: Enheten kan inte slå upp ZTNA-gatewayens FQDN korrekt. Den första avgränsningspunkten är dock ZTNA-användarportalen: om inte heller den kan nås via Protected Browser ligger problemet före den enskilda RDP-/SSH-resursen.

Kontroll:

1. Försök öppna ZTNA-användarportalen via Protected Browser på samma enhet och som samma användare.
2. Kör en DNS-fråga på den berörda enheten om portalen inte kan nås:

nslookup <ZTNA-Gateway-FQDN>

Ersätt <ZTNA-Gateway-FQDN> med det faktiskt konfigurerade gatewaynamnet. nslookup är ett skrivskyddat test och ändrar ingen konfiguration.

Förväntat resultat: För en Sophos Cloud Gateway slås gatewaynamnet upp till gatewayproxyns adress. För en lokal gateway slås det upp till adressen till ZTNA-gatewayen som är konfigurerad på organisationens DNS-server. Jämför svaret med det faktiskt konfigurerade målet för den aktuella gatewaymodellen. Om namnuppslagningen misslyckas måste DNS-konfigurationen kontrolleras. Ett annat svar bekräftar inte ett fel förrän det avviker från det konfigurerade målet. Om det avsedda målet är okänt ska DNS inte ändras; lämna över kontrollen till den DNS-/ZTNA-ansvariga.

Säker åtgärd: Korrigera DNS-konfigurationen enligt den avsedda DNS-/ZTNA-processen. Rätt zon och mål beror på gatewaymodellen. Gör därför inga allmänna DNS-ändringar här.

Validera igen: När den DNS-/ZTNA-ansvariga har bekräftat en korrigering enligt den avsedda processen ska samma nslookup-fråga köras igen. Öppna därefter ZTNA-användarportalen och testa först sedan den ursprungliga RDP-/SSH-resursen. Om DNS-svaret är det förväntade och portalen kan nås, men resursen fortfarande inte kan nås, ska dessa två godkända kontroller dokumenteras och den resursspecifika ZTNA-undersökningen eskaleras.

”Netzwerk nicht erreichbar” eller ”Verbindung konnte nicht hergestellt werden”

Trolig orsak: ZTNA använder en identitetsleverantör som Okta eller Entra ID, men användaren är inloggad i Protected Browser med sitt Sophos ID eller som lokal användare. De angivna meddelandena kan då visas vid åtkomst till ett SSH- eller RDP-program bakom ZTNA-gatewayen.

Kontroll: Ta reda på vilken identitetsleverantör som är konfigurerad i ZTNA och jämför den med inloggningsmetoden för den aktuella Protected Browser-sessionen.

Förväntat resultat: Orsaken är bekräftad om ZTNA använder en identitetsleverantör men Protected Browser-sessionen inte autentiserades via den leverantören.

Säker åtgärd: Avsluta den berörda sessionen och logga in användaren i Protected Browser via identitetsleverantören som är konfigurerad i ZTNA. Ändra inte ZTNA-identitetsleverantören för att kringgå ett enskilt inloggningsfel.

Validera igen: Öppna samma SSH- eller RDP-program i den nya autentiserade sessionen. Om meddelandet kvarstår trots att inloggningsmetoderna överensstämmer ska identitetsleverantör, användare, resurs och tidpunkt registreras och ärendet lämnas över till den ZTNA-ansvariga.

Användaren kan inte logga in i Protected Browser

Här ska två oberoende orsaker kontrolleras. Åtgärda dem inte samtidigt, så att det går att fastställa den faktiska orsaken.

Åtkomst till Self Service Portal saknas

Kontroll: Öppna Meine Umgebung > Benutzer und Gruppen > Benutzer och kontrollera kolumnen Rolle för den berörda användaren. Alternativt kan användarnamnet väljas och texten under profilbilden kontrolleras.

Förväntat resultat: Om användaren har åtkomst till Sophos Central Self Service Portal visas SelfService i kolumnen Rolle eller under profilbilden.

Säker åtgärd: Om SelfService saknas ska tilldelningen av åtkomst till Self Service Portal lämnas över till ansvarig Sophos Central-administratör.

Validera igen: Bekräfta först att SelfService visas och upprepa sedan inloggningen med exakt samma användare.

E-postadressen är kopplad till flera Sophos Central-konton

Kontroll: Fastställ om den berörda användarens e-postadress är tilldelad till flera Sophos Central-konton.

Förväntat resultat: Adressen får inte vara kopplad till flera Sophos Central-konton.

Säker åtgärd: Låt ansvarig klientorganisations- eller identitetsadministratör korrigera tilldelningen. Utan en bekräftad målklientorganisation får ingen användare tas bort och ingen produktionsadress ändras.

Validera igen: Upprepa inloggningen i Protected Browser när den unika tilldelningen har bekräftats. Om den fortfarande misslyckas ska SelfService, e-posttilldelningen, tidpunkten och det synliga meddelandet dokumenteras för eskaleringen.

SSH rapporterar ”Hostschlüsselüberprüfung fehlgeschlagen”

Trolig orsak: Nyckeln som lagras i SSH-klienten överensstämmer inte längre med värdens nyckel. Detta kan inträffa efter en legitim ändring, till exempel en ominstallation, men samma meddelande kan även tyda på en oväntad ändring.

Kontroll: Hämta det förväntade fingeravtrycket för värdnyckeln från den systemansvariga via en oberoende, betrodd kanal och jämför det med fingeravtrycket för rätt målvärd. Förlita dig varken på den misslyckade SSH-anslutningen eller på den nya nyckeln som erbjuds där. Om det förväntade fingeravtrycket inte har bekräftats oberoende, inte stämmer eller om ändringen inte kan förklaras ska processen stoppas här och eskaleras som en säkerhetsincident.

Förväntat resultat: Målvärden, den legitima nyckeländringen och det förväntade fingeravtrycket har bekräftats oberoende och entydigt.

Säker åtgärd: Fastställ före borttagning vilka poster som tas bort av funktionen i den använda SSH-klienten. Sophos anger Bekannte Hosts löschen som ett exempel, men bekräftar inte att funktionen endast tar bort den berörda värden. Utför ingen återställning utan eskalera om borttagningens omfattning är okänd eller om det förväntade fingeravtrycket inte kan bekräftas oberoende. Ta endast bort den lagrade nyckeln när omfattningen är klarlagd och fingeravtrycket bekräftat. Vid nästa anslutning ska endast den nyckel accepteras vars fingeravtryck överensstämmer med den oberoende bekräftelsen.

Validera igen: Upprätta anslutningen igen. Värdnyckelkontrollen ska lyckas med den nyligen accepterade nyckeln. Om meddelandet visas igen eller om nyckeln återigen ändras oväntat ska poster inte tas bort upprepade gånger. Eskalera i stället med värdnamn, tidpunkt och SSH-klient.

Återgång, eskalering och driftsgränser

Det finns ingen universell rollback för dessa problem. Den säkra vägen tillbaka är att undvika omfattande ändringar och dokumentera startvärdet för alla användartilldelningar som ändras specifikt. Om åtgärden inte löser problemet ska processen stoppas vid den aktuella eskaleringspunkten. Att ta bort kända SSH-värdnycklar är inte en allmän återställning och är endast acceptabelt när fingeravtrycket har bekräftats oberoende och borttagningens omfattning är känd.

För en intern eskalering eller eskalering till support ska åtminstone symptom, användare, enhet, resurstyp, gatewaymodell, ZTNA-gatewayens FQDN, tidpunkt och resultatet från den direkt relaterade kontrollen registreras. Inloggningsuppgifter, privata nycklar och token får inte ingå i ärendet.

Upprepa endast den kontroll som hör till den faktiskt utförda åtgärden eller den bekräftade överlämningen: lägga till eller redigera resursen igen efter en korrigering av e-postadressen; logga in efter bekräftad åtkomst till Self Service Portal eller unik kontotilldelning; öppna resursen efter inloggning via den konfigurerade identitetsleverantören; eller ansluta via SSH efter den kontrollerade återställningen av värdnyckeln. Efter överlämning till den DNS-/ZTNA-ansvariga ska nslookup, användarportalen och den ursprungliga resursen inte testas igen förrän den ansvariga har bekräftat en korrigering enligt sin process.

Avgränsning mot relaterade guider

Den här runbooken behandlar endast de Protected Browser-symptom som beskrivs här. Konfiguration av Protected Browser eller tillägget samt allmän DNS- och ZTNA-konfiguration hör hemma i respektive installationsguide. När en sådan konfiguration krävs ska ärendet lämnas över till ansvarig administratör.