FortiGate VPN MFA: lokaal token, RADIUS of SAML?

Elk FortiGate VPN MFA-ontwerp beantwoordt eerst één vraag: wie verifieert de tweede factor? De gateway zelf kan dat doen met een lokaal token of een per e-mail verzonden code, een RADIUS-backend kan het afdwingen en een uitdaging terugsturen, of een SAML-identiteitsprovider kan de hele ceremonie in een browser overnemen. Elk daarvan levert een andere inlogreeks, een andere foutsignatuur en een andere herstelprocedure op, en een commandoblok ertussen kopiëren levert een configuratie op die plausibel lijkt en niemand authenticeert. Dit is een artikel over het mechanisme: wat elk ontwerp tijdens een login feitelijk doet, en waar het breekt.

De login-ceremonie bepaalt wie de factor bezit

In de eerste twee ontwerpen is de FortiGate de partij die vertrouwt. Hij verzamelt de referentie, beslist of een tweede factor nodig is, en verifieert die lokaal of via een uitdaging. In het derde ontwerp houdt de gateway op verifieerder te zijn en wordt een doorgeefluik: hij verwijst de client door naar de identiteitsprovider, ontvangt een assertie en koppelt de bevestigde identiteit aan een gebruiker en een groep. In het RADIUS-ontwerp staat hij ertussenin en drijft een vraag-en-antwoord-uitwisseling met een backend die het beleid heeft.

Dat verschil bepaalt welk bewijs je kunt verzamelen. Als de gateway verifieert, vertelt zijn eigen foutopsporingsuitvoer je wat er gebeurde. Als een identiteitsprovider verifieert, weet de gateway alleen dat er een assertie is aangekomen, en het antwoord op „was MFA echt vereist” staat in de logboeken van de provider, niet in die van de firewall. Het verkeerde logboek lezen is de meest voorkomende manier om een uitrol verkeerd te diagnosticeren die zich precies gedraagt zoals ontworpen. De dienst zelf begrenst de ceremonie ook: FortiOS 7.6.3 verwijdert de SSL VPN-tunnelmodus ten gunste van IPsec, terwijl de webmodus doorgaat als Agentless VPN op ondersteunde modellen, dus een ceremonie die op de ene dienst is bewezen, is niet automatisch op een andere beschikbaar.

Lokale verificatie: tokens en e-mailcodes

Door FortiGate beheerde factoren hangen aan het gebruikersobject. Een FortiToken of een gedocumenteerde tokenintegratie vereist inschrijving, de ondersteunde verificatieceremonie, licenties waar van toepassing, en een vervangingsprocedure. Een per e-mail verzonden code vereist een werkend SMTP-pad en een mailbox die de gebruiker kan bereiken voordat de tunnel bestaat, een afhankelijkheid die niets met cryptografie te maken heeft en alles met de vraag of iemand kan inloggen.

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

E-mailbezorging is deel van de beschikbaarheid van authenticatie. Een mailbox die alleen via de VPN bereikbaar is, maakt een lus die zich voor niemand vanzelf oplost, en bezorgvertraging, codegeldigheid en de time-out van externe authenticatie zijn drie afzonderlijke beperkingen. Eén ervan verhogen repareert geen onbereikbare mailbox, en een ontwerp dat de lus nooit heeft getest, ontdekt die bij de eerste wachtwoordreset na een vakantie.

Ook zekerheidseisen horen hier, vóór de productkeuze. NIST SP 800-63B beschouwt e-mail als onaanvaardbaar voor out-of-band-authenticatie, dus een implementatie die conformiteit claimt, kan geen e-mailcode als tweede factor gebruiken, hoe handig ook. Dat een functie op het apparaat bestaat, is geen verklaring dat de functie aan een bepaalde standaard voldoet.

RADIUS: de gateway vraagt, de backend beslist

Met RADIUS stuurt de FortiGate de referentie naar een backend die het factorbeleid bezit. De uitwisseling kan een simpele acceptatie of afwijzing zijn, of een uitdaging bevatten die de client moet beantwoorden, wat betekent dat zowel de VPN-dienst als de client die vorm van uitdaging moeten ondersteunen. Een backend die een push-goedkeuring afdwingt en een client die alleen een zescijferige code aan een wachtwoord kan toevoegen, komen elkaar niet halverwege tegen.

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 de backend onafhankelijk voordat je de tunnel de schuld geeft. Als de authserver-test slaagt en een VPN-login niet, zit het verschil in de afhandeling van de uitdaging en niet in de referentie, en de foutopsporing van de authenticatiedaemon van de gateway is waar dat zichtbaar wordt:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: de browser verlaat de gateway

In een SAML-ontwerp wordt de client naar de identiteitsprovider gestuurd, authenticeert daar, en komt terug met een assertie die de gateway valideert tegen een vertrouwensrelatie en een groeps mapping. De gateway ziet nooit het wachtwoord of de tweede factor, wat tegelijk een beveiligingsverbetering en een operationele complicatie is: de fout gebeurt nu in een browsersessie die de firewall niet kan inspecteren.

Een assertie accepteren bewijst niet dat de provider MFA voor die login vereiste. Een providerbeleid dat MFA op sommige applicaties toepast en op andere niet, levert precies de login die je vroeg en niets van de zekerheid die je aannam. Controleer het beleid van de provider voor deze specifieke applicatie, en controleer dat de mapping van groepsclaims naar FortiGate-groepen na elke hernoeming aan beide kanten nog steeds klopt.

Clientondersteuning is hier belangrijker dan waar dan ook. Sommige VPN-clients verwerken de overdracht naar de browser native, andere openen de systeembrowser, en headless of commandoregel-clients voltooien de stroom mogelijk helemaal niet. Test met de client die gebruikers echt draaien, op de platforms die ze echt gebruiken, voordat je het profiel publiceert.

Herstel is deel van het mechanisme

Elk ontwerp hierboven heeft een afhankelijkheid die voor één gebruiker tegelijk kan falen: een onbereikbare mailbox, een verloren token, een backend die een uitdaging weigert, een vergrendeld account bij de identiteitsprovider. Beslis nu wie toegang kan herstellen, via welke ondersteunde procedure en met welke verificatie van de persoon die erom vraagt. Een lokaal noodbeheerdersaccount dat los van het VPN-pad wordt gehouden, is een beheersmaatregel; en een onverklaarde omzeiling met alleen een wachtwoord is een incident dat wacht om ontdekt te worden.

Test daarna drie logins vóór de uitrol: de normale, een geweigerde of verlopen factor, en het goedgekeurde herstel van een verloren authenticator. Noteer in welk logboek elk verschijnt. Die registratie is wat „MFA is ingeschakeld” verandert in een ontwerp dat iemand anders kan beheren.