从联合身份验证迁移到云身份验证
本文介绍如何使用 Microsoft Entra 密码哈希同步 (PHS) 或直通身份验证 (PTA) 部署云用户身份验证。 虽然我们展示的是从 Active Directory 联合身份验证服务 (AD FS) 迁移到云身份验证方法的用例，但本指南也同样适用于其他本地系统。
在继续操作之前，建议你查看有关如何选择正确的身份验证方法的指南，并比较最适合组织的方法。
建议使用 PHS 部署云身份验证。
分阶段推出
分阶段推出是一种不错的形式，可以在切换域之前，有选择性地让几组用户测试 Microsoft Entra 多重身份验证、条件访问、用于防范凭据泄漏的标识保护、标识监管等云身份验证功能。
请参阅分阶段推出实施计划，了解支持和不支持的方案。 建议在切换域之前使用分阶段推出进行测试。
迁移流程
先决条件
在开始迁移之前，请确保满足以下先决条件。
必需的角色
若要使用分阶段推出，你必须是租户的混合标识管理员。
设置 Microsoft Entra Connect 服务器
安装 Microsoft Entra Connect (Microsoft Entra Connect) 或升级到最新版本。 升级 Microsoft Entra Connect 服务器后，它会将从 AD FS 迁移到云身份验证方法的时间从可能的几小时缩短到几分钟。
阐述当前联合身份验证设置
若要查找当前的联合身份验证设置，请运行 Get-MgDomainFederationConfiguration。
Get-MgDomainFederationConfiguration - DomainID yourdomain.com
验证可能已根据联合身份验证设计和部署文档自定义的任何设置。 具体而言，就是要查找 PreferredAuthenticationProtocol、federatedIdpMfaBehavior、SupportsMfa（如果未设置 federatedIdpMfaBehavior）和 PromptLoginBehavior 中的自定义项。
备份联合身份验证设置
尽管此部署不会更改 AD FS 场中的其他信赖方，但你可以对设置进行备份：
使用 Microsoft AD FS 快速还原工具还原现有场，或创建新场。
使用以下 PowerShell 示例导出 Microsoft 365 标识平台信赖方信任以及所添加的任何关联的自定义声明规则：
(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-RelyingPartyTrust.xml"
计划项目
如果技术项目失败，通常是由于在影响、结果和责任方面不符合预期而导致的。 若要避免这些问题，请确保吸引适当的利益干系人并充分了解项目中的利益干系人角色。
规划沟通
迁移到云身份验证后，访问通过 Microsoft Entra 进行身份验证的 Microsoft 365 和其他资源时，用户登录体验会发生变化。 网络外部的用户只会看到 Microsoft Entra 登录页面。
主动与用户交流，告知他们的体验将如何更改、何时会更改以及在遇到问题时如何获取支持。
规划维护时段
新式身份验证客户端（Office 2016 和 Office 2013、iOS 及 Android 应用）使用有效的刷新令牌获取新的访问令牌以持续访问资源，而无需返回到 AD FS。 在完成域转换过程后，有无密码提示对这些客户端而言并不重要。 无需进行额外的配置，这些客户端就能持续正常运行。
注意
从联合身份验证迁移到云身份验证时，将域从“联合”转换为“托管”的过程可能需要 60 分钟时间。 在此过程中，可能不会提示用户提供新登录到 Microsoft Entra 管理中心或登录到受 Microsoft Entra ID 保护且基于浏览器的其他应用程序所需的凭据。 建议将此延迟包含在维护时段中。
规划回滚
提示
如果需要回滚，请考虑在非工作时间规划域切换。
若要规划回滚，请使用已记录的当前联合身份验证设置并查看联合身份验证设计和部署文档。
回滚过程应包括使用 New-MgDomainFederationConfiguration cmdlet 将托管域转换为联合域。 必要时还会配置额外的声明规则。
迁移注意事项
下面是重要的迁移注意事项。
规划自定义设置
Microsoft Entra ID 不能出现重复的 onload.js 文件。 如果 AD FS 实例进行了大量自定义，并且依赖于 onload.js 文件中的特定自定义设置，请验证 Microsoft Entra ID 是否能够满足当前的自定义要求并相应地进行规划。 将这些即将推出的更改告知用户。
登录体验
无法自定义 Microsoft Entra 登录体验。 无论用户之前如何登录，你都需要一个完全限定的域名（例如用户主体名称 (UPN) 或电子邮件）来登录 Microsoft Entra ID。
组织品牌打造
可以自定义 Microsoft Entra 登录页面。 转换后，AD FS 在登录页面上会发生一些视觉变化。
注意
免费 Microsoft Entra ID 许可证不提供组织品牌打造，除非你拥有 Microsoft 365 许可证。
规划条件访问策略
评估当前是否正在使用条件访问进行身份验证，或者是否在 AD FS 中使用访问控制策略。
考虑将 AD FS 访问控制策略替换为等效的 Microsoft Entra 条件访问策略和 Exchange Online 客户端访问规则。 可以使用 Microsoft Entra ID 或本地组进行条件访问。
禁用旧式身份验证 - 由于与旧式身份验证协议相关的风险不断增加，需创建条件访问策略来阻止旧式身份验证。
规划对 MFA 的支持
对于联合域，可以通过 Microsoft Entra 条件访问或本地联合身份验证提供程序强制执行 MFA。 可以启用保护功能，防止绕过 Microsoft Entra 多重身份验证，方法是配置安全设置 federatedIdpMfaBehavior。 为 Microsoft Entra 租户中的联合域启用保护。 确保在经过联合身份验证的用户访问受需要 MFA 的条件访问策略管理的应用程序时，始终执行 Microsoft Entra 多重身份验证。 这包括执行 Microsoft Entra 多重身份验证，即使联合标识提供者已颁发联合令牌声明，表示本地 MFA 已执行。 每次强制执行 Microsoft Entra 多重身份验证可确保恶意攻击者无法通过模仿标识提供者已执行 MFA 来绕过 Microsoft Entra 多重身份验证，除非你使用第三方 MFA 提供程序对联合用户执行 MFA，否则强烈建议每次强制执行。
下表说明了每个选项的行为。 有关详细信息，请参阅 federatedIdpMfaBehavior。
| 值 | 说明 |
|---|---|
| acceptIfMfaDoneByFederatedIdp | Microsoft Entra ID 接受联合标识提供者执行的 MFA。 如果联合标识提供者未执行 MFA，则 Microsoft Entra ID 将执行 MFA。 |
| enforceMfaByFederatedIdp | Microsoft Entra ID 接受联合标识提供者执行的 MFA。 如果联合标识提供者未执行 MFA，它会将请求重定向到联合标识提供者以执行 MFA。 |
| rejectMfaByFederatedIdp | Microsoft Entra ID 始终执行 MFA 并拒绝联合标识提供者执行的 MFA。 |
federatedIdpMfaBehavior 设置是 Set-MsolDomainFederationSettings MSOnline v1 PowerShell cmdlet 的 SupportsMfa 属性的演变版本。
对于已设置 SupportsMfa 属性的域，这些规则决定 federatedIdpMfaBehavior 和 SupportsMfa 如何协同工作：
- 不支持在 federatedIdpMfaBehavior 和 SupportsMfa 之间进行切换。
- 设置 federatedIdpMfaBehavior 属性后，Microsoft Entra ID 将忽略 SupportsMfa 设置。
- 如果未设置 federatedIdpMfaBehavior 属性，则 Microsoft Entra ID 继续遵循 SupportsMfa 设置。
- 如果没有设置 federatedIdpMfaBehavior，也没有设置 SupportsMfa，Microsoft Entra ID 会默认执行
acceptIfMfaDoneByFederatedIdp行为。
可以通过运行 Get-MgDomainFederationConfiguration 来检查保护状态：
Get-MgDomainFederationConfiguration -DomainId yourdomain.com
规划实施
本部分介绍切换登录方法和转换域之前的准备工作。
为分阶段推出创建必要的组
如果你不使用分阶段推出，请跳过此步骤。
创建用于分阶段推出和条件访问策略（如果决定添加）的组。
建议使用在 Microsoft Entra ID 中管理的组，也称为仅限云的组。 对于将用户移到 MFA，以及对于条件访问策略，你都可以使用 Microsoft Entra 安全组或 Microsoft 365 组。 有关详细信息，请参阅创建 Microsoft Entra 安全组和 Microsoft 365 管理员组概述。
将自动为组中成员启用分阶段推出。 分阶段推出不支持嵌套和动态组。
SSO 的准备工作
你使用的 SSO 版本取决于你的设备 OS 和加入状态。
对于 Windows 10、Windows Server 2016 及更高版本，建议在加入 Microsoft Entra 的设备、加入混合 Microsoft Entra 联接的设备和 Microsoft Entra 注册设备上通过主刷新令牌 (PRT) 使用 SSO。
对于 macOS 和 iOS 设备，我们建议通过适用于 Apple 设备的 Microsoft 企业 SSO 插件使用 SSO。 此功能要求你的 Apple 设备由 MDM 管理。 如果你使用 Intune 作为 MDM，请按照适用于 Apple Intune 的 Microsoft 企业 SSO 插件部署指南进行操作。 如果你使用其他 MDM，请按照 Jamf Pro/通用 MDM 部署指南进行操作。
对于 Windows 7 和 8.1 设备，建议将无缝 SSO 与域加入结合使用，以在 Microsoft Entra ID 中注册计算机。 无需像在 Windows 10 设备上一样同步这些帐户。 但是，你必须完成使用 PowerShell 进行无缝 SSO 的准备工作。
PHS 和 PTA 的准备工作
根据所选登录方法，完成 PHS 的准备工作或 PTA 的准备工作。
实施解决方案
最后，按计划将登录方法切换为 PHS 或 PTA，并将域从联合身份验证转换为云身份验证。
使用分阶段推出
如果使用分阶段推出，请按照以下链接中的步骤操作：
测试完成后，将域从联合域转换为托管域。
不使用分阶段推出
可通过以下两个选项实现此更改：
选项 A：使用 Microsoft Entra Connect 进行切换。
如果最初使用 Microsoft Entra Connect 配置了 AD FS/ping-federated 环境，则可以选择此选项。
选项 B：使用 Microsoft Entra Connect 和 PowerShell 进行切换
如果最初未使用 Microsoft Entra Connect 配置联合域或使用的是第三方联合身份验证服务，则可以选择此选项。
若要选择上述选项之一，你必须知道当前的设置是什么。
验证当前 Microsoft Entra Connect 设置
- 至少以混合管理员的身份登录到 Microsoft Entra 管理中心。
- 浏览到“标识”>“混合管理”>“Microsoft Entra Connet”>“云同步”。
- 验证 USER SIGN_IN 设置，如下图所示：
若要验证联合身份验证的配置方式，请执行以下操作：
在 Microsoft Entra Connect 服务器上，打开 Microsoft Entra Connect，然后选择“配置”。
在“其他任务”>“管理联合身份验证”下，选择“查看联合身份验证配置”。
如果此部分显示了 AD FS 配置，则可以肯定 AD FS 最初是使用 Microsoft Entra Connect 配置的。 请参阅下图作为示例：
如果当前设置中未列出 AD FS，则必须使用 PowerShell 手动将域从联合标识转换为托管标识。
选项 A
使用 Microsoft Entra Connect 从联合身份验证切换到新的登录方法
在 Microsoft Entra Connect 服务器上，打开 Microsoft Entra Connect，然后选择“配置”。
在“其他任务”页面下，选择“更改用户登录”，然后选择“下一步”。
在“连接到 Microsoft Entra”页面上，输入全局管理员帐户凭据。
在“用户登录”页面上：
如果选择“直通身份验证”选项按钮，并且 Windows 7 和 8.1 设备需要 SSO，请检查启用单一登录，然后选择“下一步”。
如果选择“密码哈希同步”选项按钮，请确保选中“不转换用户帐户”复选框。 该选项已过时。 如果 Windows 7 和 8.1 设备需要 SSO，请检查启用单一登录，然后选择“下一步”。
了解详细信息：使用 PowerShell 启用无缝 SSO。
在“启用单一登录”页上输入域管理员帐户的凭据，然后选择“下一步”。
需要使用域管理员帐户凭据来启用无缝 SSO。 该过程将完成以下操作，而这些操作需要这些提升的权限：
- 在本地 Active Directory 实例中创建名为 AZUREADSSO 的计算机帐户（表示 Microsoft Entra ID）。
- 计算机帐户的 Kerberos 解密密钥与 Microsoft Entra ID 安全共享。
- 创建两个 Kerberos 服务主体名称 (SPN) 来表示 Microsoft Entra 登录期间使用的两个 URL。
域管理员凭据不会存储在 Microsoft Entra Connect 或 Microsoft Entra ID 中，并且在该过程成功完成后会被丢弃。 它们用于启用此功能。
了解详细信息：无缝 SSO 技术探讨。
在“已准备好进行配置”页上，确保已选中“配置完成后启动同步过程”复选框。 然后选择“配置”。
重要
此时，所有联合域会更改为托管身份验证。 你选择的用户登录方法即为新的身份验证方法。
在 Microsoft Entra 管理中心，选择“Microsoft Entra ID”，然后选择“Microsoft Entra Connect”。
验证以下设置：
- “联合身份验证”设置为“已禁用”。
- “无缝单一登录”设置为“已启用”。
- “密码哈希同步”设置为“已启用”。
若要切换到 PTA，请执行后续步骤。
为 PTA 部署更多身份验证代理
注意
PTA 要求在 Microsoft Entra Connect 服务器和运行 Windows Server 的本地计算机上部署轻型代理。 为减少延迟，请将代理安装在尽量靠近 Active Directory 域控制器的位置。
对于大多数客户而言，两个或三个身份验证代理足以提供高可用性和所需的容量。 为一个租户注册的代理不能超过 12 个。 第一个代理始终安装在 Microsoft Entra Connect 服务器本身上。 要了解代理的限制和代理部署选项，请参阅 Microsoft Entra 直通身份验证：当前限制。
选择“直通身份验证”。
在“直通身份验证”页上选择“下载”按钮。
在“下载代理”页上选择“接受条款并下载”。
随后将开始下载更多身份验证代理。 在已加入域的服务器上安装辅助身份验证代理。
运行身份验证代理安装。 在安装过程中，必须输入全局管理员帐户的凭据。
安装身份验证代理后，可以返回到 PTA 运行状况页面查看更多代理的状态。
选项 B
使用 Microsoft Entra Connect 和 PowerShell 从联合身份验证切换到新的登录方法
如果最初未使用 Microsoft Entra Connect 配置联合域或使用的是第三方联合身份验证服务，则可以选择此选项。
在 Microsoft Entra Connect 服务器上，按照选项 A 中的步骤 1-5 进行操作。请注意，在“用户登录”页面上，“不配置”选项是预先选中的。
在 Microsoft Entra 管理中心，选择“Microsoft Entra ID”，然后选择“Microsoft Entra Connect”。
验证以下设置：
“联合身份验证”设置为“已启用”。
“无缝单一登录”设置为“已禁用”。
“密码哈希同步”设置为“已启用”。
如果仅使用 PTA，请按照以下步骤安装更多 PTA 代理服务器。
在 Microsoft Entra 管理中心，选择“Microsoft Entra ID”，然后选择“Microsoft Entra Connect”。
选择“直通身份验证”。 验证状态是否为“活动”。
如果身份验证代理不处于活动状态，请先完成这些故障排除步骤，然后继续在下一步骤进行域转换过程。 在验证 PTA 代理是否已成功安装并且其在 Microsoft Entra管理中心的状态显示为“活动”之前，如果转换域，可能存在身份验证中断的风险。
将联合域转换为托管域
此时，联合身份验证仍为活动状态，并可以对域正常运行。 若要继续部署，必须将每个域从联合标识转换为托管标识。
重要
无需同时转换所有域。 可以选择从生产租户中的某个测试域着手，或者从用户数量最少的域着手。
使用 Microsoft Graph PowerShell SDK 完成转换：
在 PowerShell 中，使用全局管理员帐户登录到 Microsoft Entra ID。
Connect-MGGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"若要转换第一个域，请运行以下命令：
Update-MgDomain -DomainId <domain name> -AuthenticationType "Managed"在 Microsoft Entra 管理中心，依次选择“Microsoft Entra ID”>“Microsoft Entra Connect”。
验证是否已通过运行以下命令将该域转换为托管域。 应将“身份验证类型”设置为“托管”。
Get-MgDomain -DomainId yourdomain.com
完成迁移
完成以下任务，以验证注册方法并完成转换过程。
测试新的登录方法
以前，当租户使用联合标识时，用户会从 Microsoft Entra 登录页面重定向到你的 AD FS 环境。 现在，将租户配置为使用新的登录方法而不是联合身份验证之后，用户不会重定向到 AD FS。
而是直接通过 Microsoft Entra 登录页登录。
按照此链接中的步骤操作 - 使用 PHS/PTA 和无缝 SSO 验证登录（如果需要）
从分阶段推出中删除用户
如果使用了分阶段推出，应记得在完成切换后关闭分阶段推出功能。
若要禁用分阶段推出功能，请将控件滑回“关”。
同步 UserPrincipalName 更新
在过去，除非以下两个条件都成立，否则会阻止在本地环境中使用同步服务对 UserPrincipalName 属性进行更新：
- 用户在托管的（非联合）标识域中。
- 没有为用户分配许可证。
若要了解如何验证或启用此功能，请参阅同步 userPrincipalName 更新。
管理实施
滚动更新无缝 SSO 的 Kerberos 解密密钥
建议每隔 30 天至少滚动更新 Kerberos 解密密钥一次，以便与 Active Directory 域成员提交密码更改的频率保持一致。 没有任何关联的设备附加到 AZUREADSSO 计算机帐户对象，因此必须手动执行滚动更新。
请参阅 FAQ 如何滚动更新 AZUREADSSO 计算机帐户的 Kerberos 解密密钥？
监视和日志记录
监视运行身份验证代理的服务器，以保持解决方案的可用性。 除了常规服务器性能计数器以外，身份验证代理还会公开有助于了解身份验证统计信息和错误的性能对象。
身份验证代理将操作记录到应用程序和服务日志下的 Windows 事件日志中。 还可以出于故障排除目的启用日志记录。
若要确认对分阶段推出执行的各种操作，可以审核 PHS、PTA 或无缝 SSO 的事件。
疑难解答
支持团队应了解如何排查在从联合身份验证更改为托管身份验证期间或之后出现的任何身份验证问题。 使用以下故障排除文档可帮助支持团队熟悉常见的故障排除步骤，以及可帮助找出和解决问题的相应操作。
解除 AD FS 基础结构授权
将应用身份验证从 AD FS 迁移到 Microsoft Entra ID
迁移需要评估应用程序在本地的配置方式，然后将该配置映射到 Microsoft Entra ID。
如果你打算继续将 AD FS 与使用 SAML/WS-FED 或 Oauth 协议的本地和 SaaS 应用程序结合使用，则在转换域后，你将同时使用 AD FS 和 Microsoft Entra ID 进行用户身份验证。 在这种情况下，你可以通过 Microsoft Entra 应用程序代理或 Microsoft Entra ID 合作伙伴集成之一，使用安全混合访问 (SHA) 来保护本地应用程序和资源。 使用应用程序代理或者我们的合作伙伴之一，可以提供对本地应用程序的安全远程访问。 用户获得的好处是：可以在单一登录后轻松地从任何设备连接到他们的应用程序。
可以将当前与 ADFS 联合的 SaaS 应用程序移动到 Microsoft Entra ID。 可通过 Azure 应用库中的内置连接器或通过在 Microsoft Entra ID 中注册应用程序，重新配置为向 Microsoft Entra ID 进行身份验证。
有关更多信息，请参阅将应用程序身份验证从 Active Directory 联合身份验证服务移动到 Microsoft Entra ID。
删除信赖方信任
如果有 Microsoft Entra Connect Health，可以从 Microsoft Entra 管理中心监视使用情况。 如果使用情况显示没有新的身份验证请求，并且你确认所有用户和客户端都已通过 Microsoft Entra ID 成功完成身份验证，则可以安全删除 Microsoft 365 信赖方信任。
如果未将 AD FS 用于其他目的（即，其他信赖方信任），则现在可以解除 AD FS 授权。
删除 AD FS
若要获取从环境中完全删除 AD FS 需执行的步骤的完整列表，请按照 Active Directory 联合身份验证服务 (AD FS) 停用指南进行操作。