通过

从 MFA 服务器迁移到 Microsoft Entra 多重身份验证

  • 项目

多重身份验证为基础结构和资产免受恶意行动者的入侵发挥了重要作用。 Azure 多重身份验证服务器（MFA 服务器）不适用于新部署，将被弃用。 使用 MFA 服务器的客户应改用基于云的 Microsoft Entra 多重身份验证。

本文假设你有一个混合环境，在其中：

  • 你要使用 MFA 服务器实现多重身份验证。
  • 你正在将 Microsoft Entra ID 上的联合身份验证与 Active Directory 联合身份验证服务 (AD FS) 或其他标识提供者联合身份验证产品配合使用。
    • 尽管本文所述内容的范围限于 AD FS，但类似的步骤也适用于其他标识提供者。
  • MFA 服务器已与 AD FS 集成。
  • 可能有应用程序正在使用 AD FS 进行身份验证。

你的迁移有多种可能的最终状态，具体取决于你的目标。


 目标：仅停用 MFA 服务器 目标：停用 MFA 服务器并迁移到 Microsoft Entra 身份验证 目标：停用 MFA 服务器和 AD FS
MFA 提供程序 将 MFA 提供程序从 MFA 服务器更改为 Microsoft Entra 多重身份验证。 将 MFA 提供程序从 MFA 服务器更改为 Microsoft Entra 多重身份验证。 将 MFA 提供程序从 MFA 服务器更改为 Microsoft Entra 多重身份验证。
用户身份验证 继续使用联合身份验证进行 Microsoft Entra 身份验证。 迁移到提供密码哈希同步（首选）或直通身份验证以及无缝单一登录 (SSO) 的 Microsoft Entra ID。 迁移到提供密码哈希同步（首选）或直通身份验证以及 SSO 的 Microsoft Entra ID。
应用程序身份验证 继续对应用程序使用 AD FS 身份验证。 继续对应用程序使用 AD FS 身份验证。 在迁移到 Microsoft Entra 多重身份验证之前，先将应用移动到 Microsoft Entra ID。

如果可能，请将多重身份验证和用户身份验证都迁移到 Azure。 有关分步指南，请参阅迁移到 Microsoft Entra 多重身份验证和 Microsoft Entra 用户身份验证。

如果无法迁移用户身份验证，请参阅有关通过联合迁移到 Microsoft Entra 多重身份验证的分步指南。

先决条件

  • AD FS 环境（如果在迁移 MFA 服务器之前未将所有应用迁移到 Microsoft Entra，则必须创建此环境）
    • 升级到 AD FS for Windows Server 2019，场行为级别 (FBL) 4。 通过这种升级，可以根据组成员身份选择身份验证提供程序，使用户过渡更加顺畅。 尽管在 AD FS for Windows Server 2016 FBL 3 上可以进行迁移，但这种迁移对于用户而言不是很顺畅。 在迁移过程中，在迁移完成之前，系统会提示用户选择身份验证提供程序（MFA 服务器或 Microsoft Entra 多重身份验证）。
  • 权限
    • Active Directory 中有权为 Microsoft Entra 多重身份验证配置 AD FS 场的企业管理员角色
    • 需要全局管理员来管理此功能。

所有迁移路径的注意事项

从 MFA 服务器到 Microsoft Entra 多重身份验证的迁移过程不只是涉及到移动已注册的 MFA 电话号码。 Microsoft 的 MFA 服务器可与多个系统集成，必须评估这些系统如何使用 MFA 服务器，以了解与 Microsoft Entra 多重身份验证集成的最佳方式。

迁移 MFA 用户信息

分批移动用户的常见方式包括按区域、部门或角色（例如管理员）移动用户。 应以迭代方式移动用户帐户，从测试和试点组开始，并确保已制定好回滚计划。

可以使用 MFA 服务器迁移实用工具将本地 Azure MFA 服务器中存储的 MFA 数据同步到 Microsoft Entra 多重身份验证，并使用分阶段推出将用户重新路由到 Azure MFA。 分阶段推出可帮助你进行测试，而无需更改域联合设置。

为了帮助用户区分新添加的帐户与链接到 MFA 服务器的旧帐户，请确保 MFA 服务器上移动应用的帐户名以一种能够区分这两个帐户的方式命名。 例如，在 MFA 服务器上的移动应用下显示的帐户名已重命名为“本地 MFA 服务器”。 在下一次向用户发送推送通知时，Microsoft Authenticator 中的帐户名将会更改。

迁移电话号码还可能导致迁移过时的号码，并很有可能会使用户保持使用基于电话的 MFA，而不是设置更安全的方法，例如，在无密码模式下使用 Microsoft Authenticator。 因此，无论你选择哪种迁移路径，我们都建议让所有用户注册组合安全性信息。

迁移硬件安全密钥

Microsoft Entra ID 提供 OATH 硬件令牌支持。 可以使用 MFA 服务器迁移实用工具在 MFA 服务器与 Microsoft Entra 多重身份验证之间同步 MFA 设置，并使用分阶段推出测试用户迁移，而无需更改域联合设置。

如果只想迁移 OATH 硬件令牌，则需要使用 CSV 文件（通常称为“种子文件”）将令牌上传到 Microsoft Entra ID。 种子文件包含机密密钥和令牌序列号，以及将令牌上传到 Microsoft Entra ID 所需的其他必要信息。

如果你不再拥有包含机密密钥的种子文件，则无法从 MFA 服务器导出机密密钥。 如果你不再有权访问机密密钥，请与硬件供应商联系以请求支持。

可以使用 MFA 服务器 Web 服务 SDK 导出分配到给定用户的任何 OATH 令牌的序列号。 可将此信息与种子文件一起使用，以将令牌导入 Microsoft Entra ID，并基于序列号将 OATH 令牌分配给指定用户。 在导入时，还需要联系用户，让其提供设备中的 OTP 信息以完成注册。 请参阅 MFA 服务器上的多重身份验证服务器中的帮助文件主题“GetUserInfo”>“userSettings”>“OathTokenSerialNumber”。

其他迁移方案

决定从 MFA 服务器迁移到 Microsoft Entra 多重身份验证可以打开其他迁移方案的大门。 如何完成其他迁移方案取决于多种因素，具体包括：

  • 为用户使用 Microsoft Entra 身份验证的意愿
  • 将应用程序迁移到 Microsoft Entra ID 的意愿

由于 MFA 服务器与应用程序和用户身份验证集成，因此，请考虑在 MFA 迁移过程中将这两项功能都迁移到 Azure，并最终停用 AD FS。

我们的建议：

  • 使用 Microsoft Entra ID 进行身份验证，因为它可以实现更可靠的安全性和治理
  • 如果可能，将应用程序迁移到 Microsoft Entra ID

若要选择最适合你的组织的用户身份验证方法，请参阅为 Microsoft Entra 混合标识解决方案选择适当的身份验证方法。 我们建议使用密码哈希同步 (PHS)。

无密码身份验证

在注册用户以使用 Microsoft Authenticator 作为第二个因素的过程中，我们建议在用户注册过程中启用无密码手机登录。 有关详细信息（包括 FIDO2 安全密钥和 Windows Hello 企业版等其他无密码方法），请访问规划使用 Microsoft Entra ID 的无密码身份验证部署。

Microsoft Identity Manager 自助式密码重置

在执行密码重置流的过程中，Microsoft Identity Manager (MIM) SSPR 可以使用 MFA 服务器调用一次性短信密码。 无法将 MIM 配置为使用 Microsoft Entra 多重身份验证。 建议评估是否要将 SSPR 服务迁移到 Microsoft Entra SSPR。 凭借用户注册的机会，可以让 Microsoft Entra 多重身份验证使用组合注册体验来注册 Microsoft Entra SSPR。

如果无法移动 SSPR 服务，或者利用 MFA 服务器对调用特权访问管理 (PAM) 方案的 MFA 请求，建议更新为备用第三方 MFA 选项。

RADIUS 客户端和 Microsoft Entra 多重身份验证

MFA 服务器支持通过 RADIUS 来为支持该协议的应用程序和网络设备调用多重身份验证。 如果将 RADIUS 与 MFA 服务器配合使用，我们建议将客户端应用程序迁移到新式协议，例如 SAML、Open ID Connect，或 Microsoft Entra ID 上的 OAuth。 如果无法更新应用程序，可以使用 Microsoft Entra 多重身份验证扩展来部署网络策略服务器 (NPS)。 网络策略服务器 (NPS) 扩展充当基于 RADIUS 的应用程序与 Microsoft Entra 多重身份验证之间的适配器，提供身份验证的第二因素。 使用此“适配器”，可以将 RADIUS 客户端迁移到 Microsoft Entra 多重身份验证并解除 MFA 服务器。

重要注意事项

为 RADIUS 客户端使用 NPS 时存在一些限制，我们建议评估所有 RADIUS 客户端，确定是否可将其升级到新式身份验证协议。 有关支持的产品版本及其功能，请咨询服务提供商。

  • NPS 扩展不使用 Microsoft Entra 条件访问策略。 如果继续使用 RADIUS，并且使用 NPS 扩展，则转到 NPS 的所有身份验证请求都会要求用户执行 MFA。
  • 用户必须先注册 Microsoft Entra 多重身份验证才能使用 NPS 扩展。 否则，该扩展无法对用户进行身份验证，从而可能导致用户呼叫支持人员。
  • 当 NPS 扩展调用 MFA 时，MFA 请求将发送到用户的默认 MFA 方法。
    • 由于登录发生在非 Microsoft 应用程序上，因此用户通常看不到需要执行多重身份验证并且已将请求发送到其设备的视觉通知。
    • 在处理多重身份验证要求期间，用户必须能够访问其默认身份验证方法才能满足要求。 用户无法选择替代方法。 即使租户身份验证方法和多重身份验证策略中已禁用默认身份验证方法，也将使用该方法。
    • 用户可以在“安全信息”页 (aka.ms/mysecurityinfo) 中更改其默认多重身份验证方法。
  • RADIUS 客户端的可用 MFA 方法由发送 RADIUS 访问请求的客户端系统控制。
    • 要求用户在输入密码后输入的 MFA 方法只能用于支持 RADIUS 的访问质询响应的系统。 输入方法可能包括 OTP、硬件 OATH 令牌或 Microsoft Authenticator。
    • 某些系统可能会将可用多重身份验证方法限制为 Microsoft Authenticator 推送通知和电话呼叫。

注意

在 RADIUS 客户端与 NPS 系统之间使用的密码加密算法以及客户端可以使用的输入方法会影响哪些身份验证方法可供使用。 有关详细信息，请参阅确定用户可以使用的身份验证方法。

常见的 RADIUS 客户端集成包括远程桌面网关和 VPN 服务器等应用程序。 其他应用程序可能包括：

有关部署 NPS 的资源

后续步骤