介绍 Microsoft Entra 域服务
Contoso IT 团队在作为域成员的计算机和设备上部署了多个业务线 (LOB) 应用程序。 Contoso 使用基于 AD DS 的凭据进行身份验证，使用 GPO 来管理这些设备和应用。 现在他们正在考虑将这些应用转移到 Azure 中运行。 关键问题是如何为这些应用提供身份验证服务。
为了满足这一需求，Contoso IT 团队可以选择：
- 在本地基础结构与 Azure IaaS 之间实现站点到站点虚拟专用网络 (VPN)。
- 将本地 AD DS 中的副本域控制器部署为 Azure 中的 VM。
但是，这些方法可能会产生额外的成本和管理工作量。 此外，这两种方法之间的区别是：在第一个方法中，身份验证流量需要跨越 VPN；在第二个方法中，复制流量需要跨越 VPN，而身份验证流量仍保留在云中。 Microsoft 提供了 Microsoft Entra 域服务来作为这些方法的替代方法。
什么是 Microsoft Entra 域服务？
Microsoft Entra 域服务（作为 Microsoft Entra ID P1 或 P2 层的一部分运行）向 Microsoft Entra 租户提供组策略管理、域加入和 Kerberos 身份验证等域服务。 这些服务与本地 AD DS 完全兼容，因此使用它们时无需在云中部署和管理其他域控制器。
由于 Microsoft Entra ID 可以与本地 AD DS 集成，因此在你实施 Microsoft Entra Connect 时，用户可以在本地 AD DS 和 Microsoft Entra 域服务中都使用组织凭据。 即使未在本地部署 AD DS，也可以选择使用 Microsoft Entra 域服务作为仅限云的服务。 这样你便有了与本地部署的 AD DS 类似的功能，而无需在本地或云中部署单个域控制器。
例如，Contoso IT 人员可以选择创建 Microsoft Entra 租户并启用 Microsoft Entra 域服务，然后在其本地资源和 Microsoft Entra 租户之间部署虚拟网络 (VNet)。 Contoso IT 人员可以为此 VNet 启用 Microsoft Entra 域服务，以便所有本地用户和服务都可以从 Microsoft Entra ID 中使用域服务。
Microsoft Entra 域服务可为组织提供多项好处，例如：
- 管理员无需管理、更新和监视域控制器。
- 管理员无需部署和管理 Active Directory 复制。
- 对于 Microsoft Entra 域服务管理的域，无需设置“域管理员”或“企业管理员”组。
如果选择实施 Microsoft Entra 域服务，则必须了解服务的当前限制。 这些方法包括：
- 仅支持 Active Directory 基本计算机对象。
- 扩展 Microsoft Entra 域服务域的架构是不可能的。
- OU 结构是平面的，当前不支持嵌套的 OU。
- 有内置 GPO，用于计算机和用户帐户。
- 不能使用内置 GPO 来定向到 OU。 此外，不能使用 Windows Management Instrumentation (WMI) 筛选器或安全组筛选。
使用 Microsoft Entra 域服务，可以将使用 LDAP、NT LAN Manager (NTLM) 或 Kerberos 协议的应用程序从本地基础结构中自由迁移到云。 还可以在 VM 上使用 Microsoft SQL Server 或 SharePoint Server 等应用程序，或将其部署到 Azure IaaS 中。 所有这些都不需要云中的域控制器，也不需要与本地基础结构连接的 VPN。 下表标识了一些利用 Microsoft Entra 域服务的常见方案。
| 优点 | 说明 |
|---|---|
| 安全管理 Azure VM | 可以将 Azure VM 加入到 Microsoft Entra 域服务托管域中，这样便可以使用一组 Active Directory 凭据。 此方法可减少凭据管理问题，例如维护每个 VM 上的本地管理员帐户或环境之间的帐户和密码。 可以管理和保护加入到 Microsoft Entra 域服务托管域的 VM。 也可将所需的安全基线应用到 VM 以根据企业安全指导原则锁定这些 VM。 例如，可以使用组策略管理功能来限制可在 VM 上启动的应用程序类型。 |
| 使用 LDAP 绑定身份验证的本地应用程序 | 在此方案中，Microsoft Entra 域服务允许应用程序在身份验证过程中执行 LDAP 绑定。 旧版本地应用程序可以直接迁移到 Azure，并继续无缝验证用户身份，而无需更改任何配置或用户体验。 |
| 使用 LDAP 读取访问目录的本地应用程序 | 在此方案中，Microsoft Entra 域服务允许应用程序对托管域执行 LDAP 读取操作，以检索所需的属性信息。 无需重新编写应用程序，通过直接迁移到 Azure，用户可以继续使用该应用，而不会意识到其运行位置发生了变化。 |
| 本地服务或守护程序应用程序 | 某些应用程序包含多个层，其中有一个层需要对后端层（如数据库）执行经身份验证的调用。 在这些方案中，通常会使用 Active Directory 服务帐户。 将应用程序直接迁移到 Azure 时，通过 Microsoft Entra 域服务，你能够以相同的方式继续使用服务帐户。 可以选择使用已从本地目录同步到 Microsoft Entra ID 的同一服务帐户，也可以创建自定义 OU，然后在该 OU 中创建一个单独的服务帐户。 使用其中任意一种方法，应用程序都将继续以相同的方式对其他层和服务进行经身份验证的调用。 |
| Azure 中的远程桌面服务 | 还可以使用 Microsoft Entra 域服务向 Azure 中部署的远程桌面服务器提供托管域服务。 |
注意事项
在实现前面的方案时，应考虑以下部署注意事项：
- 默认情况下，Microsoft Entra 域服务托管域使用单一、扁平的 OU 结构。 所有已加入域的 VM 均位于单个 OU 中。 如果需要，可以创建自定义 OU。
- Microsoft Entra 域服务使用分别适用于用户和计算机容器的内置 GPO。 若要进行其他控制，可以创建自定义 GPO，并将其目标设为自定义 OU。
- Microsoft Entra 域服务支持基本 Active Directory 计算机对象架构。 但是，无法扩展计算机对象的架构。
- 不能直接在 Microsoft Entra 域服务托管域中更改密码。 最终用户可以使用 Microsoft Entra ID 的自助密码更改机制或针对本地目录更改其密码。 随后，这些更改会自动同步并提供到 Microsoft Entra 域服务托管域中。
同时，请确保：
- 任何应用程序都不需要修改/写入 LDAP 目录。 对 Microsoft Entra 域服务托管域的 LDAP 写入访问不受支持。
- 应用程序不需要自定义/扩展的 Active Directory 架构。 Microsoft Entra 域服务不支持架构扩展。
- 应用程序使用用户名和密码进行身份验证。 Microsoft Entra 域服务不支持基于证书或基于智能卡的身份验证。