Active Directory 环境下实现 MFA 的本质是构建本地身份到 Microsoft Entra ID 的可信通路：通过 Azure AD Connect 同步账号（启用 PHS/PTA 及组同步）、在 Entra ID 中基于条件访问策略精准作用于高权限组、管理员须提前完成 Authenticator 注册，否则将导致管理中断。
在 active directory 环境下实现多因素身份验证（mfa），本质不是给本地 ad“装个插件”，而是构建一条从本地身份到云侧强认证的可信通路。核心路径是：通过 azure ad connect 同步本地账号 → 在 microsoft entra id（原 azure ad）中定义策略 → 对高权限账号强制执行 mfa。纯本地 windows server ad 本身不支持现代 mfa 流程，必须借助云身份服务完成策略控制与验证执行。
同步配置是前提，不是可选项
本地 AD 账号要被 MFA 策略识别，必须成为 Microsoft Entra ID 中的“混合标识”。这依赖 Azure AD Connect 的正确配置：
- 启用密码哈希同步（PHS）或直通身份验证（PTA），确保登录请求能路由至云侧触发 MFA 检查
- 务必勾选“同步组成员身份”，否则你创建的 HighPrivilege-Users 安全组在云端为空，策略将无目标生效
- 确认用户对象的 userPrincipalName 与本地一致，且 immutableId 正确映射，否则策略匹配失败
- 避免仅同步用户而不同步组、不启用 PHS/PTA——这类常见疏漏会导致 MFA 看似启用实则不生效
策略必须精准作用于高权限账号
条件访问（CA）策略不能笼统面向“所有用户”，应严格限定范围并分阶段上线：
- 用户和组：只选择预定义的安全组（如 HighPrivilege-Users），该组成员应包含 Domain Admins、Enterprise Admins 等实际承担管理职责的账号，而非直接选内置组（因同步限制）
- 云应用：优先锁定关键入口，如 “Microsoft Azure Management”、“Office 365 Exchange Online”，避免影响普通办公应用
- 授予条件：勾选“要求多重身份验证”，其他条件（如位置、设备状态）可作为增强项，但非必需
- 启用前设为“报告仅”模式运行至少 7 天，检查 Sign-in Logs 确认策略命中、无误阻断，再切换为“开启”
管理员必须提前完成 MFA 注册
策略一旦启用，未注册 MFA 的高权限账号将无法登录任何受保护的云服务（包括 Azure 门户、Exchange 后台等），导致管理中断：
- 推荐使用 Microsoft Authenticator 应用，配置“通知+验证码”双方式，兼顾安全性与可用性
- 引导管理员访问 https://aka.ms/MFASetup 完成自助注册，注册过程需在策略启用前全部完成
- 保留至少 2 个独立维护的应急管理员账号（不在同一安全组、使用不同验证方式），并确保其 MFA 已激活且可离线验证
- 同步启用登录日志、风险检测与活动审计，便于事后追溯异常登录尝试
补充建议：降低实施风险
MFA 集成不是一次性开关，而是持续运营过程：
- 定期审查 HighPrivilege-Users 组成员，及时移出已转岗或离职人员
- 禁用长期不用的管理员账号，避免其成为沉默的攻击入口
- 对所有管理员开展 MFA 故障恢复培训，例如备用验证方式切换、恢复密钥保管等
- 避免依赖短信验证码作为唯一第二因素，因其易受 SIM 交换攻击；优先选择 Authenticator 或硬件令牌
