MFA 服务器迁移
本主题介绍如何将 Microsoft Entra 用户的 MFA 设置从本地 Microsoft Entra 多重身份验证服务器迁移到 Microsoft Entra 多重身份验证。
解决方案概述
MFA 服务器迁移实用工具可帮助将存储在本地Microsoft Entra 多重身份验证服务器中的多重身份验证数据直接同步到 Microsoft Entra 多重身份验证。 将身份验证数据迁移到 Microsoft Entra ID 后，用户可以无缝执行基于云的 MFA，而无需再次注册或确认身份验证方法。 管理员可以使用 MFA 服务器迁移实用工具以单个用户或用户组为目标进行测试和控制推出，而无需进行任何租户范围的更改。
视频：如何使用 MFA 服务器迁移实用工具
查看我们的视频，大致了解 MFA 服务器迁移实用工具及其工作原理。
限制和要求
MFA 服务器迁移实用工具要求在主 MFA 服务器上安装 MFA 服务器解决方案的新版本。 该内部版本更新了 MFA 服务器数据文件，并包含新的 MFA 服务器迁移实用工具。 无需更新 WebSDK 或用户门户。 安装更新 不会 自动启动迁移。
注意
可以在辅助 MFA 服务器上执行 MFA 服务器迁移实用工具。 有关详细信息，请查看运行辅助 MFA 服务器（可选）。
MFA 服务器迁移实用工具将数据从数据库文件复制到 Microsoft Entra ID 中的用户对象。 在迁移期间，可以使用分阶段推出将用户作为 Microsoft Entra 多重身份验证的目标进行测试。 通过暂存迁移，无需对域联合设置进行任何更改即可进行测试。 迁移完成后，必须通过更改域联合设置来完成最终的迁移步骤。
运行 Windows Server 2016 或更高版本的 AD FS 需要在任何 AD FS 信赖方（不包括Microsoft Entra ID 和 Office 365）上提供 MFA 身份验证。
查看 AD FS 访问控制策略，并确保没有任何要求在本地执行 MFA 作为身份验证过程的一部分。
阶段性推出可以针对最多 500,000 名用户（10 个组，每个组最多包含 50,000 名用户）。
迁移指南
| 阶段 | 步骤 |
|---|---|
| 准备 | 识别Microsoft Entra 多重身份验证服务器依赖项 |
| 备份Microsoft Entra 多重身份验证服务器数据文件 | |
| 安装 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。 在第二阶段结束时，整个用户群应该在与 Microsoft Entra ID 联合的所有工作负荷中使用 Microsoft Entra 多重身份验证。
在前面的阶段，可以从“分阶段推出”文件夹中删除用户，使其脱离Microsoft Entra 多重身份验证的范围，并将它们路由回本地Microsoft Entra 多重身份验证服务器，用于源自 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 请求，无论组成员身份如何。
以下部分更详细地介绍了迁移步骤。
识别Microsoft Entra 多重身份验证服务器依赖项
我们努力确保迁移到云端的 Microsoft Entra 多因素身份验证解决方案，以保持和提升您的安全态势。 有三大类应该用于对依赖项进行分组：
为了帮助你进行迁移，我们已将广泛使用的 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 方法，否则用户无法尝试其新迁移的 MFA 方法。
身份验证服务
Microsoft Entra 多重身份验证服务器可以通过充当身份验证代理为使用 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 联合。 确定每个依赖项的最佳操作计划。
备份Microsoft Entra 多重身份验证服务器数据文件
在主 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 服务器安装目录（默认位置为 C:\Program Files\Multi-Factor Authentication Server）的\Configure-MultiFactorAuthMigrationUtility.ps1 脚本。
此脚本要求你在 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 中设置，则设置为最安全的可用方法
迁移默认方法时，这些选项提供灵活性。 此外，迁移期间会检查身份验证方法策略。 如果策略不允许迁移的默认方法，则会将其设置为最安全的可用方法。
用户匹配 – 允许你为匹配 Microsoft Entra UPN 指定不同的本地 Active Directory 属性，而不是与 userPrincipalName 的默认匹配：
- 在使用本地 Active Directory 属性之前，迁移实用工具会尝试直接匹配 UPN。
- 如果未找到匹配项，它将调用 Windows API 来查找 Microsoft Entra UPN 并获取用于搜索 MFA 服务器用户列表的 SID。
- 如果 Windows API 找不到用户或未在 MFA 服务器中找到 SID，则它使用配置的 Active Directory 属性查找本地 Active Directory 中的用户，然后使用 SID 搜索 MFA 服务器用户列表。
自动同步 – 启动一个后台服务，该服务会持续监视对本地 MFA 服务器中的用户的任何身份验证方法更改，并在定义的指定时间间隔将其写入Microsoft Entra ID。
同步服务器 – 允许 MFA 服务器迁移同步服务在辅助 MFA 服务器上运行，而不仅仅是在主服务器上运行。 若要将迁移同步服务（Migration Sync service）配置为在辅助服务器上运行，必须在该辅助服务器上运行
Configure-MultiFactorAuthMigrationUtility.ps1脚本，以便在 MFA 服务器迁移工具应用注册中注册证书。 证书用于对 Microsoft Graph 进行身份验证。
迁移过程可以是自动的，也可以是手动的。
手动过程步骤包括：
若要为用户或选择多个用户开始迁移过程，请在选择要迁移的每个用户时按住 Ctrl 键。
选择所需用户后，选择 迁移用户>所选用户>确定。
若要迁移组中的所有用户，请选择“迁移用户”>“Microsoft Entra 组中的所有用户”>“确定”。
即使未更改用户，也可以迁移他们。 默认情况下，实用工具设置为“仅迁移已更改的用户”。 选择“迁移所有用户 以重新迁移先前已迁移且未更改的用户。 如果管理员需要重置用户的Microsoft Entra 多重身份验证设置并且想要重新迁移这些设置，则迁移未更改的用户在测试过程中非常有用。
对于自动过程，请在 设置中选择 自动同步，然后选择是希望所有用户同步，还是仅选择给定Microsoft Entra 组的成员。
下表列出了各种方法的同步逻辑。
| 方法 | 逻辑 |
|---|---|
| 电话 | 如果没有分机，请更新 MFA 电话。 如果有分机，请更新办公室电话。 异常：如果默认方法是短信，请删除扩展并更新 MFA 电话。 |
| 备份电话 | 如果没有分机，请更新备用电话。 如果有分机，请更新办公室电话。 特殊情况：如果电话和备份电话都有分机号，请跳过备份电话。 |
| 移动应用 | 如果用户还具有硬件 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 默认”、“AAD 电话”、“AAD 备用”、“AAD 办公室”、“AAD 设备”和“AAD OATH 令牌”列的显示。 隐藏列时，将跳过一些Microsoft图形 API 调用，这大大提高了用户加载时间。
查看迁移详细信息
可以使用审核日志或日志分析查看有关从 MFA 服务器到 Microsoft Entra 多重身份验证用户迁移的详细信息。
使用审核日志
若要访问 Microsoft Entra 管理中心中的审核日志，以查看 MFA 服务器迁移到 Microsoft Entra 多重身份验证用户的详细信息，请执行以下步骤：
请以至少是 身份验证管理员的身份登录到 Microsoft Entra 管理中心。
浏览到“标识”>“监视和运行状况”>“审核日志”。 若要筛选日志，请选择 添加筛选器。
选择“启动者(行动者)”，然后选择“应用”。
键入“Microsoft Entra 多重身份验证管理”并选择“应用”。
此筛选器仅显示 MFA 服务器迁移实用工具日志。 若要查看用户迁移的详细信息，请选择一行，然后选择 修改的属性 选项卡。此选项卡显示对已注册的 MFA 方法和电话号码的更改。
下表列出了每个代码的身份验证方法。
代码 方法 0 语音移动 2 语音办公室 3 语音备用移动 5 短信 6 Microsoft Authenticator 推送通知 7 硬件或软件令牌 OTP 如果迁移了任何用户设备，则存在单独的日志条目。
使用日志分析
还可以使用 Log Analytics 查询 MFA 服务器到 Microsoft Entra 多重身份验证用户迁移的详细信息。
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Microsoft Entra multifactor authentication 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 == "Microsoft Entra multifactor authentication 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。
启用分阶段推出
导航至以下 URL：启用分阶段推出功能 - Microsoft Azure。
将“Azure 多重身份验证”更改为“打开”，然后选择“管理组”。
选择“添加组”，然后添加包含要为其启用 Microsoft Entra 多重身份验证的用户的组。 所选组显示在列表中。
注意
使用以下 Microsoft Graph 方法定位的任何组也将显示在此列表中。
使用 Microsoft Graph 启用分阶段推出
创建 featureRolloutPolicy
导航到 aka.ms/ge 并使用你希望为分阶段推出设置的租户中的混合标识管理员帐户登录到 Graph 浏览器。
确保针对以下终结点选择 POST：
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies请求正文应包含以下内容（将“MFA 推出策略”更改为组织的名称和说明）：
{ "displayName": "MFA rollout policy", "description": "MFA rollout policy", "feature": "multiFactorAuthentication", "isEnabled": true, "isAppliedToOrganization": false }
使用相同的终结点执行 GET 并记下 ID 值（在下图中划掉）：
以包含要测试的用户的 Microsoft Entra 组为目标
使用以下终结点创建 POST 请求（将 {ID of policy} 替换为你从步骤 1d 复制的 ID 值）：
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$ref请求正文应包含以下内容（将 {ID of group} 替换为希望作为分阶段推出目标的组的对象 ID）：
{ "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}" }对希望作为分阶段推出目标的任何其他组重复步骤 a 和 b。
可以通过针对以下 URL 执行 GET 来查看当前策略：
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesTo上述过程使用 featureRolloutPolicy 资源。 公共文档尚未使用新的多重身份验证功能进行更新，但提供了有关如何与 API 交互的详细信息。
确认最终用户 MFA 体验。 以下是要检查的一些事项：
- 用户是否在 aka.ms/mfasetup 中看到其方法？
- 用户是否接收电话/短信？
- 他们能否使用上述方法成功进行身份验证？
- 用户是否成功接收 Authenticator 通知？ 他们能否批准这些通知？ 身份验证是否成功？
- 用户能否使用硬件 OATH 令牌成功进行身份验证？
培训用户
确保用户了解在切换到 Microsoft Entra 多重身份验证（并包括新的身份验证流）时会发生什么。 你可能还希望指示用户使用 Microsoft Entra ID 合并注册门户（aka.ms/mfasetup）来管理其身份验证方法，而不是在迁移完成后使用用户门户。 对 Microsoft Entra ID 中身份验证方法所做的任何更改都不会传播回本地环境。 在必须恢复到 MFA 服务器的情况下，用户在 Microsoft Entra ID 中所做的任何更改都不会出现在 MFA 服务器用户门户中。
如果使用依赖于Microsoft Entra 多重身份验证服务器进行身份验证的第三方解决方案（请参阅 身份验证服务），则需要用户在用户门户中继续更改其 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 服务器
如果不再需要 Microsoft Entra 多重身份验证服务器，请遵循正常的服务器弃用做法。 Microsoft Entra ID 中不需要采取特殊操作来指示 MFA 服务器停用。
回滚计划
如果升级出现问题，请按照以下步骤回滚：
卸载 MFA 服务器 8.1。
将 PhoneFactor.pfdata 替换为在升级之前进行的备份。
注意
自备份以来所做的任何更改都将丢失，但如果是在升级之前立即进行备份且升级失败的话，这些更改应该会很少。
为以前的版本运行安装程序（例如 8.0.x.x）。
配置 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" }
将“Microsoft Entra 多重身份验证的分阶段推出”设置为“关闭”。 用户会再次重定向到本地联合服务器以进行 MFA。