设计云、混合和多云访问策略（包括 Microsoft Entra ID）
在任何环境中，无论是本地、混合还是仅限云，IT 都需要控制哪些管理员、用户和组有权访问资源。 通过标识和访问管理（IAM）服务，可以在云中管理访问控制。
有多种选项可用于在云环境中管理标识。 这些选项因成本和复杂性而异。 构建基于云的标识服务的一个关键因素是与现有本地标识基础结构的集成级别。
Microsoft Entra ID 为 Azure 资源提供云、基线级别的访问控制和标识管理，这是独立的，并且与本地 Active Directory 没有集成。 如果组织的本地 Active Directory 基础结构具有复杂的林结构或自定义的组织单位（OU），则基于云的工作负荷可能需要与 Microsoft Entra ID 进行目录同步，以实现本地和云环境之间身份、组和角色的一致性。 此外，对依赖于旧式身份验证机制的应用程序的支持可能需要在云中部署 Active Directory 域服务（AD DS）。
基于云的标识管理是一个迭代过程。 可以从云原生解决方案开始，其中包含少量用户和初始部署的相应角色。 随着迁移的成熟，可能需要使用目录同步集成标识解决方案，或将域服务添加为云部署的一部分。 在迁移过程的每次迭代中重新审视身份策略。
确定标识集成要求
如本单元开头所述，构建基于云的标识服务的一个关键因素是与现有本地标识基础结构所需的集成级别。
| 问题 | 云基线 | 目录同步 | 云托管域服务 | Active Directory 联合身份验证服务 |
|---|---|---|---|---|
| 你当前是否缺少本地目录服务？ | 是的 | 否 | 否 | 否 |
| 工作负荷是否需要在云和本地环境之间使用一组常见的用户和组？ | 否 | 是的 | 否 | 否 |
| 工作负荷是否依赖于旧式身份验证机制，例如 Kerberos 或 NTLM？ | 否 | 否 | 是的 | 是的 |
| 是否需要跨多个标识提供者进行单一登录？ | 否 | 否 | 否 | 是的 |
在规划迁移到 Azure 时，需要确定如何最好地集成现有标识管理和云标识服务。 以下是常见的集成方案。
云基线
Microsoft Entra ID 是本机标识和访问管理 （IAM） 系统，用于授予用户和组对 Azure 平台上管理功能的访问权限。 如果你的组织缺少重要的本地标识解决方案，并且你计划迁移工作负载以与基于云的身份验证机制兼容，则应开始使用 Microsoft Entra ID 作为基础来开发标识基础结构。
云基线假设：使用纯云原生标识基础结构假设以下各项：
- 基于云的资源不会依赖于本地目录服务或 Active Directory 服务器，或者可以修改工作负荷来删除这些依赖项。
- 要迁移的应用程序或服务工作负荷要么支持与 Microsoft Entra ID 兼容的身份验证机制，也可以轻松修改以支持它们。 Microsoft Entra ID 依赖于 Internet 就绪的身份验证机制，例如 SAML、OAuth 和 OpenID Connect。 使用 Kerberos 或 NTLM 等协议依赖旧式身份验证方法的现有工作负荷可能需要重构，然后才能使用云基线模式迁移到云。
目录同步
对于具有现有本地 Active Directory 基础结构的组织，目录同步通常是保留现有用户和访问管理的最佳解决方案，同时提供管理云资源所需的 IAM 功能。 此过程持续同步Microsoft Entra ID和本地目录服务之间的目录信息，允许用户使用通用凭据，并确保组织内身份、角色和权限系统的一致性。
目录同步假设：使用同步的标识解决方案假设如下：
- 需要在云和本地 IT 基础结构中维护一组常见的用户帐户和组。
- 本地标识服务支持使用 Microsoft Entra ID 进行复制。
Microsoft支持目录同步的解决方案之一是Microsoft Entra Sync。
Microsoft Entra Connect Sync 旨在满足并实现涉及将用户、组和联系人同步到 Microsoft Entra ID 的混合身份目标。 它将通过使用 Microsoft Entra 云预配代理来实现此目标。
Microsoft Entra Connect Sync 具有以下优势：
- 对从已断开连接的多林 Active Directory 林环境同步到 Microsoft Entra 租户的支持：常见场景包括合并和收购。 在这些情况下，收购公司的 AD 森林与母公司的 AD 森林是隔离的。 另一个场景涉及历史上拥有多个 AD 林的公司。
- 使用轻型预配代理简化安装：代理充当 AD 与 Microsoft Entra ID 之间的桥梁，所有同步配置托管在云中。
- 可以使用多个预配代理来简化高可用性部署。 对于依赖于从 AD 到 Microsoft Entra ID 的密码哈希同步的组织来说，它们至关重要。
- 支持最多 50,000 个成员的大型群组。
有关详细信息 ，请参阅Microsoft Entra Cloud Sync 支持的拓扑和方案 。
云托管域服务
如果工作负荷依赖于使用旧协议（如 Kerberos 或 NTLM）的基于声明的身份验证，并且无法重构这些工作负载以接受新式身份验证协议（如 SAML 或 OAuth 和 OpenID Connect），则可能需要在云部署过程中将某些域服务迁移到云。
此模式涉及将运行 Active Directory 的虚拟机部署到基于云的虚拟网络，以便为云中的资源提供 Active Directory 域服务（AD DS）。 迁移到云网络的任何现有应用程序和服务应能通过轻微更改来使用这些云托管的目录服务器。
现有目录和域服务可能继续在本地环境中使用。 在此方案中，还应使用目录同步在云和本地环境中提供一组常见的用户和角色。
云托管的域服务假设：执行目录迁移假设如下：
- 工作负荷依赖于使用 Kerberos 或 NTLM 等协议的基于声明的身份验证。
- 为管理或应用 Active Directory 组策略，工作负载虚拟机需要加入域。
可通过两种方法在云中提供 Active Directory 域服务：
- 使用传统资源（例如虚拟机（VM）、Windows Server 来宾操作系统和 Active Directory 域服务（AD DS））创建和配置的自我管理域名。 然后，你需要继续管理这些资源。
- 使用 Microsoft Entra 域服务创建的托管域。 Microsoft创建和管理所需的资源。 这相对于自托管简化了部署，因此会位于图中所示的云托管域服务的左侧
Microsoft Entra 域服务。 Microsoft Entra 域服务提供托管域服务，例如域加入、组策略、轻型目录访问协议 (LDAP) 和 Kerberos/NTLM 身份验证。 无需在云中部署、管理和修补域控制器 (DC) 即可使用这些域服务。
域服务可与你现有的 Microsoft Entra 租户集成。 通过此集成，用户可以使用其现有凭据登录到与托管域相连的服务和应用程序。 还可以使用现有组和用户帐户来保护对资源的访问。 这些功能可更顺畅地将本地资源直接迁移到 Azure。
Active Directory 联合身份验证服务
身份联合在多个身份管理系统之间建立信任关系，以实现共同的身份验证和授权功能。 然后，可以在组织或客户或业务合作伙伴管理的标识系统中支持跨多个域的单一登录功能。
Microsoft Entra ID 支持通过 Active Directory 联合身份验证服务 (AD FS) 实现本地 Active Directory 域的联合。