FortiGate VPN MFA：本地令牌、RADIUS 还是 SAML？

网关、RADIUS 后端或 SAML 提供方都能验证这个因素，而各自的失败方式不同。要把服务、客户端与恢复路径匹配起来。

每一种 FortiGate VPN MFA 设计都要先回答一个问题：谁来验证第二因素？网关自己可以用本地令牌或邮件验证码完成，RADIUS 后端可以强制执行并返回一个挑战，SAML 身份提供方则可以在浏览器中承担整套流程。每种做法都会产生不同的登录序列、不同的失败特征和不同的恢复流程，而在它们之间照搬命令块，只会得到一份看起来合理却谁也验证不了的配置。这是一篇讲机制的文章：每种设计在登录过程中究竟做了什么，以及在哪里会断。

登录流程决定了谁拥有这个因素

在前两种设计里，FortiGate 是依赖方。它收集凭据，判断是否需要第二因素，并在本地验证或通过挑战提示来验证。在第三种设计里，网关不再是验证者，而成为中继：它把客户端重定向到身份提供方，接收一条断言，并把断言的标识映射到用户和组。在 RADIUS 设计里，它介于两者之间，与持有策略的后端驱动一次请求与响应的交换。

这个区别决定了你能收集到什么证据。网关自己验证时，它自己的调试输出会告诉你发生了什么。身份提供方验证时，网关只知道来了断言，而“MFA 是否真的被要求”的答案在提供方的日志里，不在防火墙的日志里。读错日志，是误判一次完全按设计运行的部署最常见的方式。服务本身也限定了流程：FortiOS 7.6.3 移除了 SSL VPN 隧道模式，转用 IPsec，而 Web 模式在受支持的型号上继续以 Agentless VPN 形式存在，所以在一个服务上验证过的流程并不会自动适用于另一个。

本地验证：令牌与邮件验证码

FortiGate 管理的因素挂在用户对象上。FortiToken 或受支持的令牌集成需要注册、受支持的验证流程、适用时的许可，以及替换流程。邮件验证码需要可用的 SMTP 路径，以及用户在隧道建立之前就能访问的邮箱，这个依赖与密码学毫无关系，却完全决定了有没有人能登录。

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

邮件投递是认证可用性的一部分。只能通过 VPN 访问的邮箱会形成一个谁也无法自解的循环，而投递延迟、验证码有效期和远程认证超时是三个彼此独立的约束。提高其中一个并不能修复无法访问的邮箱，而从未测试过这个循环的设计，会在假期后第一次重置密码时发现它。

保证要求也应该在这里出现，而且在选型之前。NIST SP 800-63B 认为电子邮件不适合作为带外认证，所以声称符合规范的部署无论多方便，都不能把邮件验证码当作第二因素。设备上存在某个功能，并不等于该功能满足某项标准。

RADIUS：网关提问，后端决定

使用 RADIUS 时，FortiGate 把凭据发给持有因素策略的后端。交换可能只是简单的接受或拒绝，也可能包含客户端必须回答的挑战，这意味着 VPN 服务和客户端都必须支持这种挑战形式。强制推送审批的后端，与只会把六位数字码拼在密码后面的客户端，永远对不上。

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>

在责怪隧道之前，先单独测试后端。如果 authserver 测试成功而 VPN 登录失败，差别在于挑战的处理而不是凭据，网关认证守护进程的调试日志会显示这一点：

diagnose debug application fnbamd -1
diagnose debug enable

SAML：浏览器离开网关

在 SAML 设计里，客户端被重定向到身份提供方，在那里完成认证，然后带着网关依据信任关系和组映射校验的断言返回。网关永远看不到密码和第二因素，这既是安全上的改进，也是运维上的复杂化：失败现在发生在防火墙无法检视的浏览器会话里。

接受断言并不证明提供方对那次登录要求了 MFA。一条只对部分应用启用 MFA 的提供方策略，会给出你要求的登录，却不会给你以为的保证。请检查提供方针对这个具体应用的策略，并确认映射到 FortiGate 组的组声明在任一方改名后仍然匹配。

客户端支持在这里比任何地方都重要。有些 VPN 客户端原生处理浏览器交接，有些会打开系统浏览器，而 无界面或命令行客户端可能根本无法完成这个流程。在发布配置文件之前，要用用户真正运行的客户端、在他们真正使用的平台上测试。

恢复也是机制的一部分

上面每一种设计都有一个可能在同一时间只对某个用户失效的依赖：无法访问的邮箱、丢失的令牌、拒绝挑战的后端、被锁定的身份提供方账户。现在就决定谁能恢复访问、通过哪个受支持的流程，以及对请求者做什么验证。与 VPN 路径分开保存的应急本地管理员账户是一种控制措施；而一个无法解释的仅凭密码的绕过，则是一起等待被发现的事件。

然后在推广前测试三次登录：正常一次、被拒绝或过期的因素一次、以及经批准的丢失认证器恢复一次。记下每一次出现在哪个日志里。正是这份记录，把“MFA 已启用”变成别人可以运维的设计。

相关文章