组织越来越多地采用云优先方法来现代化其标识和访问管理（IAM）解决方案。 对于云计划的道路，Microsoft已经 建模了五种转型状态， 以符合客户业务目标。 将用户的授权源（SOA）从本地 Active Directory 域服务（AD DS）过渡到云是这一过程中的关键步骤。 此过程称为 AD DS 最小化，通过直接在云中管理用户来降低本地基础结构的复杂性。
本文介绍用户 SOA 的概念、其优势以及它支持的方案。 它还概述了 IT 管理员计划使用 Microsoft Entra ID 将用户管理转移到云的关键注意事项和先决条件。 通过使用用户 SOA，组织可以简化用户生命周期管理、启用高级治理功能，并完全采用云优先态势。 有关将用户 SOA 用于 IT 架构师的指南，请参阅： Cloud-First 标识管理：IT 架构师指南。
视频：Microsoft Entra 用户权威来源
请查看此视频，了解 SOA 简介及其如何帮助你迁移到云：
用户 SOA 场景
后续部分将介绍有关用户 SOA 支持的方案的更多详细信息。
使用 Microsoft Entra ID Governance 最大程度地减少 AD 用户和管理用户生命周期
方案：你对部分或所有应用程序进行了现代化，并删除了使用 AD DS 用户进行访问的需求。 例如，这些应用程序现在使用来自 Microsoft Entra ID 的 安全断言标记语言（SAML） 或 OpenID Connect 的用户声明，而不是使用 AD FS 等联合系统。 但是，这些应用仍依赖于现有的同步用户来管理访问权限。 通过实现用户 SOA，可以在云中编辑用户，完全删除 AD DS 用户，并通过 Microsoft Entra ID Governance 功能管理用户。
SOA 转移用户的无密码身份验证
场景：你已为用户实现 SOA，现在想要允许他们访问本地和云资源。 无需完全从本地删除用户，而是引入云 Kerberos 信任无密码身份验证，以允许他们保持混合状态，使他们能够继续访问其本地资源，同时允许他们访问云资源。 无密码身份验证方法（例如 Windows Hello 企业版或 FIDO2 安全密钥）可用于允许这些用户通过 Microsoft Entra Private Access 访问其本地资源和云资源（如 Azure 文件存储）。 使用无密码身份验证还可以在 SOA 传输的用户上启用多重身份验证，从而提高安全性。 无密码身份验证还允许在本地资源上启用条件访问策略，从而对这些资源进行更大的控制和安全性。 要使此方案正常工作，用户帐户必须保留在 Active Directory 中。
传输用户 SOA 的先决条件
在开始为组织中的用户转移 SOA 之前，环境必须满足以下先决条件：
- 云 HR 系统已配置并成功与 Microsoft Entra ID 集成。 对从 HR 系统预配的用户所做的更改应直接发送到 Microsoft Entra ID。 有关详细信息，请参阅：将用户配置中的预配操作从HR系统中转移。
- 没有本地 Exchange 工作负载。 如果当前使用的是本地 Exchange 服务器，则将用户和邮箱转移到云，然后删除本地 Exchange。 有关详细信息，请参阅： 准备 Microsoft Exchange 设置。
- 任何身份验证方法都适用于云用户，但如果使用基于 Kerberos 的应用程序，则需要无密码身份验证。
- 必须使用 云 Kerberos 信任类型 。
- 用于 SOA 传输的用户不会与需要基于密码的身份验证的任何应用程序相关联。 如果要传输 SOA 的任何用户具有任何密码依赖项，则不支持传输 SOA。 如果用户使用 Active Directory 联合身份验证服务进行联合身份验证，则不支持传输 SOA。 如果你的组织使用第三方联合身份验证标识提供者，并计划转移用户的 SOA，则必须手动管理 Active Directory 帐户。 在此过程中，必须使用第三方同步工具维护密码。