比较自托管 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 可以与本地 Active Directory 域服务环境同步，为用户提供在云中无缝兼容的单一身份。
- 有关Microsoft Entra ID 的详细信息，请参阅 什么是 Microsoft Entra ID？
- Microsoft Entra Domain Services - 为托管域服务提供一部分完全兼容的传统 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 云环境 - Azure 虚拟网络通过 VPN/ExpressRoute 连接与本地网络相连。 Azure VM 将连接到此 Azure 虚拟网络，因此可通过域加入添加到本地 AD DS 环境。
- 另一种方法是创建 Azure VM 并将其提升为本地 AD DS 域的副本域控制器。 这些域控制器通过 VPN/ExpressRoute 连接复制到本地 AD DS 环境。 本地 AD DS 域可有效地扩展到 Azure。
下表概述了组织可能需要的一些功能，以及托管域或自托管 AD DS 域之间的差异：
| 功能 | 托管域 | 自我管理型 AD DS |
|---|---|---|
| 托管服务 | ✓ | ✕ |
| 安全部署 | ✓ | 管理员确保部署安全 |
| DNS 服务器 | ✓（托管服务） | ✓ |
| 域或企业管理员权限 | ✕ | ✓ |
| 域加入 | ✓ | ✓ |
| 使用 NTLM 和 Kerberos 进行域身份验证 | ✓ | ✓ |
| Kerberos 约束委派 | 基于资源 | 基于资源和基于帐户 |
| 自定义 OU 结构 | ✓ | ✓ |
| 组策略 | ✓ | ✓ |
| 架构扩展 | ✕ | ✓ |
| AD 域/林信任 | ✓ （预览需要企业SKU） | ✓ |
| 安全 LDAP (LDAPS) | ✓ | ✓ |
| LDAP 读取 | ✓ | ✓ |
| LDAP 写入 | •（托管域中） | ✓ |
| 异地分布式部署 | ✓ | ✓ |
域服务和 Microsoft Entra ID
Microsoft Entra ID 允许管理组织使用设备的身份，并控制从这些设备对公司资源的访问。 用户还可以使用 Microsoft Entra ID 注册他们的个人设备（自带设备（BYO）模式），该 ID 为设备提供标识。 然后，当用户登录到 Microsoft Entra ID 并使用设备访问受保护的资源时，Microsoft Entra ID 对设备进行身份验证。 可以使用移动设备管理（MDM）软件（如 Microsoft Intune）来管理设备。 通过此管理能力，可以将敏感资源的访问权限限制为受管理的设备和符合策略的设备。
传统计算机和笔记本电脑也可以加入 Microsoft Entra ID。 此机制提供了使用 Microsoft Entra ID 注册个人设备的好处，例如允许用户使用其公司凭据登录到设备。
已加入 Microsoft Entra 的设备提供以下优势：
- 单一登录 (SSO) 到 Microsoft Entra ID 保护的应用程序。
- 在不同的设备之间以符合企业策略的方式漫游用户设置。
- 使用公司凭据访问适用于企业的 Windows 应用商店。
- Windows Hello 企业版。
- 限制从符合公司策略的设备访问应用和资源。
设备可以加入到包含本地 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 协议 |
| 管理 | 移动设备管理（MDM）软件，如 Intune | 组策略 |
| 联网 | 通过 Internet 工作 | 必须连接到部署管理域的虚拟网络或与其对等互连 |
| 非常适合用于... | 最终用户移动设备或桌面设备 | 在 Azure 中部署的服务器 VM |
如果本地 AD DS 和 Microsoft Entra ID 配置为使用 AD FS 进行联合身份验证，则 Azure DS 中没有可用的密码哈希（当前/有效）。 Microsoft实现 fed 身份验证之前创建的 Entra 用户帐户可能有旧密码哈希，但这可能与本地密码的哈希不匹配。 因此，域服务将无法验证用户凭据
后续步骤
若要开始使用域服务，使用 Microsoft Entra 管理中心创建域服务托管域。
你还可以详细了解 域服务中用户帐户、密码和管理的管理概念以及如何在托管域中同步对象和凭据。