mysql本身不支持原生mfa，需通过authentication_pam（对接pam_google_authenticator）或authentication_ldap_sasl（依赖已启用mfa的ldap/ad服务）委托第二因子验证，且必须mysql≥8.0.27、对应插件active、用户显式声明require multifactor。
MySQL 本身不支持原生 MFA，所谓「配置 MFA」实际是把第二因子验证委托给外部系统——要么走 LDAP（依赖 AD/Duo/Okta 等已启用 MFA 的目录服务），要么走 Linux PAM（对接 pam_google_authenticator、pam_duo 等模块）。两者都要求 MySQL 启用对应插件，并严格匹配认证链顺序和用户映射逻辑。
确认 MySQL 版本与插件可用性
低于 8.0.27 的版本不支持 REQUIRE MULTIFACTOR 语法，也无法正确加载 authentication_policy 插件。必须先执行：
SELECT VERSION();
再查插件状态：
SHOW PLUGINS LIKE 'authentication%';
关键插件需处于 ACTIVE 状态，包括：
-
authentication_pam（PAM 方案必需） -
authentication_ldap_sasl（LDAP 方案必需，仅企业版完整支持） -
authentication_policy（MFA 策略编排必需，8.0.27+才有）
若缺失，需手动安装，例如：
INSTALL PLUGIN authentication_pam SONAME 'authentication_pam.so';
注意：SONAME 名称在不同发行版可能为 auth_pam.so 或带路径，须查 SELECT @@plugin_dir; 后确认文件是否存在。
用 PAM 实现密码 + TOTP 双因子（Linux 系统级）
PAM 是社区版最可行的落地方式，但极易因配置错位导致全量用户锁死。核心陷阱在三处：PAM service 名、密钥文件路径权限、MySQL 用户定义语法。
- PAM 配置文件必须新建或修改为
/etc/pam.d/mysqld（不是mysql或mysqld_safe），内容示例：
auth [success=ok default=bad] pam_google_authenticator.so secret=/var/lib/mysql-pam/${USER}.google_authenticator
auth [success=done default=ignore] pam_unix.so
- 每个 MySQL 用户必须对应一个同名 Linux 用户，且该用户已运行
google-authenticator -t -d -f -r 3 -w 3生成密钥文件，权限为600，属主严格匹配 - 创建用户时不能写
IDENTIFIED BY，否则覆盖 PAM 认证方式；必须用：
CREATE USER 'alice'@'%' IDENTIFIED WITH authentication_pam AS 'mysqld';
其中 mysqld 必须与 PAM service 文件名一致（即 /etc/pam.d/mysqld）。
客户端连接时还需显式启用明文插件：mysql --enable-cleartext-plugin -u alice -p，否则报错 Authentication plugin 'authentication_pam' cannot be loaded。
用 LDAP 集成已有 MFA 目录服务（如 Microsoft Entra ID / Okta）
此方案不依赖 MySQL 做任何令牌校验，而是把整个认证流程交给 LDAP 服务器——只要目录服务本身启用了 Duo/Okta/MFA 策略，MySQL 就自动获得第二因子能力。但社区版功能受限，企业版更稳定。
- 必须确保 LDAP 服务可达、支持
simple bind、且账户 DN 可唯一映射到 MySQL 用户 - 启用插件后，用户创建语法为：
CREATE USER 'bob'@'%' IDENTIFIED WITH authentication_ldap_sasl USING 'uid=bob,ou=users,dc=example,dc=com';
注意：authentication_ldap_sasl 在社区版中仅支持基本绑定，高级策略（如组过滤、MFA 触发条件）需企业版或自建中间层。
如果 LDAP 侧已配置 MFA 强制策略，MySQL 登录失败日志里通常只显示 Access denied for user，真实原因需查 LDAP 服务端日志，而非 MySQL error log。
为什么 authentication_policy 设置容易失效
authentication_policy 变量只是策略开关，它本身不校验任何因子，只按顺序调用已注册的认证插件。常见错误是：
- 设了
SET GLOBAL authentication_policy = '*,authentication_fido';，但没装authentication_fido插件 → 登录直接拒 - 设了
'mysql_native_password,authentication_pam'，但 PAM 插件未启用或 service 名不匹配 → 第二因子被跳过，退化为单因子 - 用户创建时没显式声明多因子，例如漏掉
REQUIRE MULTIFACTOR→ 即使全局策略开启，该用户仍按单因子处理
真正生效的语句应类似：
CREATE USER 'carol'@'%' IDENTIFIED WITH mysql_native_password BY 'p1' REQUIRE MULTIFACTOR AUTHENTICATION USING 'authentication_pam' AS 'mysqld';
这里 mysql_native_password 是第一因子（密码），authentication_pam 是第二因子（TOTP），二者缺一不可，且顺序不能颠倒。
时间同步、密钥文件路径拼接、PAM 模块返回码映射——这些细节不出现在 SQL 层，却决定整个 MFA 链路是否成立。调试时优先看 /var/log/secure 或 journalctl -u mysqld，而不是只盯 MySQL 日志。
