FortiGate VPN MFA: ¿token local, RADIUS o SAML?

Cada diseño de FortiGate VPN MFA responde primero una pregunta: ¿quién verifica el segundo factor? La propia puerta de enlace puede hacerlo con un token local o un código enviado por correo, un backend RADIUS puede imponerlo y devolver un desafío, o un proveedor de identidad SAML puede asumir toda la ceremonia en un navegador. Cada opción produce una secuencia de inicio de sesión distinta, una firma de fallo distinta y un procedimiento de recuperación distinto, y copiar un bloque de comandos entre ellas produce una configuración que parece plausible y no autentica a nadie. Este es un artículo de mecanismo: qué hace realmente cada diseño durante un inicio de sesión y dónde se rompe.

La ceremonia de inicio de sesión decide quién posee el factor

En los dos primeros diseños, el FortiGate es la parte que confía. Recoge la credencial, decide si se requiere un segundo factor y lo verifica localmente o mediante un desafío. En el tercer diseño, la puerta de enlace deja de ser el verificador y se convierte en un relé: redirige al cliente al proveedor de identidad, recibe una aserción y asigna la identidad afirmada a un usuario y un grupo. En el diseño RADIUS queda en medio e impulsa un intercambio de petición y respuesta con un backend que tiene la política.

Esa diferencia decide qué pruebas puede reunir. Cuando la puerta de enlace verifica, su propia salida de depuración le dice qué ocurrió. Cuando verifica un proveedor de identidad, la puerta de enlace solo sabe que llegó una aserción, y la respuesta a «¿se exigía realmente MFA?» vive en los registros del proveedor, no en los del cortafuegos. Leer el registro equivocado es la forma más habitual de diagnosticar mal un despliegue que se comporta exactamente como se diseñó. El propio servicio también delimita la ceremonia: FortiOS 7.6.3 elimina el modo túnel de SSL VPN en favor de IPsec, mientras que el modo web continúa como Agentless VPN en los modelos compatibles, así que una ceremonia probada en un servicio no está disponible automáticamente en otro.

Verificación local: tokens y códigos por correo

Los factores gestionados por FortiGate se asocian al objeto de usuario. Un FortiToken o una integración de token documentada necesita registro, la ceremonia de verificación admitida, licencia cuando corresponda y un procedimiento de sustitución. Un código enviado por correo necesita una ruta SMTP funcional y un buzón al que el usuario pueda llegar antes de que exista el túnel, una dependencia que no tiene nada que ver con la criptografía y todo que ver con si alguien puede iniciar sesión.

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

La entrega del correo forma parte de la disponibilidad de la autenticación. Un buzón accesible solo a través de la VPN crea un bucle que no se resuelve para nadie, y el retardo de entrega, la validez del código y el tiempo de espera de la autenticación remota son tres restricciones separadas. Elevar una no repara un buzón inaccesible, y un diseño que nunca ha probado el bucle lo descubrirá durante el primer restablecimiento de contraseña tras unas vacaciones.

Los requisitos de aseguramiento también pertenecen aquí, antes de la elección del producto. NIST SP 800-63B considera el correo inaceptable para la autenticación fuera de banda, así que un despliegue que afirme conformidad no puede usar un código por correo como segundo factor, por cómodo que sea. Que una función exista en el dispositivo no declara que esa función cumpla una norma determinada.

RADIUS: la puerta de enlace pregunta, el backend decide

Con RADIUS, el FortiGate envía la credencial a un backend que posee la política de factores. El intercambio puede ser una simple aceptación o rechazo, o puede implicar un desafío que el cliente debe responder, lo que significa que tanto el servicio VPN como el cliente deben admitir esa forma de desafío. Un backend que impone una aprobación push y un cliente que solo sabe añadir un código de seis dígitos a una contraseña no se encontrarán a mitad de camino.

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>

Pruebe el backend de forma independiente antes de culpar al túnel. Si la prueba de authserver tiene éxito y un inicio de sesión VPN no, la diferencia está en el tratamiento del desafío y no en la credencial, y la depuración del demonio de autenticación de la puerta de enlace es donde eso se ve:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: el navegador abandona la puerta de enlace

En un diseño SAML, el cliente es redirigido al proveedor de identidad, se autentica allí y vuelve con una aserción que la puerta de enlace valida contra una relación de confianza y un mapeo de grupos. La puerta de enlace nunca ve la contraseña ni el segundo factor, lo que es a la vez una mejora de seguridad y una complicación operativa: el fallo ocurre ahora en una sesión de navegador que el cortafuegos no puede inspeccionar.

Aceptar una aserción no demuestra que el proveedor exigiera MFA para ese inicio de sesión. Una política del proveedor que aplica MFA a algunas aplicaciones y no a otras producirá exactamente el inicio de sesión que pidió y nada del aseguramiento que supuso. Compruebe la política del proveedor para esta aplicación concreta y compruebe que el mapeo de las afirmaciones de grupo a los grupos de FortiGate sigue coincidiendo tras cualquier cambio de nombre en cualquiera de los lados.

El soporte del cliente importa aquí más que en ningún otro sitio. Algunos clientes VPN gestionan el traspaso al navegador de forma nativa, otros abren el navegador del sistema, y los clientes sin interfaz o de línea de comandos puede que no completen el flujo. Pruebe con el cliente que los usuarios ejecutan realmente, en las plataformas que realmente usan, antes de publicar el perfil.

La recuperación forma parte del mecanismo

Cada diseño anterior tiene una dependencia que puede fallar para un usuario a la vez: un buzón inaccesible, un token perdido, un backend que rechaza un desafío, una cuenta de proveedor de identidad bloqueada. Decida ahora quién puede restaurar el acceso, mediante qué procedimiento admitido y con qué verificación de la persona que lo solicita. Una cuenta de administrador local de emergencia mantenida separada de la ruta VPN es un control; y un bypass inexplicado solo con contraseña es un incidente esperando a ser descubierto.

Después pruebe tres inicios de sesión antes del despliegue: el normal, un factor rechazado o caducado y la recuperación aprobada de un autenticador perdido. Anote en qué registro aparece cada uno. Ese registro es lo que convierte «MFA está activado» en un diseño que otra persona puede operar.