FortiGate VPN MFA: token local, RADIUS o SAML?

Cada disseny de FortiGate VPN MFA respon primer una pregunta: qui verifica el segon factor? La mateixa passarel·la pot fer-ho amb un token local o un codi enviat per correu, un backend RADIUS pot imposar-lo i tornar un repte, o un proveïdor d'identitat SAML pot assumir tota la cerimònia en un navegador. Cadascun produeix una seqüència d'inici de sessió diferent, una signatura de fallada diferent i un procediment de recuperació diferent, i copiar un bloc de comandes entre ells produeix una configuració que sembla plausible i no autentica ningú. Aquest és un article de mecanisme: què fa realment cada disseny durant un inici de sessió i on es trenca.

La cerimònia d'inici de sessió decideix qui posseeix el factor

En els dos primers dissenys, el FortiGate és la part que confia. Recull la credencial, decideix si cal un segon factor i el verifica localment o mitjançant un repte. En el tercer disseny, la passarel·la deixa de ser el verificador i es converteix en un relé: redirigeix el client al proveïdor d'identitat, rep una asserció i assigna la identitat afirmada a un usuari i un grup. En el disseny RADIUS queda entremig i impulsa un intercanvi de petició i resposta amb un backend que té la política.

Aquesta diferència decideix quines proves podeu recollir. Quan la passarel·la verifica, la seva pròpia sortida de depuració us diu què ha passat. Quan verifica un proveïdor d'identitat, la passarel·la només sap que ha arribat una asserció, i la resposta a «calia realment MFA» viu als registres del proveïdor, no als del tallafoc. Llegir el registre equivocat és la manera més habitual de diagnosticar malament un desplegament que es comporta exactament com es va dissenyar. El servei també limita la cerimònia: FortiOS 7.6.3 elimina el mode túnel d'SSL VPN en favor d'IPsec, mentre que el mode web continua com a Agentless VPN en els models compatibles, de manera que una cerimònia provada en un servei no està automàticament disponible en un altre.

Verificació local: tokens i codis per correu

Els factors gestionats pel FortiGate s'adjunten a l'objecte d'usuari. Un FortiToken o una integració de token documentada necessita registre, la cerimònia de verificació compatible, llicència quan correspongui i un procediment de substitució. Un codi enviat per correu necessita un camí SMTP funcional i una bústia a què l'usuari pugui arribar abans que existeixi el túnel, una dependència que no té res a veure amb la criptografia i ho té tot a veure amb si algú pot iniciar sessió.

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

El lliurament del correu forma part de la disponibilitat de l'autenticació. Una bústia accessible només a través de la VPN crea un bucle que no es resol per a ningú, i el retard de lliurament, la validesa del codi i el temps d'espera de l'autenticació remota són tres restriccions separades. Apujar-ne una no arregla una bústia inaccessible, i un disseny que mai no ha provat el bucle el descobrirà durant el primer restabliment de contrasenya després d'unes vacances.

Els requisits d'assegurament també van aquí, abans de triar el producte. NIST SP 800-63B considera el correu inacceptable per a l'autenticació fora de banda, així que un desplegament que afirma conformitat no pot fer servir un codi per correu com a segon factor, per convenient que sigui. Que una funció existeixi a l'aparell no vol dir que la funció compleixi un estàndard determinat.

RADIUS: la passarel·la pregunta, el backend decideix

Amb RADIUS, el FortiGate envia la credencial a un backend que té la política dels factors. L'intercanvi pot ser un simple acceptar o rebutjar, o pot implicar un repte que el client ha de respondre, cosa que vol dir que tant el servei VPN com el client han de suportar aquesta forma de repte. Un backend que imposa una aprovació push i un client que només sap afegir un codi de sis xifres a una contrasenya no es trobaran al mig.

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>

Proveu el backend independentment abans de culpar el túnel. Si la prova d'authserver té èxit i un inici de sessió VPN no, la diferència és en el tractament del repte i no en la credencial, i la depuració del dimoni d'autenticació de la passarel·la és on es veu:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: el navegador surt de la passarel·la

En un disseny SAML, el client es redirigeix al proveïdor d'identitat, s'autentica allà i torna amb una asserció que la passarel·la valida contra una relació de confiança i un mapatge de grups. La passarel·la no veu mai la contrasenya ni el segon factor, cosa que és alhora una millora de seguretat i una complicació operativa: ara la fallada passa en una sessió de navegador que el tallafoc no pot inspeccionar.

Acceptar una asserció no demostra que el proveïdor exigís MFA per a aquell inici de sessió. Una política del proveïdor que aplica MFA a algunes aplicacions i no a altres produirà exactament l'inici de sessió que heu demanat i cap de l'assegurament que havíeu suposat. Comproveu la política del proveïdor per a aquesta aplicació concreta i comproveu que el mapatge de les afirmacions de grup als grups de FortiGate encara coincideix després de qualsevol canvi de nom a qualsevol banda.

El suport del client aquí importa més que enlloc. Alguns clients VPN gestionen el traspàs al navegador de manera nativa, d'altres obren el navegador del sistema, i els clients sense interfície o de línia d'ordres potser no completen el flux. Proveu-ho amb el client que els usuaris fan servir realment, a les plataformes que fan servir realment, abans de publicar el perfil.

La recuperació forma part del mecanisme

Cada disseny anterior té una dependència que pot fallar per a un usuari alhora: una bústia inaccessible, un token perdut, un backend que rebutja un repte, un compte de proveïdor d'identitat bloquejat. Decidiu ara qui pot restaurar l'accés, amb quin procediment compatible i amb quina verificació de la persona que ho demana. Un compte d'administrador local d'emergència mantingut separat del camí VPN és un control; i un bypass inexplicat només amb contrasenya és un incident esperant a ser descobert.

Després proveu tres inicis de sessió abans del desplegament: el normal, un factor rebutjat o caducat i la recuperació aprovada d'un autenticador perdut. Anoteu en quin registre apareix cadascun. Aquest registre és el que converteix «MFA està activat» en un disseny que algú altre pot operar.