Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access

Administrativ åtkomst och fjärråtkomstportaler bör inte bara skyddas med användarnamn och lösenord. Med Multi-Factor Authentication, förkortat MFA, kräver Sophos Firewall också en andra faktor, till exempel en tidsbaserad OTP-kod från en autentiseringsapp.

För det bredare hardening-sammanhanget passar hubben Sophos Firewall Hardening: best practices för säker konfiguration.

Artikeln förklarar hur man planerar, aktiverar och testar MFA förnuftigt. Fokus ligger på WebAdmin, VPN portal och fjärråtkomst.

Klassificering och åtkomstskydd

MFA är ett viktigt skydd för inloggningar, men bara en byggsten. Först bör det framgå vilken åtkomst som skyddas, vilken identitetskälla som ligger bakom och om tjänsten ens måste vara tillgänglig från respektive nätverk.

Vilken autentiseringsartikel passar?

MFA är bara en del av åtkomstsäkerheten. Beroende på målet är det första att tänka på tillgänglighet, identitetskälla, portal, VPN-klient eller publicerad webbapplikation:

• Planera MFA för WebAdmin, VPN Portal eller Remote Access: Den här artikeln.
• Begränsa WebAdmin, SSH, User Portal, VPN Portal, DNS eller Ping: Sophos Firewall Säker åtkomst: konfigurera Device Access korrekt.
• Använd Microsoft Entra ID SSO för Sophos Connect eller VPN Portal: Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal.
• Jämför Sophos Connect, SSL VPN, IPsec eller ZTNA som en fjärråtkomstmodell: Sophos Connect eller SSL VPN: Vilken fjärråtkomstlösning är lämplig?.
• Kontrollera Sophos Connect Client-versionen, OTP-återanslutningar eller SSO-provisionering: Kontrollera och uppdatera Sophos Connect Client-versionen på ett säkert sätt.
• Skydda en WAF-publicerad webbapplikation med MFA: Skydda Sophos Firewall WAF med MFA.
• Ansluta klassiskt Active Directory som användarkälla: Lägga till Active Directory på Sophos Firewall.
• Förbered supportåtkomst för Avanet eller Sophos på ett kontrollerat sätt: Konfigurera Avanet supportåtkomst till Sophos Firewall.
• Prioritera hälsokontrollresultat för MFA eller portalåtkomst: Sophos Firewall använd hälsokontrollen korrekt.

Denna separation är viktig: MFA skyddar inloggningar, men den begränsar inte automatiskt från vilka nätverk WebAdmin, SSH eller portaler kan nås. Omvänt ersätter en smal Device Access-regel inte en andra faktor. Bra åtkomstsäkerhet kombinerar nåbarhet, identitetskälla, MFA, loggning och testad reservåtkomst.

När MFA är vettigt

MFA bör vara aktiverad åtminstone för alla konton som tillåts åtkomst till administrativa gränssnitt eller fjärråtkomstfunktioner.

Typiska användningsområden:

• Registrering på WebAdmin.
• Registrering på portalen VPN.
• SSL VPN eller Sophos Connect fjärråtkomst.
• Åtkomst för externa tjänsteleverantörer.
• Åtkomst för privilegierade administratörer.

MFA minskar risken för stulna lösenord, men ersätter inte lämpliga åtkomstbegränsningar. SSH, WebAdmin och portaler bör fortfarande endast vara tillgängliga från pålitliga nätverk eller via tydligt definierad hanteringsåtkomst.

MFA är inte en ersättning för Device Access

MFA skyddar inloggningsprocessen. Det minskar dock inte attackytan för en tjänst. Om WebAdmin, User Portal, VPN Portal eller SSL VPN är tillgängliga från hela Internet, kommer dessa tjänster att fortsätta att drabbas av bots, skannrar och brute force-försök. Detta skapar onödiga loggposter, supportinsatser och risker.

Det är därför du alltid bör kombinera MFA med tillgänglighetskontroller:

• Enhetsåtkomst: Bestäm i princip vilka tjänster som är tillgängliga i vilken zon.
• Undantagsregel för lokal tjänst ACL: WebAdmin, SSH eller portaler tillåter specifikt endast från hanteringsnätverk, VPN-nätverk eller kända källadresser.
• MFA: Ytterligare säkerhet för inloggningar om giltig åtkomstdata har äventyrats.
• Loggning och Syslog: Gör misslyckade försök, utrullningsproblem och attacker spårbara.

Om en portal behöver vara tillgänglig över hela världen bör du åtminstone kombinera MFA, giltiga certifikat, loggning, restriktiva användargrupper och regelbundna granskningsprocesser. För allmänt tillgängliga brandväggstjänster är frågan inte bara om en angripare kan logga in, utan om tjänsten överhuvudtaget behöver vara allmänt tillgänglig.

Begränsa dessutom åtkomsten med ACL-regler

Innan du aktiverar MFA bör du kontrollera varifrån portalerna WebAdmin, SSH, User Portal och VPN faktiskt kan nås.

Menysökvägen är System > Administration > Device access.

Det finns två relevanta områden:

• Lokal service ACL: Grundläggande åtkomst per zon, till exempel LAN, VPN eller WAN.
• Lokal tjänst ACL undantagsregel: Riktade undantag för individuella källnätverk, värdar eller supportåtkomst.

För produktiva miljöer bör man i allmänhet inte aktivera WebAdmin och SSH för WAN-zonen. Det är bättre att begränsa det till:

• en hanterings-IP,
• ett administratörsnätverk,
• ett VPN nätverk,
• en dedikerad supportvärd,
• eller ett tydligt definierat FQDN/värd undantag.

Om SSH krävs bör åtkomsten begränsas ytterligare och helst användas med en publik nyckel. Detta passar med Sophos Firewall anslut via SSH.

⚠️ MFA skyddar mot stulen åtkomstdata, men inte mot onödigt exponerade tjänster. WebAdmin, SSH och portaler bör aldrig vara mer allmänt tillgängliga än nödvändigt.

Välj variant MFA och planera lanseringen

Före aktivering bör du bestämma om den lokala Sophos OTP-funktionen är tillräcklig eller om en befintlig MFA-plattform ska integreras via RADIUS, NPS eller SSO. Utrullningen planeras sedan så att administratörer och användare inte låser sig ute.

Krav

Innan aktivering bör du kontrollera:

• Brandväggssystemets tid är korrekt.
• En fungerande NTP-server är konfigurerad.
• Användarna finns lokalt, via AD, LDAP, RADIUS eller annan autentiseringstjänst som stöds.
• De berörda användarna kan logga in på User Portal eller respektive tjänst.
• Minst en administrativ reservåtkomst är tillgänglig.

⚠️ Du måste vara särskilt försiktig med Admin-MFA. MFA bör inte aktiveras direkt för alla administratörer utan att först kontrollera efter en testanvändare, en andra administratör och reservåtkomst. En felaktig MFA-konfiguration kan resultera i att du låser dig utanför portalen WebAdmin eller VPN.

Sophos MFA eller extern MFA?

Det finns i princip två sätt för MFA på Sophos Firewall: du använder den lokala OTP-funktionen för brandväggen eller ansluter en extern MFA-lösning via RADIUS eller SSO. Båda varianterna är legitima, men löser olika problem.

Den lokala MFA av Sophos Firewall hanterar OTP-tokens direkt på brandväggen. Detta är vanligtvis det snabbaste sättet att säkra WebAdmin, portaler och fjärråtkomst med en andra faktor. Ingen ytterligare RADIUS-infrastruktur eller identitetsleverantör krävs.

Fördelar med Sophos egen MFA:

• Ingen ytterligare RADIUS eller identitetsleverantörsintegration krävs.
• Snabb utrullning för lokala användare och små miljöer.
• Tokens kan genereras och hanteras direkt på brandväggen.
• Lämplig för WebAdmin, User Portal, VPN Portal, SSL VPN fjärråtkomst och IPsec fjärråtkomst.

Nackdelar:

• Användare kan behöva underhålla en extra autentiseringsapp eller token.
• Token är separat från Microsoft 365, Entra ID eller andra befintliga MFA-processer.
• Beroende på inloggningsmasken finns det inget separat OTP-fält.
• För vissa portaler måste användare ange lösenordet och token efter varandra.

I större miljöer kan en extern MFA-lösning vara mer vettig. Typiska varianter är RADIUS med en MFA-kompatibel backend, Microsoft NPS med Entra-MFA tillägg eller ett annat RADIUS-kompatibelt MFA system. Beroende på SFOS-versionen och fjärråtkomstmodellen kan Microsoft Entra ID SSO för WebAdmin, VPN Portal samt Sophos Connect med SSL VPN eller IPsec VPN också passa.

Den viktiga skillnaden är: Entra ID är inte bara samma mekanism som den lokala Sophos OTP-funktionen. Antingen är Entra MFA indirekt integrerad i autentiseringsflödet via RADIUS/NPS eller så används en SSO-modell om tjänsten och klienten som används stödjer detta.

Användare tycker ofta att en extern MFA är bekvämare eftersom de använder samma MFA som de gör för Microsoft 365 eller andra företagstjänster. Detta skapar inte en andra MFA värld med en extra app, ytterligare token och olika inloggningsbeteende.

Nackdelen med en extern lösning är den högre komplexiteten. RADIUS, grupper, timeouts, utmaningsbeteende och fallback måste noggrant planeras och testas.

• Sophos OTP på brandväggen: Snabbinstallerad, utan ytterligare infrastruktur och hanteras direkt i SFOS. En extra token skapas för detta, separat från Microsoft 365 eller Entra ID; Beroende på portalen måste lösenord plus OTP finnas i ett fält. Typiskt för små miljöer, lokala användare och snabb härdning av WebAdmin eller VPN.
• Extern MFA via RADIUS: Befintlig MFA-plattform kan användas och centrala användarprocesser behålls. För att göra detta måste RADIUS, NPS, timeouts, grupper och klientbeteende testas ordentligt. Typiskt för AD/Microsoft 365-miljöer med många VPN-användare.
• Entra ID SSO: Bekant Microsoft-inloggning, bättre användarupplevelse och centrala identitetsprocesser. Alla scenarion kan inte användas på samma sätt; det beror på SFOS version, tjänst och klient. Typiskt för WebAdmin, VPN Portal och Sophos Connect om SSO passar driftsmodellen.

Beslutsstöd

Den korrekta MFA-varianten beror mindre på brandväggen än på den befintliga identitetsoperationen.

• Liten miljö med lokala brandväggar: Sophos egen OTP-funktion räcker ofta.
• Microsoft 365-miljö med befintlig Entra MFA: Validera extern MFA via RADIUS/NPS eller Entra ID SSO så att användare inte behöver underhålla två MFA världar.
• Många externa tjänsteleverantörer: Egen användargrupp, MFA krav, tydlig term och regelbunden granskning.
• Kritisk administratörsåtkomst: MFA plus Device Access, kombinera hanteringsnätverk, reservadmin och loggning.
• Många fjärråtkomstanvändare: Planera för pilotgrupp, helpdeskprocess, tokenåterställning och klienttestning innan bred utrullning.

Om Microsoft Entra ID planeras direkt som en SSO-källa för VPN Portal eller Sophos Connect, passar även Set up Microsoft Entra ID SSO for Sophos Connect och VPN Portal. Detta är en annan driftsmodell än den klassiska Sophos OTP-funktionen och bör inte likställas med RADIUS-MFA utan testning.

MFA plan

För produktiva miljöer är det vanligtvis bättre att först aktivera MFA för en liten pilotgrupp.

This order has proven successful:

1. Förbered testanvändare eller pilotgrupp.
2. Kontrollera brandväggens NTP och tid.
3. Aktivera MFA för testområdet.
4. Testa inloggning med autentiseringsappen.
5. Inkludera först då ytterligare användargrupper.

En separat användargrupp rekommenderas för tjänsteleverantörer. Detta gör att MFA kan upprätthållas specifikt och åtkomst tas bort lättare senare.

För administratörer bör du också planera:

• Vem är den första testadministratören?
• Finns det en andra administratör med fungerande åtkomst?
• Är åtkomst möjlig via ett hanteringsnätverk eller VPN?
• Är standard admin skyddad separat?
• Är det dokumenterat hur man ersätter en förlorad token?

Aktivera MFA och ställ in tokens

Om krav, grupper och fallback förtydligas kan MFA först aktiveras för en pilotgrupp. Först efter framgångsrika tester bör du inkludera ytterligare användare eller administratörer.

Aktivera MFA på Sophos Firewall

MFA-inställningarna finns under Authentication > Multi-factor authentication i nuvarande SFOS-versioner. I äldre gränssnitt eller beroende på navigering kan området fortfarande visas under Configure > Authentication > Multi-factor authentication.

1. Registrera dig på WebAdmin av Sophos Firewall.
2. Öppna Autentisering.
3. Växla till fliken Multifaktorautentisering.
4. För Engångslösenord (OTP) väljer du vem MFA ska gälla för:
   • Ingen OTP: MFA är inaktiverad.
   • Alla användare: MFA gäller för alla användare.
   • Specifika användare och grupper: MFA gäller endast utvalda användare eller grupper.
5. Aktivera Generera OTP-token med nästa inloggning om användare ska ställa in sin token själva nästa gång de loggar in.
6. Under Kräv MFA för välj för vilka tjänster MFA krävs.
7. Spara konfigurationen med Apply.

Typiska alternativ under Kräv MFA för är:

• Användarportal
• Webbadministratörskonsol
• VPN portal
• SSL VPN fjärråtkomst
• IPsec fjärråtkomst
• Webbapplikationsbrandvägg

Beroende på miljön kan MFA användas på olika sätt för enskilda tjänster eller användargrupper. För administratörer bör du tillämpa MFA konsekvent, men testa det på ett kontrollerat sätt först.

Om webbapplikationer publiceras via webbserverskydd krävs också en lämplig WAF-autentiseringspolicy. Processen är i Sophos Firewall säker WAF med MFA.

Förbered för utbyggnad och drift

MFA är inte bara en switch i brandväggen. Efter aktivering ändras inloggningsbeteende, supportfrågor och akutåtkomst. Därför bör det, innan den breda utrullningen, vara klart vem som utfärdar tokens, vem som återställer förlorade tokens och hur reaktionen kommer att vara utanför kontorstid.

Dessa punkter har visat sig användbara för drift:

• Testpilotgrupp med riktiga användare, inte bara administratörer.
• Dokumentera en andra administratör och bryt glasåtkomst.
• Informera helpdesk om lösenord+OTP-beteende.
• Ställ in token-återställningsprocess för nya smartphones eller förlorade enheter.
• Kontrollera Log Viewer och autentiseringsloggar efter lanseringen.
• Testa extern MFA via RADIUS med realistiska timeouts.
• Kontrollera Device Access och ACL undantag regelbundet.

Speciellt med fjärråtkomst bör du testa MFA tillsammans med de berörda VPN-reglerna, användargrupperna och klientprofilerna. En fungerande WebAdmin-inloggning bevisar inte automatiskt att SSL VPN, IPsec Remote Access eller Sophos Connect fungerar likadant.

Planera fallback och krossa glas

MFA ökar säkerheten, men kan också låsa ut legitima administratörer om token, tid, autentiseringsserver eller grupper inte matchar. Det är därför som en reservplan behövs innan aktivering.

Åtminstone dessa punkter bör dokumenteras:

• Vem har en andra testad administratörsåtkomst?
• Är åtkomst möjlig från ett hanteringsnätverk eller admin VPN?
• Är den lokala standarden admin skyddad som ett nödkonto men används inte för dagligt bruk?
• Hur återställer man en förlorad eller trasig OTP-token?
• Vem kan återställa tokens för administratörer?
• Hur reagerar du utanför kontorstid?
• Finns det en aktuell backup före ändringen?

Tillbakagången får inte innebära att oskyddad administratörsåtkomst förblir permanent tillgänglig från Internet. Det är bättre att ha ett nödkonto med tydlig dokumentation, en smal åtkomstväg och regelbundna granskningar.

MFA för standardadmin

Den lokala standardanvändaren admin är ett specialfall. MFA för denna användare aktiveras inte direkt på fliken Multifaktorautentisering.

Menysökvägen är System > Administration > Device access.

Där kan du aktivera MFA för standardadmin. Du bör bara göra detta om:

• systemtiden är korrekt,
• en andra administratör testades,
• åtkomst fungerar via ett pålitligt hanteringsnätverk,
• och det är tydligt hur man kan återfå administrativ åtkomst i en nödsituation.

Följande gäller för standard admin: Avaktivera den inte, gör den inte tillgänglig oskyddad på Internet och använd den inte som en vanlig dagsanvändare. Det är ett krossglas eller nödkonto.

Andra administratörer bör inte anta att de kan redigera eller ta bort standard admins MFA token som en vanlig användartoken. Denna åtkomst måste medvetet planeras och testas via din egen enhetsåtkomstväg.

Ställ in tokens för användare

När den är aktiverad måste användaren ställa in sin andra faktor. Om Generera OTP-token med nästa inloggning är aktivt loggar användaren in på User Portal- eller VPN-portalen och skannar QR-koden med en autentiseringsapp.

Lämpliga appar inkluderar:

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Andra TOTP-kompatibla autentiseringsappar.

Koden som genereras är tidsbaserad. Om tiden på brandväggen eller smarttelefonen skiljer sig markant kommer inloggningen att misslyckas.

Om User Portal är inaktiverad kanske användare inte kan ställa in sina tokens själva. I det här fallet måste du antingen tillhandahålla portalen på ett kontrollerat sätt eller förbereda tokens administrativt.

Under Authentication > Multi-factor authentication > Issued tokens kan du se vilka användare som redan har genererat eller tilldelats en token. Tokens kan kontrolleras, raderas eller förberedas manuellt vid behov. En specialregel gäller för standarden admin: andra administratörer kan inte ändra eller ta bort dess token som vanliga användartokens. Denna token hanteras via sin egen default-admin-MFA-sökväg.

Tokenalgoritm och appbyte

Sophos Firewall stöder hashalgoritmerna SHA1, SHA256 och SHA512 för OTP-tokens. SFOS-versioner före 22.0 använder SHA1 för MFA; från SFOS 22.0 bör nya eller migrerade tokens testas med SHA256 eller SHA512. Detta får inte ställas in blint: den valda hashalgoritmen måste stödjas av den autentiseringsapp som används.

Sophos säger uttryckligen att en app måste stödja den valda algoritmen. Om en app inte stöder SHA256 eller SHA512 korrekt kan QR-koden skannas, men inloggningen misslyckas fortfarande. Det är därför algoritmen alltid hör hemma i pilottestet, speciellt när Microsoft Authenticator, lösenordshanteraren TOTP, Google Authenticator eller Sophos Intercept X for Mobile används på ett blandat sätt.

Dessa punkter är viktiga för driften:

• Planerar inte längre nya tokens med gamla appantaganden.
• Använd en autentiseringsapp som stöder den valda hashalgoritmen.
• Om du byter app eller tappar bort din smartphone, radera den gamla token och få QR-koden om.
• Använd bara hårdvarutokens om algoritmen, tidssteget och hemligheten kan hanteras korrekt.
• Testa en pilotgrupp före en SHA256-/SHA512-migrering i stället för att byta alla tokens samtidigt.
• Befintliga SHA1-tokens kan tas bort och återskapas på ett kontrollerat sätt under en migrering.

Den gamla Sophos Authenticator-appen ska inte längre planeras som ny standardapp; enligt Sophos är den End of Life sedan 31 juli 2022. I många miljöer är Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password eller Bitwarden mer realistiska alternativ. Appens varumärke är mindre viktigt än om TOTP, hashalgoritm, backup/återställningsbeteende och helpdeskprocess passar ihop.

Om en användare byter smartphone bör den gamla token inte bara fortsätta att existera tyst. En tydlig process är bättre: kontrollera identitet, ta bort gammal token, generera ny QR-kod, testa inloggning med korrekt och felaktig OTP och dokumentera processen.

Viktig anmärkning om lösenord och tokens

Beroende på Sophos-tjänsten finns det inget separat formulärfält för OTP-koden. Detta leder alltid till förvirring, särskilt med VPN-portalen eller fjärråtkomstinloggningar.

I dessa fall måste användaren ofta ange lösenordet och OTP-koden efter varandra.

Exempel:

Losenord:  MittSakraLosenord
OTP-kod:   123456
Inmatning: MittSakraLosenord123456

Detta bör tydligt kommuniceras till användarna innan lanseringen. Annars ser det ut för användaren som om lösenordet är felaktigt, även om endast OTP-koden saknas.

Detta beteende bör testas och dokumenteras innan lanseringen eftersom det uppfattas olika beroende på tjänst och inloggningsmask.

Testa och kontrollera funktion

Ett lyckat WebAdmin-test räcker inte. Varje påverkat inloggningsgränssnitt måste testas separat eftersom portalen, VPN-klienten, användargruppen och autentiseringsservern kan reagera olika.

Testregistrering

MFA bör testas först med en användare som inte är den enda administratören.

Dessa punkter bör kontrolleras:

• Registrering på WebAdmin.
• Registrering på portalen VPN.
• Loggar in på fjärråtkomsttjänsten.
• Beteende vid felaktig OTP-kod.
• Beteende efter att en OTP-kod löper ut.
• Åtkomst med en användare som inte är i gruppen MFA.
• Logga in med lösenord och bifogad OTP-kod.
• Åtkomst via schemalagda ACL-regler.

Först när dessa tester är framgångsrika bör MFA rullas ut till andra grupper.

Testmatris efter tjänst

Ett MFA-test bör inte bara bestå av en lyckad WebAdmin-inloggning. Beroende på tjänsten gäller andra portaler, grupper, profiler och loggfiler. Denna matris hjälper till att undersöka de viktigaste fallen separat:

• WebAdmin: Logga in admin användare med korrekt och felaktig OTP. Korrekt OTP tillåter åtkomst, felaktig OTP avvisas och loggas.
• Standard admin: Testa den separata MFA-vägen under System > Administration > Device access. Nödkontot är skyddat, men en dokumenterad break-glass-väg finns fortfarande.
• User Portal: Användaren ställer in tokens själv. QR-koden visas endast för behöriga användare, token fungerar då vid inloggning.
• VPN Portal: Användaren loggar in med lösenord och OTP. Inloggningen fungerar med ett dokumenterat inmatningsformat och är synligt i Log Viewer.
• SSL VPN / Sophos Connect: Importera profil eller återupprätta anslutningen. MFA frågas i den verkliga klienten, inte bara i webbläsaren.
• IPsec Fjärråtkomst: Kontrollera grupp och autentiseringsmetod. MFA gäller för samma grupp som också är tillåten i fjärråtkomstkonfigurationen.
• Extern MFA via RADIUS: Testa push, utmaning eller token med riktig klient. Timeout är tillräcklig, utmaningsbeteende passar klienten och fel är synliga på RADIUS-servern.

Varje test bör också kontrollera om Device Access eller en lokal tjänst ACL-regel avsiktligt tillåter tjänsten. Om token fungerar, men portalen är tillgänglig från fel nätverk, löser MFA-konfigurationen bara delvis problemet.

Loggar och driftkontroll

Efter utrullningen bör du kontrollera om MFA-händelser kan spåras under drift. Detta är viktigt för supportärenden, säkerhetsgranskningar och incidentrespons.

Användbara kontrollpunkter:

• Sök efter autentiseringshändelser i Loggvisaren.
• Skilj misslyckade inloggningar från felaktigt lösenord, felaktig OTP och utgången OTP.
• Dokumentera VPN portal- och fjärråtkomsttest med tid och användare.
• För extern RADIUS, kontrollera även RADIUS-server, NPS-loggar eller identitetsleverantörsloggar.
• För längre lagring, planera för Central Reporting eller Syslog/SIEM.

För lokala loggfiler och servicemappning är Sophos Firewall Felsökning: tjänster och loggar lämplig. Om autentisering och portalhändelser ska utvärderas långsiktigt, passar Sophos Firewall syslog till SIEM.

Med Sophos Central, Syslog eller SIEM bör du inte bara kontrollera lyckade inloggningar efter lanseringen. Upprepade misslyckade försök på WebAdmin, User Portal, VPN Portal och SSL VPN är särskilt intressanta eftersom de visar om en tjänst är onödigt brett tillgänglig eller om användare kämpar med OTP-formatet.

Felsökning

OTP-kod accepteras inte

Kontrollera först brandväggens systemtid och smarttelefonens tid. TOTP är tidsberoende. Även en betydande avvikelse kan leda till att giltiga koder avvisas.

Du kan kontrollera utfärdade tokens under Authentication > Multi-factor authentication. Om en enskild token missas upprepade gånger bör du inte omedelbart ändra hela MFA-konfigurationen. Kontrollera först token-tidsdrift, app som används, hashalgoritm och tidssteg.

Användaren ser inte QR-koden

Användaren måste vara berättigad till MFA och logga in på rätt portal. Dessutom bör det kontrolleras om användaren hittas via den förväntade autentiseringskällan.

Om User Portal är inaktiverad kanske användaren inte kan ställa in token själv. Portalen måste då göras tillfälligt tillgänglig eller så måste token skapas administrativt.

Portalen kan inte nås via Device Access

Om användare inte kan ställa in sin token trots att MFA har aktiverats korrekt, bör man inte ta bort token först. Ofta kan den nödvändiga portalen inte nås från det aktuella nätverket via System > Administration > Device access eller en ACL-regel för lokal tjänst.

Kontrollera först:

• Vilken portal används för tokeninstallation?
• Vilken zon eller källa kommer användaren ifrån?
• Är åtkomst avsiktligt tillåten eller av misstag blockerad?
• Finns det ett snävare ACL-undantag istället för en bred version?

Administratören är utelåst

Använd i det här fallet den förberedda reservåtkomsten. Om en reserv inte finns måste åtkomsten bedömas via konsol, support eller återställningsvägar beroende på situationen.

MFA fungerar inte för fjärråtkomst

Kontrollera om fjärråtkomstkonfigurationen använder samma användargrupp som MFA aktiverades för. Ofta beror felet inte på MFA i sig, utan på olika grupper i VPN och autentiseringsregler.

Klientprofiler måste också matcha den aktuella konfigurationen. Efter ändringar av VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO eller RADIUS, bör berörda Sophos Connect-profiler återimporteras eller omdistribueras.

Användaren anger endast lösenordet

Om ett separat OTP-fält inte visas måste användaren ange lösenordet och OTP-koden efter varandra. Detta är ett av de vanligaste supportfallen efter aktivering av Sophos OTP.

Extern MFA fungerar inte tillförlitligt

För RADIUS-baserade MFA-lösningar måste timeouts, utmaningsbeteende och grupper passa snyggt. Om Push-MFA, Call-MFA eller utmaningssvar används bör du testa hela inloggningsprocessen med den berörda klienten.

Portalgränsen är också viktig: inte alla Sophos-inloggningar stöder varje RADIUS-utmaningsbeteende lika bra. I synnerhet bör VPN Portal, SSL VPN, Sophos Connect, WebAdmin och Captive Portal testas separat med riktiga klienter. Ett lyckat RADIUS-test i serverkonfigurationen är inte tillräckligt bevis på produktiv fjärråtkomstinloggning.

MFA har aktiverats för fel grupp

Om MFA fungerar för vissa användare och inte andra, bör du först jämföra grupper tekniskt. Inte bara de synliga visningsnamnen är relevanta, utan också de faktiskt importerade eller matchade grupperna från AD, LDAP, RADIUS eller Entra ID. En användare kan framgångsrikt autentisera och ändå inte hamna i gruppen som kräver MFA.

Operationell checklista och rekommendation

Efter teknisk aktivering behöver MFA en enkel driftprocess: Vem återställer tokens, vem kontrollerar loggar och hur kontrolleras att portaler inte är onödigt allmänt tillgängliga?

Checklista för verksamheten

• Systemtid och NTP kontrolleras.
• Pilotgrupp definierad och testad.
• MFA är inte direkt aktiverad för alla administratörer samtidigt.
• Andra administratörs- och brytglasåtkomst dokumenterad.
• Device Access och Local Service ACL testade för WebAdmin, User Portal, VPN portal och SSL VPN.
• Åtkomst från tillåtna och ej tillåtna källnät har testats.
• Användaren informerad om lösenord+OTP-beteende.
• Token-återställningsprocess för förlorade smartphones dokumenterad.
• Autentiseringsapp, hashalgoritm och tokenmigrering dokumenterad.
• Fjärråtkomst testad med riktiga kunder och aktuella profiler.
• RADIUS/Entra timeouts testade om extern MFA används.
• Loggar och centrallager kontrolleras.

Driftsrekommendation

MFA bör vara standard för administrativ åtkomst. MFA är särskilt viktigt för WebAdmin, VPN portalen och alla användare med fjärråtkomstbehörighet.

För små miljöer räcker ofta Sophos egen OTP-funktion. I Microsoft 365 eller Entra ID-miljöer kan en extern MFA över RADIUS vara bekvämare eftersom användare inte behöver lära sig en andra MFA värld.

Oavsett MFA-varianten gäller följande: först begränsa åtkomsten med ACL-regler, testa Admin-MFA noggrant, informera användarna om lösenord + token och först sedan rulla ut det brett.

FAQ