FortiGate VPN MFA: plaaslike token, RADIUS of SAML?

Elke FortiGate VPN MFA-ontwerp beantwoord eers een vraag: wie verifieer die tweede faktor? Die gateway self kan dit doen met 'n plaaslike token of 'n e-poskode, 'n RADIUS-agterkant kan dit afdwing en 'n uitdaging terugstuur, of 'n SAML-identiteitsverskaffer kan die hele seremonie in 'n blaaier besit. Elkeen van dié lewer 'n ander aanmeldingsvolgorde, 'n ander foutpatroon en 'n ander herstelprosedure, en om 'n opdragblok tussen hulle te kopieer lewer 'n konfigurasie wat geloofwaardig lyk en niemand verifieer nie. Dit is 'n meganisme-artikel: wat elke ontwerp werklik tydens 'n aanmelding doen, en waar dit breek.

Die aanmeldingseremonie bepaal wie die faktor besit

In die eerste twee ontwerpe is die FortiGate die party wat vertrou. Dit versamel die geloofsbrief, besluit of 'n tweede faktor nodig is, en verifieer dit plaaslik of deur 'n uitdaging te vra. In die derde ontwerp hou die gateway op om die verifieerder te wees en word 'n deurgang: dit stuur die kliënt na die identiteitsverskaffer, ontvang 'n bevestiging en karteer die bevestigde identiteit na 'n gebruiker en groep. In die RADIUS-ontwerp lê dit tussenin en dryf 'n versoek-antwoord-uitruiling met 'n agterkant wat die beleid hou.

Daardie verskil bepaal watter bewyse jy kan insamel. Wanneer die gateway verifieer, vertel sy eie ontfoutingsuitset jou wat gebeur het. Wanneer 'n identiteitsverskaffer verifieer, weet die gateway net dat 'n bevestiging aangekom het, en die antwoord op “was MFA werklik nodig” lê in die verskaffer se logs, nie in die firewall s'n nie. Om die verkeerde log te lees is die algemeenste manier om 'n ontplooiing verkeerd te diagnoseer wat presies werk soos ontwerp. Die diens self begrens ook die seremonie: FortiOS 7.6.3 verwyder SSL VPN-tonnelmodus ten gunste van IPsec, terwyl webmodus voortduur as Agentless VPN op ondersteunde modelle, so 'n seremonie wat op een diens bewys is, is nie outomaties op 'n ander beskikbaar nie.

Plaaslike verifikasie: tokens en e-poskodes

FortiGate-bestuurde faktore hang aan die gebruikerobjek. 'n FortiToken of 'n gedokumenteerde token-integrasie benodig registrasie, die ondersteunde verifikasieseremonie, lisensiëring waar dit geld, en 'n vervangingsprosedure. 'n E-poskode benodig 'n werkende SMTP-pad en 'n posbus wat die gebruiker kan bereik voordat die tonnel bestaan, wat 'n afhanklikheid is wat niks met kriptografie te doen het nie en alles met of iemand kan aanmeld.

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

E-posaflewering is deel van verifikasiereg. 'n Posbus wat net deur die VPN bereikbaar is, skep 'n lus wat homself vir niemand oplos nie, en afleweringsvertraging, kodegeldigheid en die remote-verifikasie-tydlimiet is drie aparte beperkings. Om een te verhoog herstel nie 'n onbereikbare posbus nie, en 'n ontwerp wat die lus nooit getoets het nie, sal dit ontdek tydens die eerste wagwoordherstel ná 'n vakansie.

Versekeringsvereistes hoort ook hier, voor die produkkeuse. NIST SP 800-63B beskou e-pos as onaanvaarbaar vir buitebandse verifikasie, so 'n ontplooiing wat nakoming beweer, kan nie 'n e-poskode as sy tweede faktor gebruik nie, maak nie saak hoe gerieflik dit is nie. Dat 'n funksie op die toestel bestaan, is nie 'n verklaring dat die funksie aan 'n gegewe standaard voldoen nie.

RADIUS: die gateway vra, die agterkant besluit

Met RADIUS stuur die FortiGate die geloofsbrief na 'n agterkant wat die faktorbeleid besit. Die uitruiling kan 'n gewone aanvaarding of verwerping wees, of dit kan 'n uitdaging behels wat die kliënt moet antwoord, wat beteken die VPN-diens en die kliënt moet albei daardie uitdagingsvorm ondersteun. 'n Agterkant wat 'n push-goedkeuring afdwing en 'n kliënt wat net weet hoe om 'n ses-syfer-kode by 'n wagwoord te voeg, sal mekaar nie in die middel ontmoet nie.

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>

Toets die agterkant onafhanklik voordat jy die tonnel blameer. As die authserver-toets slaag en 'n VPN-aanmelding nie, is die verskil in die hantering van die uitdaging eerder as in die geloofsbrief, en die gateway se verifikasie-daemon-ontfouting is waar dit wys:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: die blaaier verlaat die gateway

In 'n SAML-ontwerp word die kliënt na die identiteitsverskaffer herlei, verifieer daar, en keer terug met 'n bevestiging wat die gateway teen 'n vertrouensverhouding en 'n groepkartering valideer. Die gateway sien nooit die wagwoord of die tweede faktor nie, wat terselfdertyd 'n sekuriteitsverbetering en 'n operasionele komplikasie is: die fout gebeur nou in 'n blaaiersessie wat die firewall nie kan inspekteer nie.

Om 'n bevestiging te aanvaar bewys nie dat die verskaffer MFA vir daardie aanmelding vereis het nie. 'n Verskafferbeleid wat MFA op sommige toepassings toepas en nie op ander nie, lewer presies die aanmelding wat jy gevra het en niks van die versekering wat jy aanvaar het nie. Kontroleer die verskaffer se beleid vir hierdie spesifieke toepassing, en kontroleer dat die groepbewerings wat na FortiGate-groepe karteer, steeds ooreenstem ná enige hernoeming aan enige kant.

Kliëntondersteuning maak hier meer saak as enige plek anders. Sommige VPN-kliënte hanteer die blaaier-oorgang inheems, sommige maak die stelselblaaier oop, en kop-lose of opdragreël-kliënte voltooi die vloei dalk glad nie. Toets met die kliënt wat gebruikers werklik gebruik, op die platforms wat hulle werklik gebruik, voordat jy die profiel publiseer.

Herstel is deel van die meganisme

Elke ontwerp hierbo het 'n afhanklikheid wat vir een gebruiker op 'n slag kan faal: 'n onbereikbare posbus, 'n verlore token, 'n agterkant wat 'n uitdaging verwerp, 'n identiteitsverskaffer-rekening wat gesluit is. Besluit nou wie toegang kan herstel, deur watter ondersteunde prosedure, en met watter verifikasie van die persoon wat vra. 'n Nood-plaaslike administrateur-rekening wat apart van die VPN-pad gehou word, is 'n beheer; 'n onverklaarde slegs-wagwoord-omseil is 'n voorval wat wag om ontdek te word.

Toets dan drie aanmeldings voor ontplooiing: die normale een, 'n verwerpte of vervalle faktor, en die goedgekeurde herstel van 'n verlore verifieerder. Teken aan in watter log elkeen verskyn. Daardie rekord is wat “MFA is geaktiveer” verander in 'n ontwerp wat iemand anders kan bedryf.