你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
标识决策指南
在任何环境中，无论是本地环境、混合环境，还是纯云环境，IT 都需要控制哪些管理员、用户和组可以访问资源。 标识和访问管理 (IAM) 服务使你能够管理云中的访问控制。
跳转到：确定标识集成需求 | 云基线 | 目录同步 | 云托管的域服务 | Active Directory 联合身份验证服务 | 了解详细信息
有多个选项可用于在云环境中管理标识。 这些选项的成本和复杂性各不相同。 构建基于云的标识服务的一个关键因素是现有本地标识基础结构所需的集成级别。
Microsoft Entra ID 提供 Azure 资源的访问控制和标识管理的基本级别。 如果组织的本地 Active Directory基础结构具有复杂的林结构或自定义的组织单位（OU），则基于云的工作负载可能需要与 Microsoft Entra ID 进行目录同步，以便在本地环境和云环境之间实现一组一致的标识、组和角色。 此外，对依赖于旧版身份验证机制的应用程序的支持可能需要在云中部署 Active Directory 域服务 (AD DS)。
基于云的标识管理是一个迭代过程。 你可能会从一个云原生解决方案开始，对于初始部署，该解决方案具有少量用户和相应角色。 随着迁移的成熟，可能需要使用目录同步来集成标识解决方案，或者在云部署过程中添加域服务。 在迁移过程的每个迭代中重新访问标识策略。
确定标识集成要求
| 问题 | 云基线 | 目录同步 | 云托管的域服务 | Active Directory 联合身份验证服务 |
|---|---|---|---|---|
| 你当前是否缺少本地目录服务？ | 是 | No | 否 | 否 |
| 工作负载是否需要在云和本地环境之间使用一组通用的用户和组？ | 否 | 是 | No | 否 |
| 你的工作负载是否依赖于传统身份验证机制，例如 Kerberos 或 NTLM？ | 否 | 否 | 是 | 是 |
| 你是否需要跨多个标识提供者进行单一登录？ | 否 | 否 | 否 | 是 |
在迁移到 Azure 的计划中，你需要确定如何以最佳方式集成现有标识管理和云标识服务。 以下是常见集成方案。
云基线
Microsoft Entra ID 是本机标识和访问管理 （IAM） 系统，用于授予用户和组对 Azure 平台上管理功能的访问权限。 如果你的组织缺少重要的本地标识解决方案，并且你计划迁移工作负载以与基于云的身份验证机制兼容，则应开始使用 Microsoft Entra ID 作为基础开发标识基础结构。
云基线假设： 使用纯云原生标识基础结构假设以下各项：
- 基于云的资源将不会依赖于本地目录服务或 Active Directory 服务器，或者可以修改工作负载来删除这些依赖项。
- 要迁移的应用程序或服务工作负荷要么支持与 Microsoft Entra ID 兼容的身份验证机制，也可以轻松修改它们以支持它们。 Microsoft Entra ID 依赖于 Internet 就绪的身份验证机制，例如 SAML、OAuth 和 OpenID 连接。 在使用云基线模式迁移到云之前，可能需要重构依赖于使用 Kerberos 或 NTLM 等协议的传统身份验证方法的现有工作负荷。
提示
将标识服务完全迁移到 Microsoft Entra ID 无需维护自己的标识基础结构，从而大大简化了 IT 管理。
但 Microsoft Entra ID 不是传统本地 Active Directory基础结构的完整替代项。 如果不向云部署其他工具或服务，则可能无法使用传统身份验证方法、计算机管理或组策略等目录功能。
对于需要将本地标识或域服务与云部署集成的方案，请参阅下面讨论的目录同步和云托管域服务模式。
目录同步
对于具有现有本地 Active Directory 基础结构的组织，目录同步通常是保留现有用户和访问权限管理，同时提供管理云资源所需的 IAM 功能的最佳解决方案。 此过程持续副本 (replica) Microsoft Entra ID 与本地目录服务之间的目录信息，从而为用户提供通用凭据，以及整个组织内一致的标识、角色和权限系统。
注意
采用 Microsoft 365 的组织可能已经在其本地 Active Directory基础结构和 Microsoft Entra ID 之间实现了目录同步。
目录同步假设： 使用同步的标识解决方案假设如下：
- 你需要跨云和本地 IT 基础结构维护一组通用的用户帐户和组。
- 本地标识服务支持使用 Microsoft Entra ID 副本 (replica)tion。
提示
任何依赖于本地 Active Directory服务器提供的旧式身份验证机制且 Microsoft Entra ID 不支持的基于云的工作负载仍需要连接到提供这些服务的云环境中的本地域服务或虚拟服务器。 此外，使用本地标识服务还会引入对云和本地网络之间连接性的依赖项。
云托管的域服务
如果你的工作负荷依赖于使用传统协议（如 Kerberos 或 NTLM）的基于声明的身份验证，并且这些工作负荷无法重构以接受 SAML 或 OAuth 和 OpenID Connect 等新式身份验证协议，则可能需要将某些域服务作为云部署的一部分迁移到云。
此模式涉及将运行 Active Directory 的虚拟机部署到基于云的虚拟网络，以便为云中的资源提供 Active Directory 域服务 (AD DS)。 迁移到云网络的任何现有应用程序和服务都应该能够使用这些云托管目录服务器，只需稍加修改即可。
你的现有目录和域服务很可能将继续在本地环境中使用。 在此场景中，还应使用目录同步来在云环境和本地环境中提供一组通用的用户和角色。
云托管的域服务假设： 执行目录迁移假设如下：
- 你的工作负载依赖于使用 Kerberos 或 NTLM 等协议的基于的身份验证。
- 为管理或应用 Active Directory 组策略，工作负载虚拟机需要加入域。
提示
虽然目录迁移结合云托管的域服务在迁移现有工作负载时提供了极大的灵活性，但在云虚拟网络中托管虚拟机来提供这些服务确实增加了 IT 管理任务的复杂性。 随着云迁移体验日趋成熟，请检查托管这些服务器的长期维护需求。 请考虑重构现有工作负载，以便与云标识提供者（如 Microsoft Entra ID）兼容，以减少这些云托管服务器的需求。
Active Directory 联合身份验证服务
联合身份验证将在多个标识管理系统之间建立信任关系，可以支持常见身份验证和授权功能。 然后，你可以支持跨组织内或由客户或业务合作伙伴管理的标识系统中多个域的单一登录功能。
Microsoft Entra ID 支持使用 Active Directory 联合身份验证服务 （AD FS） 联合本地 Active Directory域。 若要详细了解如何在 Azure 中实现此目标，请参阅将 AD FS 扩展到 Azure。
了解详细信息
有关 Azure 中标识服务的详细信息，请参阅：
- Microsoft Entra ID。 Microsoft Entra ID 提供基于云的标识服务。 它允许你管理对 Azure 资源的访问权限，并控制标识管理、设备注册、用户预配、应用程序访问控制和数据保护。
- Microsoft Entra 连接。 Microsoft Entra 连接 工具允许将 Microsoft Entra 实例连接到现有的标识管理解决方案，从而允许同步云中的现有目录。
- Azure 基于角色的访问控制 (Azure RBAC)。 Azure RBAC 可有效且安全地管理对管理平面中的资源访问。 作业和职责按角色进行组织，用户被赋予这些角色。 Azure RBAC 可控制谁有权访问资源，以及用户可以对该资源执行哪些操作。
- Microsoft Entra Privileged Identity Management （PIM）。 PIM 降低了资源访问特权的公开时间，并通过报告和警报增加了对其使用的可见性。 它通过以下方式限制用户只能使用实时特权：使特权分配持续时间有限，之后再自动撤销这些特权。
- 将本地 Active Directory域与 Microsoft Entra ID 集成。 此参考体系结构提供了本地 Active Directory域与 Microsoft Entra ID 之间的目录同步示例。
- 将 Active Directory 域服务 (AD DS) 扩展到 Azure。 此参考体系结构提供了部署 AD DS 服务器以将域服务扩展到基于云的资源的示例。
- 将 Active Directory 联合身份验证服务 (AD FS) 扩展到 Azure。 此参考体系结构将 Active Directory 联合身份验证服务 （AD FS） 配置为使用 Microsoft Entra 目录执行联合身份验证和授权。
后续步骤
标识只是云采用过程中需要体系结构决策的核心基础结构组件之一。 若要了解在为其他类型的基础结构制定设计决策时使用的替代模式或模型，请参阅架构决策指南概述。