FortiGate VPN MFA : jeton local, RADIUS ou SAML ?

Chaque conception de FortiGate VPN MFA répond d'abord à une question : qui vérifie le second facteur ? La passerelle elle-même peut le faire avec un jeton local ou un code envoyé par courriel, un backend RADIUS peut l'imposer et renvoyer un défi, ou un fournisseur d'identité SAML peut prendre en charge toute la cérémonie dans un navigateur. Chacune produit une séquence de connexion différente, une signature d'échec différente et une procédure de récupération différente, et copier un bloc de commandes de l'une à l'autre produit une configuration qui semble plausible et n'authentifie personne. C'est un article de mécanisme : ce que chaque conception fait réellement pendant une connexion, et où elle casse.

La cérémonie de connexion décide qui possède le facteur

Dans les deux premières conceptions, le FortiGate est la partie qui fait confiance. Il collecte l'identifiant, décide si un second facteur est requis et le vérifie localement ou en demandant un défi. Dans la troisième conception, la passerelle cesse d'être le vérificateur et devient un relais : elle redirige le client vers le fournisseur d'identité, reçoit une assertion et associe l'identité affirmée à un utilisateur et à un groupe. Dans la conception RADIUS, elle se situe entre les deux et pilote un échange demande-réponse avec un backend qui détient la politique.

Cette différence décide des preuves que vous pouvez recueillir. Quand la passerelle vérifie, sa propre sortie de débogage vous dit ce qui s'est passé. Quand un fournisseur d'identité vérifie, la passerelle sait seulement qu'une assertion est arrivée, et la réponse à « le MFA était-il réellement exigé » se trouve dans les journaux du fournisseur, pas dans ceux du pare-feu. Lire le mauvais journal est la façon la plus courante de mal diagnostiquer un déploiement qui se comporte exactement comme prévu. Le service lui-même borne la cérémonie : FortiOS 7.6.3 supprime le mode tunnel SSL VPN au profit d'IPsec, tandis que le mode web continue comme Agentless VPN sur les modèles pris en charge, si bien qu'une cérémonie prouvée sur un service n'est pas automatiquement disponible sur un autre.

Vérification locale : jetons et codes par courriel

Les facteurs gérés par le FortiGate sont attachés à l'objet utilisateur. Un FortiToken ou une intégration de jeton documentée nécessite un enrôlement, la cérémonie de vérification prise en charge, une licence le cas échéant et une procédure de remplacement. Un code envoyé par courriel nécessite un chemin SMTP fonctionnel et une boîte aux lettres que l'utilisateur peut atteindre avant que le tunnel existe, une dépendance qui n'a rien à voir avec la cryptographie et tout à voir avec la possibilité de se connecter.

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

L'acheminement du courriel fait partie de la disponibilité de l'authentification. Une boîte aux lettres accessible uniquement par le VPN crée une boucle qui ne se résout pour personne, et le délai d'acheminement, la validité du code et le délai d'expiration de l'authentification distante sont trois contraintes distinctes. Relever l'une ne répare pas une boîte aux lettres inaccessible, et une conception qui n'a jamais testé la boucle la découvrira lors de la première réinitialisation de mot de passe après des vacances.

Les exigences d'assurance appartiennent aussi ici, avant le choix du produit. NIST SP 800-63B considère le courriel comme inacceptable pour l'authentification hors bande, donc un déploiement qui revendique la conformité ne peut pas utiliser un code par courriel comme second facteur, aussi pratique soit-il. Qu'une fonction existe sur l'appareil n'affirme pas qu'elle satisfait une norme donnée.

RADIUS : la passerelle demande, le backend décide

Avec RADIUS, le FortiGate envoie l'identifiant à un backend qui possède la politique des facteurs. L'échange peut être une simple acceptation ou un rejet, ou il peut impliquer un défi auquel le client doit répondre, ce qui signifie que le service VPN et le client doivent tous deux prendre en charge cette forme de défi. Un backend qui impose une approbation push et un client qui ne sait qu'ajouter un code à six chiffres à un mot de passe ne se rencontreront pas à mi-chemin.

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>

Testez le backend indépendamment avant d'accuser le tunnel. Si le test authserver réussit et qu'une connexion VPN échoue, la différence réside dans le traitement du défi et non dans l'identifiant, et le débogage du démon d'authentification de la passerelle est l'endroit où cela se voit :

diagnose debug application fnbamd -1
diagnose debug enable

SAML : le navigateur quitte la passerelle

Dans une conception SAML, le client est redirigé vers le fournisseur d'identité, s'y authentifie et revient avec une assertion que la passerelle valide au regard d'une relation de confiance et d'un mappage de groupes. La passerelle ne voit jamais le mot de passe ni le second facteur, ce qui est à la fois une amélioration de la sécurité et une complication opérationnelle : l'échec se produit désormais dans une session de navigateur que le pare-feu ne peut pas inspecter.

Accepter une assertion ne prouve pas que le fournisseur exigeait le MFA pour cette connexion. Une politique de fournisseur qui applique le MFA à certaines applications et pas à d'autres produira exactement la connexion demandée et rien de l'assurance escomptée. Vérifiez la politique du fournisseur pour cette application précise, et vérifiez que le mappage des revendications de groupe vers les groupes FortiGate correspond toujours après tout renommage de part et d'autre.

Le support client compte ici plus qu'ailleurs. Certains clients VPN gèrent nativement le passage au navigateur, d'autres ouvrent le navigateur du système, et les clients sans interface ou en ligne de commande peuvent ne pas achever le flux du tout. Testez avec le client que les utilisateurs exécutent réellement, sur les plateformes qu'ils utilisent réellement, avant de publier le profil.

La récupération fait partie du mécanisme

Chaque conception ci-dessus a une dépendance qui peut défaillir pour un utilisateur à la fois : une boîte aux lettres inaccessible, un jeton perdu, un backend qui refuse un défi, un compte de fournisseur d'identité verrouillé. Décidez maintenant qui peut restaurer l'accès, par quelle procédure prise en charge et avec quelle vérification de la personne qui le demande. Un compte d'administrateur local d'urgence maintenu à l'écart du chemin VPN est un contrôle; et un contournement inexpliqué par mot de passe seul est un incident qui attend d'être découvert.

Testez ensuite trois connexions avant le déploiement : la normale, un facteur refusé ou expiré et la récupération approuvée d'un authentificateur perdu. Notez dans quel journal chacune apparaît. C'est ce relevé qui transforme « le MFA est activé » en une conception que quelqu'un d'autre peut exploiter.