FortiGate VPN MFA: lokal token, RADIUS eller SAML?

Kvart FortiGate VPN MFA-design svarar først på eitt spørsmål: kven verifiserer den andre faktoren? Gatewayen sjølv kan gjere det med eit lokalt token eller ein kode som vert send på e-post, ein RADIUS-backend kan handheve det og sende ein utfordring tilbake, eller ein SAML-identitetsleverandør kan ta over heile seremonien i ein nettlesar. Kvar av dei gjev ein annan innloggingssekvens, ein annan feilsignatur og ein annan gjenopprettingsprosedyre, og å kopiere ein kommandoblokk mellom dei gjev ein konfigurasjon som ser truverdig ut og ikkje autentiserer nokon. Dette er ein artikkel om mekanismen: kva kvart design faktisk gjer under ei innlogging, og kvar det bryt saman.

Innloggingsseremonien avgjer kven som eig faktoren

I dei to første designa er FortiGate parten som stolar på. Det samlar inn legitimasjonen, avgjer om ein andre faktor trengst, og verifiserer han lokalt eller ved å be om ei utfordring. I det tredje designet sluttar gatewayen å vere verifiserar og vert ein videresendar: han omdirigerer klienten til identitetsleverandøren, tek imot ein assertion og mappar den stadfesta identiteten til ein brukar og ei gruppe. I RADIUS-designet ligg han imellom og driv ein førespurnad-svar-utveksling med ein backend som har policyen.

Skilnaden avgjer kva bevis du kan samle inn. Når gatewayen verifiserer, fortel hans eigen feilsøkingsutskrift deg kva som hende. Når ein identitetsleverandør verifiserer, veit gatewayen berre at ein assertion kom, og svaret på «var MFA faktisk påkravd» ligg i loggane til leverandøren, ikkje i loggane til brannmuren. Å lese feil logg er den vanlegaste måten å feildiagnostisere ei utrulling som oppfører seg nøyaktig som designa. Tenesta sjølv avgrensar òg seremonien: FortiOS 7.6.3 fjernar SSL VPN-tunnelmodus til fordel for IPsec, medan nettmode held fram som Agentless VPN på støtta modellar, så ein seremoni som er prova på éi teneste er ikkje automatisk tilgjengeleg på ei anna.

Lokal verifisering: token og e-postkode

Faktorar som FortiGate styrer, er knytte til brukarobjektet. Eit FortiToken eller ein dokumentert tokenintegrasjon krev registrering, den støtta verifiseringsseremonien, lisensiering der det gjeld, og ein erstatningsprosedyre. Ein e-postkode krev ein fungerande SMTP-veg og ein postkasse som brukaren kan nå før tunnelen finst, ei avhengnad som ikkje har noko med kryptografi å gjere og alt med kvarvidt nokon kan logge inn.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

E-postlevering er ein del av tilgjengeet til autentiseringa. Ein postkasse som berre er tilgjengeleg via VPN, skaper ei løkke som ikkje løyser seg sjølv for nokon, og leveringsforsinking, kodegyldigheit og tidsavbrotet for ekstern autentisering er tre separate avgrensingar. Å heve éi reparerer ikkje ein utilgjengeleg postkasse, og eit design som aldri har testa løkka, vil oppdage ho ved første passordtilbakestilling etter ein ferie.

Også tryggingskrav høyrer heime her, før produktvalet. NIST SP 800-63B reknar e-post som uakseptabelt for autentisering utanfor banda, så ei utrulling som hevdar samsvar, kan ikkje bruke ein e-postkode som sin andre faktor, same kor praktisk det er. At ein funksjon finst på eininga, er ikkje ei fråsegn om at funksjonen oppfyller ein gjeven standard.

RADIUS: gatewayen spør, backend-en avgjer

Med RADIUS sender FortiGate legitimasjonen til ein backend som eig faktorpolitikken. Utvekslinga kan vere ei enkel godtaking eller avvising, eller ho kan innehalde ei utfordring som klienten må svare på, noko som tyder på at både VPN-tenesta og klienten må støtte den utfordringsforma. Ein backend som handhevar ei push-godkjenning, og ein klient som berre kan leggje til ein sekssifra kode på eit passord, møtest ikkje på midten.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Test backend-en uavhengig før du klandrar tunnelen. Viss authserver-testen lukkast og ei VPN-innlogging ikkje gjer det, ligg skilnaden i handteringa av utfordringa og ikkje i legitimasjonen, og feilsøkinga av autentiseringsdaemonen til gatewayen er der det syner seg:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: nettlesaren forlét gatewayen

I eit SAML-design vert klienten omdirigert til identitetsleverandøren, autentiserer seg der og kjem tilbake med ein assertion som gatewayen validerer mot eit tillitsforhold og ei gruppemapping. Gatewayen ser aldri passordet eller den andre faktoren, noko som samstundes er ei tryggingsbetring og ein driftsmessig komplikasjon: feilen skjer no i ein nettlesarøkt som brannmuren ikkje kan inspisere.

Å godta ein assertion beviser ikkje at leverandøren kravde MFA for den innlogginga. Ein leverandørpolicy som brukar MFA på nokre applikasjonar og ikkje på andre, vil gje nøyaktig den innlogginga du bad om og ingenting av den tryggleiken du antok. Sjekk policyen til leverandøren for nettopp denne applikasjonen, og sjekk at mappinga av gruppepåstandar til FortiGate-grupper framleis stemmer etter ei eventuell ny namngjeving på kvar side.

Klientstøtte tyder meir her enn nokon annan stad. Nokre VPN-klientar handterer overleveringa til nettlesaren innebygd, andre opnar systemnettlesaren, og headless- eller kommandolinjeklientar fullfører kanskje ikkje flyten i det heile. Test med klienten brukarane faktisk køyrer, på plattformane dei faktisk brukar, før du publiserer profilen.

Gjenoppretting er ein del av mekanismen

Kvart av designa ovanfor har ei avhengnad som kan svikte for éin brukar om gongen: ein utilgjengeleg postkasse, eit tapt token, ein backend som avviser ei utfordring, ein låst konto hos identitetsleverandøren. Avgjer no kven som kan gjenopprette tilgang, gjennom kva støtta prosedyre og med kva verifisering av personen som ber om det. Ein lokal naudadministratorkonto som vert halden åtskild frå VPN-vegen, er ein kontroll; og ei uforklarleg omgåing med berre passord er ei hending som ventar på å verte oppdaga.

Test deretter tre innloggingar før utrulling: den normale, ein avvist eller utgått faktor og den godkjende gjenopprettinga av ein tapt autentiserar. Noter kva logg kvar av dei viser seg i. Den registreringa er det som gjer «MFA er aktivert» til eit design som nokon andre kan drifte.