MFA 服务器迁移

本主题介绍如何将 Microsoft Entra 用户的 MFA 设置从本地 Azure MFA 服务器迁移到 Microsoft Entra 多重身份验证。

解决方案概述

MFA 服务器迁移实用工具有助于将存储在本地 Azure MFA 服务器中的多重身份验证数据直接同步到 Microsoft Entra 多重身份验证。 将身份验证数据迁移到 Microsoft Entra ID 后，用户可以无缝执行基于云的 MFA，而无需再次注册或确认身份验证方法。 管理员可以使用 MFA 服务器迁移实用工具针对单个用户或用户组进行测试和受控推出，而无需在租户范围内进行任何更改。

视频：如何使用 MFA 服务器迁移实用工具

观看我们的视频，大致了解 MFA 服务器迁移实用工具及其工作原理。

限制和要求

• MFA 服务器迁移实用工具要求在主 MFA 服务器上安装 MFA 服务器解决方案的新版本。 此版本对 MFA 服务器数据文件进行更新，并包括新的 MFA 服务器迁移实用工具。 无需更新 WebSDK 或用户门户。 安装更新不会自动启动迁移。

  注意

  可以在辅助 MFA 服务器上执行 MFA 服务器迁移实用工具。 有关详细信息，请查看运行辅助 MFA 服务器（可选）。

• MFA 服务器迁移实用工具将数据从数据库文件复制到 Microsoft Entra ID 中的用户对象。 在迁移期间，可以使用分阶段推出将用户作为 Microsoft Entra ID 多重身份验证的目标以进行测试。 通过分阶段迁移，无需对域联合设置进行任何更改即可进行测试。 迁移完成后，必须通过更改域联合设置来确定迁移。

• 运行 Windows Server 2016 或更高版本的 AD FS 需要在任何 AD FS 依赖方（不包括 Microsoft Entra ID 和 Office 365）上提供 MFA 身份验证。

• 查看 AD FS 访问控制策略，并确保在身份验证过程中没有要求在本地执行 MFA。

• 分阶段推出最多可针对 500,000 个用户（10 个组，每个组最多包含 50,000 个用户）。

迁移指南

阶段	步骤
准备工作	确定 Azure 多重身份验证服务器依赖项
	备份 Azure 多重身份验证服务器数据文件
	安装 MFA 服务器更新
	配置 MFA 服务器迁移实用工具
迁移	迁移用户数据
	验证并测试
	分阶段推出
	让用户了解更多内容
	完成用户迁移
完成	迁移 MFA 服务器依赖项
	更新域联合设置
	禁用 MFA 服务器用户门户
	解除 MFA 服务器的授权

MFA 服务器迁移通常包括以下过程中的步骤：

重要事项：

添加测试用户时，应重复阶段 1。

• 迁移工具使用 Microsoft Entra 组来确定应在 MFA 服务器和 Microsoft Entra 多重身份验证之间同步身份验证数据的用户。 同步用户数据后，该用户即可使用 Microsoft Entra 多重身份验证。
• 分阶段推出允许将用户重新路由到 Microsoft Entra 多重身份验证，也可以使用 Microsoft Entra 组。 虽然你当然可以为这两种工具使用相同的组，但建议不要这样做，因为用户可能会在工具同步其数据之前被重定向到 Microsoft Entra 多重身份验证。 建议设置 Microsoft Entra 组以通过 MFA 服务器迁移实用工具同步身份验证数据，并设置另一组用于分阶段推出的组以将目标用户定向到 Microsoft Entra 多重身份验证，而不是本地。

迁移用户群时，应重复阶段 2。 到阶段 2 结束时，整个用户群应针对 Microsoft Entra ID 联合的所有工作负载使用 Microsoft Entra 多重身份验证。

在之前的阶段，可以从分阶段推出文件夹中移除用户，使其脱离 Microsoft Entra 多重身份验证的范围，并将其路由回本地 Azure MFA 服务器，以处理源自 Microsoft Entra ID 的所有 MFA 请求。

阶段 3 需要通过 SAML/OAUTH 将所有向本地 MFA 服务器（VPN、密码管理器等）进行身份验证的客户端迁移到 Microsoft Entra 联合身份验证。 如果不支持新式身份验证标准，则需要设置安装了 Microsoft Entra 多重身份验证扩展的 NPS 服务器。 迁移依赖项后，用户不应再使用 MFA 服务器上的用户门户，而应在 Microsoft Entra ID (aka.ms/mfasetup) 中管理其身份验证方法。 一旦用户开始在 Microsoft Entra ID 中管理其身份验证数据，这些方法将不会同步回 MFA 服务器。 如果你在用户更改 Microsoft Entra ID 中的身份验证方法后回滚到本地 MFA 服务器，这些更改将丢失。 用户迁移完成后，更改 federatedIdpMfaBehavior 域联合身份验证设置。 此更改指示 Microsoft Entra ID 不再在本地执行 MFA，而是使用 Microsoft Entra 多重身份验证执行所有 MFA 请求，无论组成员身份如何。

以下部分更详细地介绍了迁移步骤。

确定 Azure 多重身份验证服务器依赖项

我们一直在努力确保迁移到基于云的 Microsoft Entra 多重身份验证解决方案将保持甚至改善你的安全态势。 有三大类别应用于对依赖项进行分组：

• MFA 方法
• 用户门户
• 身份验证服务

为了帮助你进行迁移，我们将广泛使用的 MFA 服务器功能与 Microsoft Entra 多重身份验证中每个类别的等效项进行了匹配。

MFA 方法

打开 MFA 服务器，单击“公司设置”：

MFA 服务器	Microsoft Entra 多重身份验证
“常规”选项卡
“用户默认值”部分
电话呼叫（标准）	无需操作
短信 (OTP)*	无需操作
移动应用（标准）	无需操作
电话呼叫 (PIN)*	启用语音 OTP
短信 (OTP + PIN)**	无需操作
移动应用 (PIN)*	启用数字匹配
电话呼叫/短信/移动应用/OATH 令牌语言	语言设置将根据用户浏览器中的区域设置自动应用于用户
默认 PIN 规则部分	不适用；更新方法见上述屏幕截图
“用户名解析”选项卡	不适用；Microsoft Entra 多重身份验证不需要用户名解析
“短信”选项卡	不适用；Microsoft Entra 多重身份验证对短信使用默认消息
OATH 令牌选项卡	不适用；Microsoft Entra 多重身份验证对 OATH 令牌使用默认消息
报表	Microsoft Entra 身份验证方法活动报告

^*如果 PIN 用于提供在场证明功能，上面提供了功能等效项。 未以加密方式绑定到设备的 PIN 不足以防范设备遭到入侵的情况。 为了防范这些情况（包括 SIM 交换攻击），请根据 Microsoft 身份验证方法最佳做法将用户切换为更安全的方法。

^**Microsoft Entra 多重身份验证中的默认短信 MFA 体验会向用户发送一个代码，用户需要在身份验证过程中在登录窗口输入该代码。 往返代码这一要求可提供在场证明功能。

用户门户

打开 MFA 服务器，单击“用户门户”：

MFA 服务器	Microsoft Entra 多重身份验证
“设置”选项卡
用户门户 URL	aka.ms/mfasetup
允许用户注册	请参阅合并安全信息注册
- 提示输入备用电话	请参阅 MFA 服务设置
- 提示输入第三方 OATH 令牌	请参阅 MFA 服务设置
允许用户启动一次性跳过	请参阅 Microsoft Entra ID TAP 功能
允许用户选择方法	请参阅 MFA 服务设置
- 电话呼叫	请参阅电话呼叫文档
- 短信	请参阅 MFA 服务设置
- 移动应用	请参阅 MFA 服务设置
- OATH 令牌	请参阅 OATH 令牌文档
允许用户选择语言	语言设置将根据用户浏览器中的区域设置自动应用于用户
允许用户激活移动应用	请参阅 MFA 服务设置
- 设备限制	Microsoft Entra ID 限制每个用户累计只能使用五个设备（移动应用实例 + 硬件 OATH 令牌 + 软件 OATH 令牌）
使用安全提问进行回退	Microsoft Entra ID 允许用户选择一个在进行身份验证时所选身份验证方法失败的情况下使用的应变方法
- 要回答的问题	Microsoft Entra ID 中的安全性问题只能用于 SSPR。 有关更多详细信息，请参阅 Microsoft Entra 自定义安全性问题
允许用户关联第三方 OATH 令牌	请参阅 OATH 令牌文档
使用 OATH 令牌进行回退	请参阅 OATH 令牌文档
会话超时
“安全问题”选项卡	MFA 服务器中的安全性问题用于获取用户门户的访问权限。 Microsoft Entra 多重身份验证仅支持自助密码重置的安全问题。 请参阅安全性问题文档。
“传递的会话”选项卡	所有身份验证方法注册流都由 Microsoft Entra ID 管理，不需要配置
受信任的 IP	Microsoft Entra ID 受信任的 IP

MFA 服务器中提供的任何 MFA 方法都必须通过使用 MFA 服务设置在 Microsoft Entra 多重身份验证中启用。 除非启用了新迁移的 MFA 方法，否则用户无法尝试这些方法。

身份验证服务

Azure MFA 服务器可以通过充当身份验证代理为使用 RADIUS 或 LDAP 的第三方解决方案提供 MFA 功能。 若要发现 RADIUS 或 LDAP 依赖项，请单击 MFA 服务器中的“RADIUS 身份验证”和“LDAP 身份验证”选项。 对于这些依赖项中的每一个，请确定这些第三方是否支持新式身份验证。 如果是这样，请考虑直接使用 Microsoft Entra ID 进行联合。

对于无法升级的 RADIUS 部署，需要部署 NPS 服务器并安装Microsoft Entra 多重身份验证 NPS 扩展。

对于无法升级或移动到 RADIUS 的 LDAP 部署，请确定是否可以使用 Microsoft Entra 域服务。 在大多数情况下，部署 LDAP 是为了支持最终用户的内联密码更改。 迁移后，最终用户可以使用 Microsoft Entra ID 中的自助式密码重置来管理他们的密码。

如果在除 Office 365 信赖方信任之外的任何信赖方信任上启用了AD FS 2.0 中的 MFA 服务器身份验证提供程序，需要升级到AD FS 3.0，或者，如果这些依赖方支持新式身份验证方法，则将它们直接与 Microsoft Entra ID 联合。 确定每个依赖项的最佳行动计划。

备份 Azure 多重身份验证服务器数据文件

在主 MFA 服务器上备份位于 %programfiles%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata（默认位置）中的 MFA 服务器数据文件。 请确保拥有当前安装版本的安装程序副本，以防需要回滚。 如果不再有副本，请联系客户支持服务。

根据用户活动，数据文件可能会很快过时。 对 MFA 服务器所做的任何更改，或备份后通过门户所做的任何最终用户更改均不会被捕获。 如果回滚，在此之后所做的任何更改都不会还原。

安装 MFA 服务器更新

在主 MFA 服务器上运行新的安装程序。 升级服务器时，请将其从与其他 MFA 服务器共享的任何负载均衡设置或流量中移除。 运行安装程序前，无需卸载当前的 MFA 服务器。 安装程序使用当前安装路径（例如，C:\Program Files\Multi-Factor Authentication Server）执行就地升级。 如果系统提示安装 Microsoft Visual C++ 2015 Redistributable 更新包，则接受提示。 将同时安装更新包的 x86 和 x64 版本。 无需为用户门户、Web SDK 或 AD FS 适配器安装更新。

注意

在主服务器上运行安装程序后，辅助服务器可能会开始记录未处理的 SB 条目。 这是因为主服务器上进行的架构更改不会由辅助服务器识别。 这些错误在意料之中。 在拥有 10,000 个或更多用户的环境中，日志条目的数量可能会显着增加。 若要缓解此问题，可以增加 MFA 服务器日志的文件大小，或升级辅助服务器。

配置 MFA 服务器迁移实用工具

安装 MFA 服务器更新后，打开一个提升的 PowerShell 命令提示符：将鼠标悬停在 PowerShell 图标上，右键单击，然后单击“以管理员身份运行”。 运行 MFA 服务器安装目录中的 .\Configure-MultiFactorAuthMigrationUtility.ps1 脚本（默认为 C:\Program Files\Multi-Factor Authentication Server）。

此脚本会要求你为 Microsoft Entra 租户中的应用程序管理员提供凭据。 然后，该脚本将在 Microsoft Entra ID 中创建一个新的 MFA 服务器迁移实用工具应用程序，该应用程序将用于将用户身份验证方法写入每个 Microsoft Entra 用户对象。

对于希望执行迁移的政府云客户，请将脚本中的“.com”条目替换为“.us”。 然后，此脚本将写入 HKLM:\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\ StsUrl 和 GraphUrl 注册表项，并指示迁移实用工具使用适当的 GRAPH 终结点。

你还需要访问以下 URL：

• https://graph.microsoft.com/*（或 https://graph.microsoft.us/* 用于政府云客户）
• https://login.microsoftonline.com/*（或 https://login.microsoftonline.us/* 用于政府云客户）

该脚本将指示你向新创建的应用程序授予管理员同意。 导航到提供的 URL，或在 Microsoft Entra 管理中心中单击“应用程序注册”，找到并选择“MFA 服务器迁移实用工具”应用，单击“API 权限”，然后授予相应的权限。

完成后，导航到多重身份验证服务器文件夹，并打开 MultiFactorAuthMigrationUtilityUI 应用程序。 应会看到以下屏幕：

你已成功安装迁移实用工具。

注意

为了确保迁移过程中行为不会发生变化，如果你的 MFA 服务器在未引用租户的情况下与 MFA 提供程序相关联，则你需要为要迁移的租户更新默认 MFA 设置（例如自定义问候语），以匹配 MFA 提供程序中的设置。 建议在迁移任何用户之前执行此操作。

运行辅助 MFA 服务器（可选）

如果实施 MFA 服务器时有大量用户或主 MFA 服务器繁忙，则可能需要考虑部署专用的辅助 MFA 服务器来运行 MFA 服务器迁移实用工具和迁移同步服务。 升级主 MFA 服务器后，请升级现有的辅助服务器或部署新的辅助服务器。 所选的辅助服务器不应处理其他 MFA 流量。

应在辅助服务器上运行 Configure-MultiFactorAuthMigrationUtility.ps1 脚本，以便使用 MFA 服务器迁移实用工具应用注册来注册证书。 证书用于对 Microsoft Graph 进行身份验证。 在辅助 MFA 服务器上运行迁移实用工具和同步服务会提高手动和自动用户迁移的性能。

迁移用户数据

迁移用户数据不会删除或更改多重身份验证服务器数据库中的任何数据。 同样，此过程不会更改用户执行 MFA 的位置。 此过程是将数据从本地服务器单向复制到 Microsoft Entra ID 中相应的用户对象。

MFA 服务器迁移实用工具面向所有迁移活动的单个 Microsoft Entra 组。 可以直接将用户添加到此组，或添加其他组。 还可以在迁移过程中分阶段添加它们。

若要开始迁移过程，请输入要迁移的 Microsoft Entra 组的名称或 GUID。 完成后，按 Tab 或在窗口外单击以开始搜索相应的组。 组中的所有用户都已填充。 大型组可能需要几分钟才能完成。

若要查看某个用户的属性数据，请突出显示该用户，然后选择“查看”：

此窗口显示 Microsoft Entra ID 和本地 MFA 服务器中选定用户的属性。 可以使用此窗口查看迁移后数据是如何写入用户的。

使用“设置”选项可以更改迁移过程的设置：

• 迁移 - 迁移用户的默认身份验证方法有三个选项：

  • 始终迁移
  • 仅迁移（如果尚未在 Microsoft Entra ID 中设置）
  • 如果在 Microsoft Entra ID 中尚未设置，则设置为最安全的可用方法

  迁移默认方法时，这些选项提供了灵活性。 此外，迁移期间会检查身份验证方法策略。 如果策略不允许迁移的默认方法，则会将其设置为最安全的可用方法。

• 用户匹配 - 允许指定其他本地 Active Directory 属性以匹配 Microsoft Entra UPN，而不是与 userPrincipalName 进行默认匹配：

  • 在使用本地 Active Directory 属性之前，迁移实用工具会尝试直接匹配 UPN。
  • 如果未找到匹配项，它将调用 Windows API 来查找 Microsoft Entra UPN 并获取 SID，该 SID 用于搜索 MFA 服务器用户列表。
  • 如果 Windows API 在 MFA 服务器中找不到用户或 SID，它将使用配置的 Active Directory 属性在本地 Active Directory 中查找用户，然后使用 SID 搜索 MFA 服务器用户列表。

• 自动同步 - 启动后台服务，该服务将持续监视本地 MFA 服务器中用户的任何身份验证方法更改，并按照定义的指定时间间隔将其写入 Microsoft Entra ID。

• 同步服务器 – 允许 MFA 服务器迁移同步服务在辅助 MFA 服务器上运行，而不是仅在主 MFA 服务器中运行。 若要将迁移同步服务配置为在辅助服务器上运行，必须在服务器上运行 Configure-MultiFactorAuthMigrationUtility.ps1 脚本，以便使用 MFA 服务器迁移实用工具应用注册来注册证书。 证书用于对 Microsoft Graph 进行身份验证。

迁移过程可以是自动的，也可以是手动的。

手动过程步骤包括：

1. 若要开始一个用户或多个用户的迁移过程，请按住 Ctrl 键，同时选择要迁移的每个用户。

2. 选择所需用户后，单击“迁移用户”>“所选用户”>“确定”。

3. 若要迁移组中的所有用户，请依次单击“迁移用户”>“Microsoft Entra 组中的所有用户”>“确定”。

4. 即使用户保持不变，也可以迁移用户。 默认情况下，实用工具设置为“仅迁移已更改的用户”。 单击“迁移所有用户”以重新迁移以前迁移的未更改用户。 如果管理员需要重置用户的 Azure MFA 设置并希望重新迁移这些设置，则在测试期间迁移未更改的用户可能很实用。

   

对于自动进程，请单击“设置”中的“自动同步”，然后选择是希望同步所有用户，还是仅同步给定 Microsoft Entra 组的成员。

下表列出了各种方法的同步逻辑。

方法	逻辑
电话	如果没有扩展，请更新 MFA 电话。 如果有扩展，请更新 Office 电话。 异常：如果默认方法是短信，请删除扩展并更新 MFA 电话。
备份电话号码	如果没有扩展，请更新备用电话。 如果有扩展，请更新 Office 电话。 异常：如果电话和备份电话都有扩展，请跳过备份电话。
移动应用	将最多迁移五台设备，如果用户还拥有硬件 OATH 令牌，则最多仅迁移四台设备。 如果有多个具有相同名称的设备，则仅迁移最新的设备。 设备将按最新到最旧排序。 如果 Microsoft Entra ID 中已存在设备，请匹配 OATH 令牌密钥并更新。 - 如果 OATH 令牌密钥不匹配，请在设备令牌上匹配 -- 如果找到，请为 MFA 服务器设备创建一个软件 OATH 令牌，以允许 OATH 令牌方法工作。 通知仍可使用现有 Microsoft Entra 多重身份验证设备。 -- 如果未找到，请创建新设备。 如果添加的新设备超过 5 个设备的限制，将跳过该设备。
OATH 令牌	如果 Microsoft Entra ID 中已存在设备，请匹配 OATH 令牌密钥并更新。 - 如果未找到，请添加新的硬件 OATH 令牌设备。 如果添加的新设备超过 5 个设备的限制，将跳过 OATH 令牌。

MFA 方法将根据迁移的内容进行更新，并将设置默认方法。 MFA 服务器将跟踪上次迁移时间戳，并且仅在用户的 MFA 设置更改或管理员在“设置”对话框中修改要迁移的内容时才会再次迁移用户。

在测试期间，建议先执行手动迁移，然后进行测试，以确保给定数量的用户按预期运行。 测试成功后，请为要迁移的 Microsoft Entra 组启用自动同步。 将用户添加到此组时，其信息将自动同步到 Microsoft Entra ID。 MFA 服务器迁移实用工具面向一个 Microsoft Entra 组，但是该组可以同时包含用户和嵌套用户组。

完成后，会显示一条确认消息通知你已完成的任务：

如确认消息中所述，迁移的数据可能需要几分钟时间才能显示在 Microsoft Entra ID 中的用户对象上。 用户可以通过导航到 aka.ms/mfasetup 来查看其迁移的方法。

提示

如果不需要查看 Microsoft Entra MFA 方法，则可以缩短显示组所需的时间。 单击“视图”>“Azure AD MFA 方法”，切换“AAD Default”、“AAD Phone”、“AAD Alternate”、“AAD Office”、“AAD Devices”、“AAD OATH Token”列的显示。 隐藏列时，会跳过某些 Microsoft Graph API 调用，这大幅缩短了用户加载时间。

查看迁移详细信息

可以使用审核日志或 Log Analytics 查看 MFA 服务器到 Azure MFA 用户迁移的详细信息。

使用审核日志

若要访问 Microsoft Entra 管理中心内的审核日志以查看 MFA 服务器到 Azure MFA 用户迁移的详细信息，请执行以下步骤：

1. 至少以身份验证管理员的身份登录到 Microsoft Entra 管理中心。

2. 浏览到“标识”>“监视和运行状况”>“审核日志”。 要筛选日志，请点击“添加筛选器”。

   

3. 选择“由（参与者）启动 ”，然后点击“应用”。

   

4. 键入“Azure MFA 管理”，然后点击“应用”。

   

5. 此筛选器仅显示 MFA 服务器迁移实用工具日志。 要查看用户迁移的详细信息，请点击某行，然后选择“ 修改的属性”选项卡。此选项卡显示对已注册 MFA 方法和电话号码的更改。

   

   下表列出了每个代码的身份验证方法。

   代码	方法
   0	语音移动设备
   2	语音办公室
   3	语音备用移动设备
   5	SMS
   6	Microsoft Authenticator 推送通知
   7	硬件或软件令牌 OTP

6. 如果迁移了任何用户设备，会有单独的日志条目。

   

使用 Log Analytics

还可以使用 Log Analytics 查询 MFA 服务器到 Azure MFA 用户迁移的详细信息。

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc

此屏幕截图显示了用户迁移的更改：

此屏幕截图显示了设备迁移的更改：

Log Analytics 还可用于汇总用户迁移活动。

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)

验证并测试

成功迁移用户数据后，可以在更改全局租户之前使用分阶段推出验证最终用户体验。 通过以下过程，可针对特定 Microsoft Entra 组进行 MFA 的分阶段推出。 分阶段推出指示 Microsoft Entra ID 通过对目标组中的用户使用 Microsoft Entra 多重身份验证来执行 MFA，而不是让他们在本地执行 MFA。 可以验证和测试 - 建议使用 Microsoft Entra 管理中心，但如果愿意，也可以使用 Microsoft Graph。

启用分阶段推出

1. 导航至以下 URL：启用分阶段推出功能 - Microsoft Azure。

2. 将“Azure 多重身份验证”更改为“打开”，然后单击“管理组”。

   

3. 单击“添加组”，添加包含要为其启用 Azure MFA 的用户的组。 所选组将出现在显示的列表中。

   注意

   使用下面的 Microsoft Graph 方法面向的任何组也将出现在此列表中。

   

使用 Microsoft Graph 启用分阶段推出

1. 创建 featureRolloutPolicy

   1. 导航到 aka.ms/ge 并使用你希望为分阶段推出设置的租户中的混合标识管理员帐户登录到 Graph 浏览器。

   2. 确保针对以下终结点选择 POST：https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies

   3. 请求正文应包含以下内容（将 MFA 推出策略更改为组织的名称和说明）：

      {
           "displayName": "MFA rollout policy",
           "description": "MFA rollout policy",
           "feature": "multiFactorAuthentication",
           "isEnabled": true,
           "isAppliedToOrganization": false
      }
      

      

   4. 使用相同的终结点执行 GET 并记下 ID 值（在下图中划掉）：

      

2. 面向包含要测试的用户的 Microsoft Entra 组

   1. 使用以下终结点创建 POST 请求（将 {ID of policy} 替换为你从步骤 1d 复制的 ID 值）：

      https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$ref

   2. 请求正文应包含以下内容（将 {ID of group} 替换为希望作为分阶段推出目标的组的对象 ID）：

      {
      "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}"
      }
      

   3. 对希望作为分阶段推出目标的任何其他组重复步骤 a 和 b。

   4. 可以通过对以下 URL 执行 GET 来查看当前的策略：

      https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesTo

      上述过程使用 featureRolloutPolicy 资源。 公共文档尚未使用新的 multifactorAuthentication 功能进行更新，但它包含有关如何与 API 交互的详细信息。

3. 确认最终用户 MFA 体验。 可以检查以下项：

   1. 用户是否在 aka.ms/mfasetup 中看到其方法？
   2. 用户是否收到电话呼叫/短信？
   3. 他们能否使用上述方法成功进行身份验证？
   4. 用户是否成功接收 Authenticator 通知？ 他们能否批准这些通知？ 身份验证是否成功？
   5. 用户能否使用硬件 OATH 令牌成功进行身份验证？

让用户了解更多内容

确保用户知道在迁移到 Azure MFA 时会发生什么，包括新的身份验证流。 你可能还希望指示用户在迁移完成后使用 Microsoft Entra ID 组合注册门户 (aka.ms/mfasetup) 来管理他们的身份验证方法，而不是使用用户门户。 在 Microsoft Entra ID 中对身份验证方法所做的任何更改都不会传播回本地环境。 在必须回滚到 MFA 服务器的情况下，用户在 Microsoft Entra ID 中所做的任何更改都不会在 MFA 服务器用户门户中可用。

如果使用依赖 Azure MFA 服务器进行身份验证的第三方解决方案（请参阅身份验证服务），会希望用户继续在用户门户中更改其 MFA 方法。 这些更改将自动同步到 Microsoft Entra ID。 迁移这些第三方解决方案后，可以将用户移动到 Microsoft Entra ID 合并注册页。

完成用户迁移

重复迁移用户数据和验证和测试部分中的迁移步骤，直到迁移所有用户数据。

迁移 MFA 服务器依赖项

使用在身份验证服务中收集的数据点，开始执行各种必要的迁移。 完成此操作后，请考虑让用户在合并注册门户中管理其身份验证方法，而不是在 MFA 服务器上的用户门户中。

更新域联合设置

完成用户迁移并将所有身份验证服务移出 MFA 服务器后，就可以更新域联合设置了。 更新后，Microsoft Entra 不再向本地联合服务器发送 MFA 请求。

若要将 Microsoft Entra ID 配置为忽略对本地联合服务器的 MFA 请求，请安装 Microsoft Graph PowerShell SDK 并将 federatedIdpMfaBehavior 设置为 rejectMfaByFederatedIdp，如以下示例所示。

请求

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

响应

注意：为了便于阅读，此处显示的响应对象可能会缩短。

HTTP/1.1 200 OK
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
   "issuerUri": "http://contoso.com/adfs/services/trust",
   "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
   "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
   "preferredAuthenticationProtocol": "wsFed",
   "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
   "signOutUri": "https://sts.contoso.com/adfs/ls",
   "promptLoginBehavior": "nativeSupport",
   "isSignedAuthenticationRequestRequired": true,
   "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

用户将不再重定向到 MFA 的本地联合服务器，无论他们是否是分阶段推出工具的目标。 请注意，这可能需要 24 小时才能生效。

注意

域联合设置的更新可能需要长达 24 小时才能生效。

可选：禁用 MFA 服务器用户门户

完成所有用户数据的迁移后，最终用户就可以开始使用 Microsoft Entra ID 合并注册页来管理 MFA 方法。 可通过几种方法阻止用户在 MFA 服务器中使用用户门户：

• 将 MFA 服务器用户门户 URL 重定向到 aka.ms/mfasetup
• 清除 MFA 服务器“用户门户”部分中的“设置”选项卡下的“允许用户登录”复选框，以完全阻止用户登录到门户。

解除 MFA 服务器的授权

不再需要 Azure MFA 服务器时，请遵循常规服务器弃用做法。 Microsoft Entra ID 中不需要采取特殊操作来指示 MFA 服务器停用。

回滚计划

如果升级出现问题，请按照以下步骤回滚：

1. 卸载 MFA 服务器 8.1。

2. 将 PhoneFactor.pfdata 替换为在升级之前进行的备份。

   注意

   自备份以来所做的任何更改都将丢失，但如果备份是在升级之前进行的，并且升级不成功，则损失应该是最小的。

3. 运行以前版本的安装程序（例如，8.0.x.x）。

4. 将 Microsoft Entra ID 配置为接受对本地联合服务器的 MFA 请求。 使用 Graph PowerShell 将 federatedIdpMfaBehavior 设置为 enforceMfaByFederatedIdp，如以下示例所示。

   请求

   PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
   Content-Type: application/json
   {
     "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
   }
   

   为提高可读性，已缩短以下响应对象。

   响应

   HTTP/1.1 200 OK
   Content-Type: application/json
   {
     "@odata.type": "#microsoft.graph.internalDomainFederation",
     "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
      "issuerUri": "http://contoso.com/adfs/services/trust",
      "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
      "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
      "preferredAuthenticationProtocol": "wsFed",
      "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
      "signOutUri": "https://sts.contoso.com/adfs/ls",
      "promptLoginBehavior": "nativeSupport",
      "isSignedAuthenticationRequestRequired": true,
      "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "signingCertificateUpdateStatus": {
           "certificateUpdateResult": "Success",
           "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
       },
      "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
   }
   

将“Azure MFA 的分阶段推出”设置为“关闭”。 用户将再次重定向到本地联合服务器以进行 MFA。

后续步骤

• 从 MFA 服务器迁移到 Microsoft Entra 多重身份验证的方法概述
• 使用分阶段推出迁移到云身份验证