Windows本地账户不支持直接启用双重身份验证，必须通过Microsoft Entra ID集成并配置条件访问策略实现MFA；或结合“受保护的用户”组、Kerberos强加密、RDP+NLA+Entra ID等方案分层加固。
windows 本身不支持直接在本地用户组（如 administrators）中为账户“开启双重身份验证”。本地账户体系没有内置 mfa 机制，所有对特权账户的双重验证限制，必须通过云身份集成或企业级身份基础设施来实现。
将特权账户绑定 Microsoft Entra ID 并启用条件访问策略
这是最标准、最可控的企业级做法。本地管理员账户无法直接加 MFA，但如果你把高权限用户（比如域管理员、服务管理员）映射为 Entra ID 中的云账户（例如 admin@contoso.com），就能统一管控其登录行为：
- 确保该账户已同步或直接创建于 Microsoft Entra ID，并分配至少 Entra ID Free 许可证
- 在 Entra 管理中心 → 安全 → 条件访问 中新建策略，目标用户选择该管理员账户或所属安全组（如 “Privileged Admins”）
- 设置“访问控制 → 授予”为“要求多重身份验证”，并勾选“仅限云应用”或“所有云应用”，视实际登录场景而定（如 Windows 登录、RDP、Microsoft 365）
- 策略生效后，该账户在新设备登录、高风险 IP 登录或首次加入 Entra ID 的 Windows 设备时，会强制触发 Authenticator 推送、FIDO2 密钥或 OATH 验证码等第二因素
用“受保护的用户”组配合 Kerberos 策略加固
这是针对 Active Directory 域环境的补充手段，虽不等于 MFA，但能显著缩小攻击面，防止凭证窃取后被滥用：
- 将高特权账户（如 Domain Admins 成员）加入内建的 Protected Users 安全组
- 该组自动禁用不安全的身份验证协议：NTLM、Kerberos 预身份验证加密类型（如 RC4）、凭据缓存、以及远程桌面的密码哈希重用
- 同时需配合组策略，在“计算机配置 → 策略 → Windows 设置 → 安全设置 → 账户策略 → Kerberos 策略”中启用强加密类型（AES128/256）
- 注意：此方案不提供第二因素，但它让“只靠密码”或“只靠哈希”的横向移动几乎失效，是 MFA 的重要前置基础
为远程管理通道单独启用 MFA（如 RDP + NLA + Entra ID）
若暂时无法全面迁移管理员账户至 Entra ID，可优先加固最常被攻击的远程入口：
- 确保目标 Windows Server 或 Pro 设备已加入 Entra ID（非仅传统域控），且启用了 Azure AD 登录功能
- 在组策略中启用“网络级别身份验证（NLA）”，路径：计算机配置 → 管理模板 → Windows 组件 → 远程桌面服务 → 远程桌面会话主机 → 安全 → 要求使用网络级别身份验证对远程连接进行身份验证
- 配合 Entra ID 条件访问策略，将 RDP 登录识别为“云应用”，强制 MFA；用户连接时将看到 Web 认证页，而非传统登录框
- 此方式不影响本地交互式登录，但能确保所有远程管理员操作都经过双因素校验
避免误用 Windows Hello for Business 替代 MFA 策略
Windows Hello for Business（WHfB）常被误解为“本地 MFA”，其实它是一种设备绑定的无密码强身份验证方案，需正确部署才有效：
- WHfB 不是“本地 PIN + 生物识别 = 双因素”，而是“PIN/生物特征 + 设备密钥证书”，属于微软认证的 MFA 合规方式
- 必须在 Entra ID 中启用 WHfB 策略，并通过 Intune 或组策略推送到目标设备；仅在本地账户上设置 PIN 不具备同等安全性
- 对特权账户启用 WHfB 后，登录即完成强验证，无需短信或推送——但前提是设备已注册、策略已下发、且未被绕过（如禁用 NLA 或降级到旧版 RDP 客户端）
