Hoppa till innehållet
Avanet

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

Sophos Firewall

För den lokala OTP-funktionen öppnar man Authentication > Multi-factor authentication, väljer först Specific users and groups, aktiverar de tjänster som behövs och testar allt med en pilotgrupp. All users bör användas först efter godkända tester.

MFA skyddar WebAdmin, VPN Portal och fjärråtkomst mot att enbart stulna lösenord används. Det ersätter dock varken restriktiva åtkomstregler eller en testad nödåtkomst. Därför beskriver artikeln hela processen från säker aktivering till appval, återställning och felsökning.

Huvudproceduren konfigurerar lokal Sophos OTP. Längre fram jämförs RADIUS och Entra ID SSO som alternativ.

Aktivera Sophos OTP säkert

Före aktivering

Följande punkter bör klarläggas före den första ändringen:

  • Brandväggen använder korrekt tid under Administration > Time, helst via NTP.
  • Användare och grupper är tillgängliga lokalt eller via AD, LDAP eller en annan autentiseringsserver.
  • Det finns en pilotgrupp och en andra testad administratör.
  • Konsolen och återställningsproceduren för standardkontot admin är kända.
  • Det finns en aktuell säkerhetskopia och en dokumenterad process för återställning av token.

För klassisk Active Directory beskriver Lägg till Active Directory i Sophos Firewall hur användarkällan konfigureras.

Under Administration > Device access anger man från vilka zoner WebAdmin, User Portal, VPN Portal och andra lokala tjänster kan nås. Local service ACL exception rules begränsar åtkomsten ytterligare till hanteringsnät, VPN-nät eller kända källadresser. Skydda åtkomsten till Sophos Firewall: konfigurera Device Access korrekt beskriver denna härdning i detalj.

SSH tillhör inte de tjänster som skyddas av Sophos OTP. Begränsa SSH via Device Access och använd en publik nyckel där det är möjligt; proceduren beskrivs i Anslut till Sophos Firewall via SSH.

⚠️ MFA minskar risken med komprometterade lösenord, men minskar inte angreppsytan för en offentligt tillgänglig tjänst. WebAdmin, SSH och portaler bör aldrig exponeras bredare än nödvändigt.

Före negativa tester kontrollerar man också Administration > Admin and user settings > Login security > Block login. Flera avsiktligt misslyckade försök kan blockera källans IP-adress för WebAdmin, CLI, VPN Portal och User Portal. Det kan även låsa ute en reservadministratör i samma nätverk. Därför bör en andra källa eller konsolåtkomst finnas tillgänglig.

Konfigurera MFA för en pilotgrupp

  1. Logga in på WebAdmin och öppna Authentication > Multi-factor authentication.
  2. Under One-time password (OTP) väljer man först Specific users and groups.
  3. Öppna Add users and groups, välj pilotgruppen och tillämpa valet.
  4. Aktivera Generate OTP token with next sign-in om en autentiseringsapp ska användas. I SFOS 23 väljer man även Share QR code: Email skickar QR-koden till användarens e-postadress vid nästa inloggning på VPN Portal eller User Portal. Portals visar den i User Portal och VPN Portal efter nästa inloggning på VPN Portal, User Portal eller WebAdmin. Detta val gäller inte den guide för standardadministratören som beskrivs nedan.
  5. Under Require MFA for väljer man bara de inloggningsgränssnitt som faktiskt behövs.
  6. Under OTP hash algorithm väljer man en algoritm som stöds av den avsedda appen.
  7. Ändra de valfria OTP timestep settings endast om appen stöder samma tidssteg; standardvärdet är 30 sekunder.
  8. Spara med Apply.
Sophos Firewall Authentication > Multi-factor authentication med användarval, skyddade tjänster och OTP-hashalgoritm
På den här sidan anger man MFA-användare, skyddade tjänster och OTP-hashalgoritm. De visade värdena All users och SHA1 är inga rekommendationer för utrullningen.

Slutför processen direkt med en pilotanvändare efter Apply: beroende på vald tjänst loggar användaren först in på User Portal eller VPN Portal med enbart lösenordet, registrerar QR-koden eller Base32-nyckeln i autentiseringsappen och öppnar därefter en ny session med <password><passcode>. En avsiktligt felaktig kod måste avvisas och försöket ska visas i Log viewer. Överväg All users först efter detta positiva och negativa test.

Användaralternativen betyder:

  • No OTP: MFA är inaktiverat.
  • All users: MFA gäller för alla användare; använd alternativet först efter piloten.
  • Specific users and groups: MFA gäller endast för valda konton eller grupper.

För externt autentiserade användare träder borttagning ur en MFA-grupp inte i kraft direkt vid den första efterföljande inloggningen. Sophos kräver ytterligare en inloggning med MFA; först vid senare inloggningar behövs inte längre OTP-koden. Kontrollera därför en gruppändring med en ny session och minst två kontrollerade inloggningar.

När Generate OTP token with next sign-in är aktiverat registrerar användarna en programvaruapp vid nästa inloggning. User Portal väljs då automatiskt som MFA-tjänst. När alternativet är inaktiverat tilldelas hårdvarutoken eller manuellt hanterade token under Issued tokens.

Välj tjänster medvetet

I SFOS 22 finns följande tjänster under Require MFA for:

  • User portal
  • Web admin console
  • VPN portal
  • SSL VPN remote access
  • IPsec remote access
  • Web application firewall

MFA för User Portal gäller även för Captive Portal och Client Authentication Agents. Fjärråtkomstanvändare måste först registrera sin token via VPN Portal eller User Portal.

För WAF räcker det inte att bara välja tjänsten. Från SFOS 22 krävs Webserver Protection, en formulärbaserad Authentication Policy och att denna tilldelas WAF-regeln. Hela proceduren beskrivs i Skydda Sophos Firewall WAF med MFA.

Välj en lämplig MFA-modell

Lokal Sophos OTP

Sophos OTP hanterar token direkt på brandväggen och kräver ingen ytterligare RADIUS- eller identitetsleverantörsinfrastruktur. Det lämpar sig särskilt för normala lokala användare, små miljöer och snabb härdning av WebAdmin eller fjärråtkomst.

Nackdelen med den enkla implementeringen är en separat token utanför befintliga Microsoft 365-processer. Användare och helpdesk måste känna till appregistrering, inmatning av lösenord plus OTP och hantering av enhetsbyten.

RADIUS eller Entra ID SSO

En befintlig MFA-plattform kan via RADIUS eller SSO passa bättre in i central identitetshantering. Den kräver dock tjänstespecifika tester:

  • VPN Portal stöder inte RADIUS med challenge-baserad MFA.
  • Sophos Connect stöder inte en OTP-challenge. Klienten skickar lösenord och OTP tillsammans i formatet passwordotp, men stöder MFA via telefonsamtal och push.
  • User Portal och WebAdmin stöder dessutom challenge-baserad MFA.
  • Med Entra ID SSO sker MFA hos identitetsleverantören; lokal Sophos OTP-MFA kan inte läggas ovanpå samma SSO-inloggning.
  • Entra SSO med Sophos Connect kräver minst klientversion 2.4 i Windows. WebAdmin SSO är inte tillgängligt på HA-hjälpenheten.

För Remote Access finns den separata guiden Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal. Om Entra i stället ska styra WebAdmin-inloggningen och administratörsrollerna går Entra ID SSO för Sophos Firewall WebAdmin igenom Role mapping, Least Privilege, pilotinloggning och lokal nödåtkomst.

Sophos Connect eller SSL VPN: vilken lösning passar? hjälper till att välja fjärråtkomstmodell; före utrullningen bör man även kontrollera Sophos Connect-klientversionen.

Oavsett modell börjar man med en pilotgrupp. Fler användare läggs till först när WebAdmin, portaler, verkliga VPN-klienter, grupper, tidsgränser, loggning och reservåtkomst har verifierats.

Konfigurera token och autentiseringsapp

Registrera och hantera token

När Generate OTP token with next sign-in är aktiverat loggar användaren in på VPN Portal eller User Portal och registrerar QR-koden i en kompatibel app. I SFOS 22 visas QR-koden; administratörer kan även registrera token i WebAdmin om MFA tillämpas där. I SFOS 23 följer leveransen Share QR code: med Email använder man QR-koden från e-postmeddelandet och med Portals den som visas i portalerna. En WebAdmin-inloggning kan med Portals utlösa visningen i portalerna, men inte e-postleverans. Registreringen gäller bara användare och grupper som MFA har konfigurerats för.

Vid den första registreringen i SFOS 23 med Generate OTP token with next sign-in på ON gäller följande för de valda MFA-användarna: en genererad QR-kod upphör att gälla om den inte används för inloggning inom 24 timmar efter genereringen. För att generera en ny loggar användaren in på VPN Portal eller User Portal med enbart lösenordet; den nya QR-koden levereras enligt Email eller Portals. Registrera den sedan i appen och kontrollera en ny inloggning med <password><passcode>. Denna giltighetstid för QR-koden är skild från fönstret på 300 sekunder för den första engångskoden. Flödet gäller inte en utfärdad token med status OFF eller manuell nyutfärdning av ett seed-värde; förutsätt det inte för SFOS 22 eller för varje flöde i standardadministratörens guide.

Under Authentication > Multi-factor authentication > Issued tokens kan utfärdade token kontrolleras, tillfälligt inaktiveras, tas bort eller läggas till manuellt. Där kan man också skapa extra engångskoder och kontrollera eller synkronisera tidsförskjutningen för en token.

Om tokenstatus sätts till OFF hindras användaren från att logga in; det ger inte åtkomst med enbart lösenordet. Detta är varken borttagning följd av ny registrering eller att hoppa över MFA för en enda inloggning via Device Console.

Om en smarttelefon försvinner eller appen byts verifierar man först användarens identitet. Precis före borttagningen kontrollerar man under Authentication > Multi-factor authentication att Generate OTP token with next sign-in är ON; i SFOS 23 väljer man också Email eller Portals under Share QR code. Om det manuella läget OFF är avsiktligt förbereder man i stället manuell nyutfärdning med ett nytt seed-värde; det automatiska QR-flödet nedan gäller då inte. Först därefter tar man bort den gamla token under Issued tokens. Användaren loggar in en gång på VPN Portal eller User Portal med enbart lösenordet och registrerar den nya QR-koden: SFOS 22 visar den, medan SFOS 23 skickar den via e-post eller visar den i portalen enligt valet. Kontrollera sedan en ny inloggning med <password><passcode>. En gammal token bör inte finnas kvar parallellt utan kontroll.

För detta appbytes- eller ersättningsflöde i SFOS 23 upphör en genererad QR-kod att gälla om den inte används för inloggning inom 24 timmar efter genereringen. En ny inloggning med enbart lösenordet genererar en ny QR-kod, som åter levereras via Email eller Portals. De 24 timmarna gäller QR-koden, inte det nedan beskrivna fönstret på 300 sekunder för den första engångskoden. Denna giltighetstid för QR-koden förutsätts varken för SFOS 22 eller för varje flöde i standardadministratörens guide.

Tilldela en maskinvaru- eller programvarutoken manuellt

Om brandväggen inte ska generera någon QR-kod förblir Generate OTP token with next sign-in inaktiverat. Redan registrerade token fortsätter att fungera. För nya användare sparas seed-värdet manuellt under Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). Knappens namn är snävare än dess funktion, eftersom samma dialogruta även kan användas för en manuellt tilldelad programvarutoken.

Välj först OTP hash algorithm och det tidsintervall som den aktuella token eller autentiseringsappen kräver. För Secret gäller sedan följande:

  • För en maskinvarutoken anges den individuella nyckeln från tillverkaren.
  • För en programvarutoken används ett unikt och tillräckligt slumpmässigt hexadecimalt seed-värde. Om appen kräver Base32 konverteras seed-värdet lokalt med ett kontrollerat offlineverktyg.
  • Ett seed-värde i produktion ska varken anges på en offentlig konverteringswebbplats eller läggas i ett supportärende, ett okrypterat e-postmeddelande eller ett skalkommando som sparas i historiken. Den som känner till seed-värdet kan skapa giltiga OTP-koder.

Om den enskilda token skiljer sig från den globala inställningen Default token timestep aktiveras Use custom timestep endast för denna token och det intervall som faktiskt stöds anges. Utan alternativet gäller det globala standardvärdet; appens och maskinvarans kompatibilitet kontrolleras innan konfigurationen sparas.

Välj sedan exakt den avsedda användaren och spara med Save. Maskinvarutoken eller Base32-seed-värdet överlämnas en gång via en skyddad kanal. Testa därefter en korrekt och en avsiktligt felaktig kod och synkronisera vid behov tidsförskjutningen under Issued tokens. Om seed-värdet kan ha röjts ska token inte användas vidare. Ta bort den och utfärda en ny token med ett nytt seed-värde.

Utfärda extra engångskoder under kontroll

Om appen eller maskinvarutoken endast är tillfälligt otillgänglig redigeras den berörda användaren under Authentication > Multi-factor authentication > Issued tokens. Under Additional codes genererar plusknappen extra koder och Save kopplar dem till token. Brandväggen tar automatiskt bort varje kod från listan när den har använts.

Användarens identitet verifieras innan koderna utfärdas. Koderna överlämnas en gång via en skyddad kanal endast till den användaren och placeras inte tillsammans i ett oskyddat supportärende eller e-postmeddelande. Extra koder ersätter inte en ny token när den gamla har förlorats permanent eller kan ha kopierats: ta bort den gamla token och registrera en ny med ett nytt seed-värde.

App och hashalgoritm måste vara kompatibla

SFOS 22 stöder SHA1, SHA256 och SHA512. Sophos rekommenderar SHA256 eller SHA512, men den valda algoritmen måste stödjas av appen:

  • Sophos Intercept X for Mobile och Google Authenticator stöder SHA256 och SHA512.
  • Microsoft Authenticator stöder inte dessa två algoritmer i detta Sophos-arbetsflöde. QR-koden kan ändå skannas, men den efterföljande inloggningen misslyckas.
  • Duo Mobile och Okta Verify hör till apparna som Sophos listar; deras kompatibilitet med QR-kod och algoritm måste passa det operativsystem och den konfiguration som används.
  • Andra TOTP-appar godkänns först efter ett verkligt pilottest.

Sophos Intercept X for Mobile stöder ett anpassat tidssteg för token. De flesta andra autentiseringsappar stöder endast standardvärdet på 30 sekunder, så det globala värdet ändras inte enbart för en enda app.

I iOS fungerar det inte att skanna Sophos QR-kod med Google Authenticator, Duo Mobile eller Microsoft Authenticator. Skapa kontot manuellt med den Base32-nyckel som visas. Okta Verify kräver manuell Base32-registrering i både iOS och Android. Detta löser dock inte Microsoft Authenticators brist på stöd för SHA256/SHA512.

Den tidigare appen Sophos Authenticator nådde End of Life den 31 juli 2022 och bör inte längre planeras för nya utrullningar.

Befintliga SHA1-token kan finnas kvar efter en uppgradering från en version före SFOS 22, eftersom tidigare SFOS-versioner genererade MFA-token med SHA1. Valet av en starkare global algoritm konverterar inte dessa befintliga token.

För att migrera från SHA1 till en starkare algoritm:

  1. Testa pilotappen med SHA256 eller SHA512.
  2. Aktivera Generate OTP token with next sign-in. I SFOS 23 väljer man även Email eller Portals under Share QR code före Apply.
  3. Välj den nya algoritmen under Authentication > Multi-factor authentication.
  4. Spara med Apply.
  5. Ta bort gamla SHA1-token under Issued tokens. För att ta bort token för standardkontot admin måste man vara inloggad som den användaren; en annan administratör kan inte ta bort den. Ha den testade reservåtkomsten och konsolåtkomsten redo i förväg.
  6. Låt vanliga användare logga in på VPN Portal eller User Portal med enbart lösenordet och registrera QR-koden eller Base32-nyckeln på nytt i en app som stöder SHA256/SHA512. I SFOS 23 följer QR-leveransen Email eller Portals. För standardkontot admin börjar omregistreringen efter borttagning i stället med en WebAdmin-inloggning med enbart lösenordet, inte via User Portal eller VPN Portal; följ registreringsflödet som visas där. Detta är SHA-migrering, inte Use an existing token i guiden för återaktivering. Förutsätt inte ett extra Share QR code-val i guiden för detta undantag.
  7. Genomför kontrollerade inloggningstester med en korrekt och en felaktig kod.

Token med olika algoritmer kan finnas parallellt under migreringen. Token som inte tas bort fortsätter dock att använda sin gamla algoritm.

Begränsa tidsintervallet och toleransfönstren

Under OTP timestep settings konfigureras inte bara intervallet för nya koder, utan även två verifieringsfönster. De tre värdena har olika effekter:

  • Default token timestep anger intervallet då appen eller maskinvarutoken genererar en ny kod. Standardvärdet är 30 sekunder. En ändring gäller endast nygenererade token och ändrar inte befintliga token.
  • Maximum verification code offset anger hur många tidssteg en ännu oanvänd kod förblir giltig. Med standardvärdet 2 och ett tidssteg på 30 sekunder accepteras även oanvända koder från de föregående 60 sekunderna.
  • Maximum initial verification code offset gäller den första koden efter att QR-koden har skannats. Med standardvärdet 10 och ett tidssteg på 30 sekunder är fönstret 300 sekunder om koden inte redan har använts.

Dessa fönster ersätter inte korrekt tidssynkronisering. Kontrollera först NTP på brandväggen och tiden på slutenheten och håll sedan varje offset så liten som är praktiskt möjligt för de appar och maskinvarutoken som används. Ett större fönster accepterar en avlyssnad, ännu oanvänd kod under motsvarande längre tid. Testa en nyutfärdad pilottoken efter en ändring; utgå inte från att en befintlig token använder det ändrade tidssteget.

Ange lösenord och OTP korrekt

För inbyggd Sophos OTP-inloggning är det officiella formatet <password><passcode>, utan blanksteg eller avgränsare.

Exempel:

Lösenord: MittSakraLosenord
OTP-kod:  123456
Inmatning: MittSakraLosenord123456

Sophos Connect kan visa ett separat tredje inmatningsfält med otp: true. Klienten lägger internt till koden efter lösenordet. Den här visningen ändrar inte formatet som skickas till autentiseringsservern.

Skydda och återställ standardadministratören

Aktivera MFA för standard admin

Den lokala standardanvändaren admin aktiveras inte via den vanliga användarlistan. Kontots egen guide finns under Administration > Device access, inte under Issued tokens > Add token (for hardware tokens) för vanliga användare.

Innan dess måste en andra administratör, hanteringsåtkomst och konsolåtkomst fungera. Extra engångskoder ska lagras säkert, exempelvis i en lösenordshanterare. Standardkontot admin förblir ett nödkonto och används inte för daglig administration.

Andra administratörer kan inte aktivera, inaktivera, redigera eller ta bort token för standardkontot admin. Den valda globala inställningen OTP hash algorithm gäller även för denna token.

Kontrollera före start även tiden, appens eller hårdvarans kompatibilitet och Block login, enligt beskrivningen ovan. Nya hårdvaru- och programvarutoken använder algoritmen från Authentication > Multi-factor authentication > OTP hash algorithm; den väljs inte separat i standardadministratörens guide. En lyckad QR-skanning bevisar inte att algoritmen stöds. De tidigare beskrivna begränsningarna för appar och Base32 gäller fortfarande.

  1. Logga in på WebAdmin som standardkontot admin och öppna Administration > Device access.
  2. Aktivera MFA for default admin och klicka på Apply.
  3. Välj lämplig tokenmetod i guiden och klicka på Next. Slutför sedan rätt alternativ:
  • Configure a hardware token: Ange den individuella nyckeln från enhetens tillverkare och det tidssteg som stämmer med hårdvarutoken. Klicka på Next och ange sedan standardadministratörens lösenord direkt följt av den aktuella hårdvarukoden som <password><passcode>, utan blanksteg eller avgränsare. Klicka på Validate och avsluta med Apply efter lyckad validering.
  • Generate a software token: Installera en kompatibel autentiseringsapp på den mobila enheten och skanna den visade QR-koden. Ange standardadministratörens lösenord direkt följt av appens aktuella kod som <password><passcode>. Klicka på Validate och avsluta med Apply efter lyckad validering.
  • Use an existing token: Om det redan finns en hårdvaru- eller programvarutoken för standardkontot admin och MFA bara återaktiveras väljer man detta alternativ och anger lösenordet direkt följt av den aktuella koden. För att i stället konfigurera en ny programvarutoken väljer man Generate a software token och registrerar QR-koden i appen. Detta val är inte en migrering av befintliga SHA1-användartoken.

Det första Apply startar konfigurationen; nya hårdvaru- och programvarutoken kräver fortfarande Validate och avslutande Apply. Om valideringen misslyckas kontrollerar man först lösenord plus kod, tid, tidssteg och algoritm i stället för att gissa upprepade gånger. Behåll den befintliga sessionen öppen under kontrollen och testa efter slutförd konfiguration en separat ny WebAdmin-session som standardkontot admin med lösenordet plus en ny kod. Betrakta konfigurationen som klar först efter lyckad inloggning och säker lagring av engångskoderna; den andra administratören ersätter inte standardadministratörens tokenhantering eller den konsolbaserade återställningsproceduren nedan.

Återställning via Device Console

Menyalternativen 6 och 7 visas endast om MFA for default admin redan har konfigurerats under Administration > Device access. Om de saknas ska man inte automatiskt anta ett konsolfel; kontrollera först denna inställning och att kontot verkligen är standardanvändaren admin. Alternativen gäller inte andra administratörskonton.

Om token bara är tillfälligt otillgänglig kan man via Device Console tillåta en enda inloggning utan MFA:

  1. Ange 2 för System Configuration.
  2. Ange 6 för Skip multi-factor authentication for next Admin user login.
  3. Logga in på WebAdmin och kontrollera token.

Vid förlorad enhet eller permanent obrukbar token återställs MFA:

  1. Ange 2 för System Configuration.
  2. Ange 7 för Reset multi-factor authentication for Admin user.
  3. Bekräfta med y.
  4. Logga in en gång på WebAdmin med enbart administratörslösenordet.
  5. Följ anvisningarna för att registrera MFA på nytt och testa därefter en ny inloggning med MFA.

Dessa två alternativ ändrar endast MFA-statusen. Om standardadministratörens lösenord också är okänt förklarar den separata artikeln om lösenordsåterställning den dokumenterade seriella metoden för fysiska appliances och begränsningarna vid kombinerad förlust av lösenord och MFA.

Testa, kontrollera loggar och rulla ut

Testa varje tjänst separat

En lyckad WebAdmin-inloggning visar inte att portaler och VPN-klienter fungerar på samma sätt. Före en bred utrullning testar man:

  • WebAdmin: Logga in som pilotadministratör med en korrekt och en avsiktligt felaktig OTP.
  • Default admin: Kontrollera den separata Device Access-vägen och den dokumenterade återställningsproceduren.
  • User Portal och VPN Portal: Testa registrering med QR eller Base32 samt inloggning med <password><passcode>.
  • SSL VPN och IPsec Remote Access: Testa verkliga klienter och exakt den användargrupp som används i produktion.
  • Sophos Connect: Testa vid behov det tredje OTP-fältet, aktuella klientprofiler och beteendet för telefonsamtal/push.
  • RADIUS eller Entra SSO: Kontrollera tidsgränser, IdP-loggar och det challenge-beteende som faktiskt stöds.
  • Device Access: Testa åtkomst från ett tillåtet och ett otillåtet källnät.

Utför bara ett kontrollerat antal misslyckade försök efter att Block login har kontrollerats. Det förväntade resultatet är inte bara en lyckad inloggning: en felaktig kod måste avvisas, försöket loggas och tjänsten vara nåbar enbart från avsedda nätverk.

Tolka autentiseringsloggar korrekt

I Log viewer kontrollerar man lyckade och misslyckade inloggningar tillsammans med tjänst, användare, källa, tid och dokumenterad orsak. Beroende på händelsen kan SFOS endast ge ett allmänt meddelande, till exempel felaktiga inloggningsuppgifter. Utan ytterligare belägg ska man inte dra slutsatsen att enbart lösenordet, OTP eller en utgången kod orsakade felet.

Vid extern MFA ingår RADIUS-, NPS- eller IdP-loggar i samma kontroll. Felsökning av Sophos Firewall: tjänster och loggar hjälper med lokala loggfiler och tjänstemappning. För längre lagring och korrelation används Skicka Sophos Firewall Syslog till ett SIEM.

Före den breda utrullningen

  • Pilotgruppen har testats framgångsrikt med alla nödvändiga tjänster.
  • Andra administratören, engångskoder och återställning via Device Console är dokumenterade.
  • Användarna är informerade om appregistrering och lösenord plus OTP.
  • Tokenåterställning för förlorade eller nya smarttelefoner är definierad.
  • Device Access, inloggningsblockeringar och central logglagring är kontrollerade.
  • Ansvar, tidsgränser och reservlösning är fastställda för extern MFA.

Felsökning

Token, QR-kod och inmatning

OTP-koden accepteras inte

Jämför först tiden på brandväggen och smarttelefonen, appen som används, hashalgoritmen och tidssteget. Under Issued tokens kan man kontrollera och synkronisera tidsförskjutningen. Efter en algoritmmigrering måste den gamla tokenen ha tagits bort och registrerats på nytt.

För att synkronisera öppnar man Authentication > Multi-factor authentication > Issued tokens, väljer Synchronize token time offset för berörd token, anger den aktuella kod som appen eller hårdvarutoken genererar och klickar på Check. Tidsförskjutningen synkroniseras med brandväggen, vilket korrigerar klockdriften. Testa sedan kontrollerat en ny inloggning; behåll reservåtkomsten och kontrollera Block login före fler misslyckade försök.

Planera ett byte av NTP-server separat eftersom brandväggen då återansluter befintliga IPsec-tunnlar.

QR-koden visas inte eller kan inte skannas

Användaren måste tillhöra den valda MFA-gruppen och logga in på VPN Portal eller User Portal. I SFOS 22 kan administratörer även registrera sig i WebAdmin när MFA är aktiverat där. I SFOS 23 kontrollerar man först Share QR code: med Email kontrollerar man inkorgen efter portalinloggningen i stället för att förvänta sig en QR-kod i portalen; med Portals visas QR-koden i portalerna, även efter en WebAdmin-inloggning som utlöser visningen. Portalen och källan måste dessutom vara tillåtna under Administration > Device access. Vid den första registreringen eller appersättning i SFOS 23 med tokengenerering aktiverad kontrollerar man även giltighetstiden på 24 timmar enligt beskrivningen ovan: om QR-koden inte har använts för inloggning under den tiden loggar man in på VPN Portal eller User Portal med enbart lösenordet och registrerar den nya QR-koden som levereras enligt Email eller Portals.

I iOS eller med Okta Verify använder man Base32-nyckeln i stället för att skanna QR-koden när de angivna begränsningarna gäller.

Inloggningen rapporterar fel lösenord

Vid inbyggd Sophos OTP-inloggning måste koden anges direkt efter lösenordet. Utan ett separat OTP-fält är enbart lösenordet ofullständigt.

Åtkomst, grupper och Remote Access

Portalen kan inte nås

Kontrollera först zon, källa och den nödvändiga tjänsten under Administration > Device access. En restriktiv Local Service ACL Exception Rule är säkrare än en generell WAN-tillåtelse.

MFA gäller inte för Remote Access

MFA- och Remote Access-konfigurationerna måste använda samma faktiskt importerade användargrupp. Importera eller distribuera därefter klientprofilen på nytt och testa anslutningen med den verkliga klienten. Före den första VPN-anslutningen måste token registreras via VPN Portal eller User Portal.

MFA gäller bara för vissa användare

Jämför inte bara synliga gruppnamn, utan kontrollera de grupper som faktiskt matchas via AD, LDAP, RADIUS eller Entra ID. När en AD-användare har tagits bort från en MFA-grupp kan en sista inloggning med MFA fortfarande krävas; först efterföljande inloggningar kräver inte längre OTP.

Utlåsning och extern MFA

Administratören är utlåst

För standardkontot admin använder man Device Console-alternativ 6 eller 7 enligt beskrivningen ovan. För en annan administratör använder man den förberedda andra administratören från en tillåten källa och kontrollerar därefter grupper, token och status för inloggningsblockeringen.

RADIUS eller Entra MFA fungerar inte tillförlitligt

Kontrollera RADIUS-tidsgränser, IdP-loggar, grupper och den specifika tjänstens challenge-beteende. Ett lyckat test av autentiseringsservern bevisar inte att en produktionsinloggning via VPN Portal, Sophos Connect eller WebAdmin fungerar. Testa var och en av dessa vägar separat.