本文介绍如何使用 Microsoft Entra 密码哈希同步（PHS） 或 直通身份验证（PTA）部署云用户身份验证。 虽然我们演示了从 Active Directory 联合身份验证服务（AD FS） 迁移到云身份验证方法的用例，但指南也适用于其他本地系统。
在继续之前，建议查看有关 选择正确身份验证方法 的指南，并比较最适合组织的方法。
我们建议使用 PHS 进行云身份验证。
分阶段推出
分阶段推出是一种不错的形式，可以在切换域之前，有选择性地让几组用户测试 Microsoft Entra 多重身份验证、条件访问、用于防范凭据泄漏的 Microsoft Entra ID 保护、标识监管等云身份验证功能。
请参阅分阶段推出实施计划，了解 受支持 和 不支持的方案。 建议在切换域之前使用分阶段推出进行测试。
迁移流程
先决条件
在开始迁移之前，请确保满足以下先决条件。
必需的角色
若要使用分阶段推出，你需要是租户的混合标识管理员。
设置 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。 可以通过配置安全设置 federatedIdpMfaBehavior 来启用保护以防止绕过 Microsoft Entra 多重身份验证。 在您的 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 设置是 SupportsMfa 属性的更新版本，源自 Set-MsolDomainFederationSettings MSOnline v1 PowerShell cmdlet。
对于已设置 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 及更高版本，我们建议将 SSO 通过 主刷新令牌（PRT） 用于 已加入 Microsoft Entra 的设备、 Microsoft Entra 混合联接设备和Microsoft Entra 已注册的设备。
对于 macOS 和 iOS 设备，我们建议通过 适用于 Apple 设备的 Microsoft Enterprise SSO 插件使用 SSO。 此功能要求你的 Apple 设备由 MDM 管理。 如果使用 Intune 作为 MDM，请遵循 适用于 Apple Intune 的 Microsoft Enterprise SSO 插件部署指南。 如果使用其他 MDM，请按照 Jamf Pro/通用 MDM 部署指南进行操作。
对于 Windows 7 和 8.1 设备，我们建议将 无缝 SSO 与已加入域的 SSO 配合使用，在 Microsoft Entra ID 中注册计算机。 无需像在 Windows 10 设备上一样同步这些帐户。 但是，必须使用 PowerShell 完成此准备工作，以实现无缝 SSO。
PHS 和 PTA 的准备工作
根据登录方法的选择，完成 PHS 的准备工作 或 PTA 的准备工作。
实施解决方案
最后，按计划将登录方法切换为 PHS 或 PTA，并将域从联合身份验证转换为云身份验证。
使用分阶段推出
如果使用分阶段推出，请按照以下链接中的步骤操作：
在您的租户上启用特定功能的分阶段推出。
测试完成后， 将域从联合转换为托管。
不使用分阶段推出
可通过以下两个选项实现此更改：
选项 A： 使用 Microsoft Entra Connect 进行切换。
如果最初使用 Microsoft Entra Connect 配置了 AD FS/ ping 联合环境，则可以选择此选项。
选项 B： 使用 Microsoft Entra Connect 和 PowerShell 进行切换
如果最初未使用 Microsoft Entra Connect 配置联合域或使用的是第三方联合身份验证服务，则可以选择此选项。
若要选择上述选项之一，你必须知道当前的设置是什么。
验证当前 Microsoft Entra Connect 设置
以至少混合标识管理员身份登录到 Microsoft Entra 管理中心。
浏览到 Entra ID>Entra Connect>云同步。
- 验证 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 直通身份验证：当前限制。
选择“直通身份验证”。
在“直通身份验证”页上选择“下载”按钮。
在 “下载代理 ”页上，选择“ 接受条款”并下载.f
随后将开始下载更多身份验证代理。 在已加入域的服务器上安装辅助身份验证代理。
运行身份验证代理安装。 在安装过程中，必须输入全局管理员帐户的凭据。
安装身份验证代理后，可以返回到 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 Connect 在将域转换为托管身份验证之后能够识别直通身份验证为已启用，请更新 Microsoft Entra Connect 中的登录方法设置以反映这些更改。 有关更多详细信息 ，请参阅Microsoft Entra 直通身份验证文档 。
完成迁移
完成以下任务，以验证注册方法并完成转换过程。
测试新的登录方法
以前，当租户使用联合标识时，用户会从 Microsoft Entra 登录页面重定向到你的 AD FS 环境。 现在，将租户配置为使用新的登录方法而不是联合身份验证之后，用户不会重定向到 AD FS。
相反，用户直接在 Microsoft Entra 登录页上登录。
请按照此链接中的步骤 - 使用 PHS/PTA 和无缝 SSO 完成登录（如有需要）
从分阶段推出中删除用户
如果使用了分阶段推出，应记得在完成切换后关闭分阶段推出功能。
若要禁用分阶段推出功能，请将控件滑回“关”。
同步 UserPrincipalName 更新
在过去，除非以下两个条件都成立，否则会阻止在本地环境中使用同步服务对 UserPrincipalName 属性进行更新：
- 用户在托管的（非联合）标识域中。
- 没有为用户分配许可证。
若要了解如何验证或启用此功能，请参阅 Sync userPrincipalName 更新。
管理实施
滚动更新无缝 SSO 的 Kerberos 解密密钥
建议每隔 30 天至少滚动更新 Kerberos 解密密钥一次，以便与 Active Directory 域成员提交密码更改的频率保持一致。 没有任何关联的设备附加到 AZUREADSSO 计算机帐户对象，因此必须手动执行滚动更新。
请参阅常见问题解答 如何轮换 AZUREADSSO 计算机帐户的 Kerberos 解密密钥？。
监视和日志记录
监视运行身份验证代理的服务器，以保持解决方案的可用性。 除了常规服务器性能计数器以外，身份验证代理还会公开有助于了解身份验证统计信息和错误的性能对象。
身份验证代理将操作记录到应用程序和服务日志下的 Windows 事件日志中。 还可以出于故障排除目的启用日志记录。
若要确认在分阶段部署时执行的各种动作，可以 审核 PHS、PTA 或无缝 SSO 的事件。
疑难解答
您的支持团队应了解如何解决和排查在从联合身份验证更改为托管式身份验证期间及之后出现的任何身份验证问题。 使用以下故障排除文档可帮助支持团队熟悉常见的故障排除步骤，以及可帮助找出和解决问题的相应操作。
解除 AD FS 基础结构授权
将应用身份验证从 AD FS 迁移到 Microsoft Entra ID
迁移需要评估应用程序在本地的配置方式，然后将该配置映射到 Microsoft Entra ID。
如果计划继续使用 AD FS 和本地和 SaaS 应用程序（使用 SAML/WS-FED 或 OAuth 协议），则将在转换域以进行用户身份验证后同时使用 AD FS 和 Microsoft Entra ID。 在这种情况下，可以通过 Microsoft Entra 应用程序代理 或 Microsoft Entra ID 合作伙伴集成来保护本地应用程序和资源，并使用安全混合访问（SHA）。 使用应用程序代理或者我们的合作伙伴之一，可以提供对本地应用程序的安全远程访问。 在 单一登录后，用户可以轻松地从任何设备连接到其应用程序，从而受益。 有关详细信息，请参阅 使用信赖方安全令牌服务为企业应用程序启用单一登录。
可以将当前与 ADFS 联合的 SaaS 应用程序移动到 Microsoft Entra ID。 重新配置以使用 Microsoft Entra ID 进行身份验证，可以通过 Azure 应用库中的内置连接器，或者通过在 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）停用指南。