比较自托管 Active Directory 域服务、Microsoft Entra ID 和托管 Microsoft Entra 域服务
若要为应用程序、服务或设备提供对中心标识的访问权限，可通过三种常用方式使用 Azure 中基于 Active Directory 的服务。 标识解决方案的多样性可让你灵活使用最符合组织需求的目录。 例如，如果主要工作是管理运行移动设备的仅限云的用户，那么生成并运行自己的 Active Directory 域服务 (AD DS) 标识解决方案可能没有意义。 你可以只使用 Microsoft Entra ID。
尽管这三个基于 Active Directory 的标识解决方案采用相同的名称部分和技术，但它们旨在提供满足不同客户需求的服务。 从较高层面讲，这些标识解决方案和功能集包括：
- Active Directory 域服务 (AD DS) - 随时可在企业中部署的轻型目录访问协议 (LDAP) 服务器，提供标识和身份验证、计算机对象管理、组策略和信任等关键功能。
- AD DS 是使用本地 IT 环境的众多组织中的一个中心组件，提供核心用户帐户身份验证和计算机管理功能。
- 有关详细信息，请参阅 Windows Server 文档中的 Active Directory 域服务概述。
- Microsoft Entra ID - 基于云的标识和移动设备管理，为 Microsoft 365、Microsoft Entra 管理中心或 SaaS 应用程序等资源提供用户帐户和身份验证服务。
- Microsoft Entra ID 可与本地 AD DS 环境同步，以便为原本就在云中工作的用户提供单个标识。
- 有关 Microsoft Entra ID 的详细信息，请参阅什么是 Microsoft Entra ID？
- Microsoft Entra 域服务 - 为托管域服务提供一部分完全兼容的传统 AD DS 功能，例如域加入、组策略、LDAP 和 Kerberos/NTLM 身份验证。
- 域服务与 Microsoft Entra ID 集成，后者本身可与本地 AD DS 环境同步。 此功能通过直接迁移策略将中心标识用例扩展到在 Azure 中运行的传统 Web 应用程序。
- 若要详细了解与 Microsoft Entra ID 和本地的同步，请参阅如何在托管域中同步对象和凭据。
本概述文章将这些标识解决方案根据组织需求相互配合工作或者独立工作时的情况做了对比。
域服务和自托管 AD DS
如果你有应用程序和服务需要访问 Kerberos 或 NTLM 等传统身份验证机制，可通过两种方式在云中提供 Active Directory 域服务：
- 使用 Microsoft Entra 域服务创建的托管域。 Microsoft 将创建并管理所需的资源。
- 使用虚拟机 (VM)、Windows Server 来宾 OS 和 Active Directory 域服务等传统资源创建和配置的自我管理域。 然后，你需要继续管理这些资源。
使用域服务时，Microsoft 将为你部署和维护核心服务组件（托管域体验）。 你无需部署、管理、修补和保护 VM、Windows Server OS 或域控制器 (DC) 等组件的 AD DS 基础结构。
域服务提供传统自我管理型 AD DS 环境的一小部分功能，这在一定程度上可以减轻设计和管理复杂性。 例如，无需设计和维护 AD 林、域、站点和复制链接。 你仍可以在域服务和本地环境之间创建林信任。
对于在云中运行且需要访问传统身份验证机制（例如 Kerberos 或 NTLM）的应用程序和服务，域服务提供了托管域体验，而产生极少量的管理开销。 有关详细信息，请参阅域服务中用户帐户、密码和管理的管理概念。
部署和运行自我管理型 AD DS 环境时，必须维护所有关联的基础结构和目录组件。 自行管理型 AD DS 环境会产生额外的维护开销，但你可以执行更多的任务，例如扩展架构或创建林信任。
为云中的应用程序和服务提供标识的自我管理型 AD DS 环境的常见部署模型包括：
- 独立的仅限云 AD DS - 将 Azure VM 配置为域控制器，并创建独立的仅限云的 AD DS 环境。 此 AD DS 环境不会与本地 AD DS 环境集成。 使用一组不同的凭据来登录和管理云中的 VM。
- 将本地域扩展到 Azure - 使用 VPN/ExpressRoute 连接将 Azure 虚拟网络连接到本地网络。 Azure VM 将连接到此 Azure 虚拟网络，因此可通过域加入添加到本地 AD DS 环境。
- 一种替代方法是创建 Azure VM, 并从本地 AD DS 域将其提升为副本域控制器。 这些域控制器通过与本地 AD DS 环境建立的 VPN/ExpressRoute 连接复制。 本地 AD DS 域将有效地扩展到 Azure 中。
下表概述了组织可能需要的某些功能，还概述了托管域与自我管理型 AD DS 域之间的区别：
| 功能 | 托管域 | 自我管理型 AD DS |
|---|---|---|
| 托管服务 | ✓ | ✕ |
| 安全部署 | ✓ | 管理员保护部署 |
| DNS 服务器 | ✓（托管服务） | ✓ |
| 域或企业管理员特权 | ✕ | ✓ |
| 域加入 | ✓ | ✓ |
| 使用 NTLM 和 Kerberos 进行域身份验证 | ✓ | ✓ |
| Kerberos 约束委派 | 基于资源 | 基于资源和基于帐户 |
| 自定义 OU 结构 | ✓ | ✓ |
| 组策略 | ✓ | ✓ |
| 架构扩展 | ✕ | ✓ |
| AD 域/林信任 | ✓（仅单向出站林信任） | ✓ |
| 安全 LDAP (LDAPS) | ✓ | ✓ |
| LDAP 读取 | ✓ | ✓ |
| LDAP 写入 | ✓（在托管域中） | ✓ |
| 地理分布式部署 | ✓ | ✓ |
域服务和 Microsoft Entra ID
使用 Microsoft Entra ID 可以管理组织所用的设备标识，以及控制这些设备对企业资源的访问。 用户还可将其个人设备（自带 (BYO) 模式）注册到 Microsoft Entra ID，后者为设备提供一个标识。 然后，当用户登录到 Microsoft Entra ID 并使用设备访问受保护的资源时，Microsoft Entra ID 会对该设备进行身份验证。 可以使用 Microsoft Intune 等移动设备管理 (MDM) 软件来管理设备。 使用此管理功能可以限制受管且符合策略的设备对敏感资源的访问。
传统计算机和便携式计算机也可以加入 Microsoft Entra ID。 此机制提供将个人设备注册到 Microsoft Entra ID 所能得到的相同优势，例如，允许用户使用其企业凭据登录到设备。
已加入 Microsoft Entra 的设备提供以下优势：
- 单一登录 (SSO) 到 Microsoft Entra ID 保护的应用程序。
- 在不同的设备之间以符合企业策略的方式漫游用户设置。
- 使用企业凭据访问 Windows Store for Business。
- Windows Hello for Business。
- 限制从符合企业策略的设备对应用和资源的访问。
设备可以加入到包含本地 AD DS 环境的、使用或不使用混合部署的 Microsoft Entra ID。 下表概述了常见的设备所有权模型，以及它们在一般情况下如何加入域：
| 设备类型 | 设备平台 | 机制 |
|---|---|---|
| 个人设备 | Windows 10、iOS、Android、macOS | 已注册 Microsoft Entra |
| 组织拥有的未加入本地 AD DS 的设备 | Windows 10 | 已联接 Microsoft Entra |
| 组织拥有的已加入本地 AD DS 的设备 | Windows 10 | 已进行 Microsoft Entra 混合联接 |
在已加入或已注册 Microsoft Entra 的设备上，使用基于 OAuth/OpenID Connect 的新式协议执行用户身份验证。 这些协议设计为通过 Internet 工作，因此非常适合用于移动方案，可让用户从任何位置访问企业资源。
借助已加入域服务的设备，应用程序可以使用 Kerberos 和 NTLM 协议进行身份验证，因此支持在执行直接迁移策略的过程中迁移到在 Azure VM 上运行的传统应用程序。 下表概述了设备的表示方式以及针对目录进行身份验证的差异：
| 方面 | 已建立 Microsoft Entra 联接 | 已加入域服务 |
|---|---|---|
| 设备控制方 | Microsoft Entra ID | 域服务托管域 |
| 在目录中的表示形式 | Microsoft Entra 目录中的设备对象 | 域服务托管域中的计算机对象 |
| 身份验证 | 基于 OAuth/OpenID Connect 的协议 | Kerberos 和 NTLM 协议 |
| 管理 | Intune 等移动设备管理 (MDM) 软件 | 组策略 |
| 网络 | 通过 Internet 工作 | 必须连接到部署管理域的虚拟网络或与其对等互连 |
| 非常适合用于... | 最终用户移动设备或台式机设备 | 在 Azure 中部署的服务器 VM |
如果将本地 AD DS 和 Microsoft Entra ID 配置为使用 AD FS 进行联合身份验证，则 Azure DS 中没有可用的（当前/有效）密码哈希。 在实施联合身份验证之前创建的 Microsoft Entra 用户帐户可能有旧密码哈希，但这可能与其本地密码的哈希不匹配。 因此，域服务将无法验证用户凭据
后续步骤
要开始使用域服务，请通过 Microsoft Entra 管理中心创建一个域服务托管域。
你还可以详细了解 域服务中用户帐户、密码和管理的管理概念以及如何在托管域中同步对象和凭据。