Microsoft Entra 域服务的常见用例和方案

Microsoft Entra 域服务提供托管域服务，例如域加入、组策略、轻型目录访问协议（LDAP）和 Kerberos/NTLM 身份验证。 Microsoft Entra 域服务与现有的 Microsoft Entra 租户集成，这使用户可以使用其现有凭据登录。 无需在云中部署、管理和修补域控制器即可使用这些域服务，从而更顺畅地将本地资源直接迁移到 Azure。

本文概述了一些常见业务方案，其中Microsoft Entra 域服务提供价值并满足这些需求。

在云中提供标识解决方案的常见方法

将现有工作负荷迁移到云时，目录感知应用程序可能会使用 LDAP 来读取或写入本地 AD DS 目录。 在 Windows Server 上运行的应用程序通常部署在已加入域的虚拟机（VM）上，以便可以使用组策略安全地管理它们。 若要对最终用户进行身份验证，应用程序还可能依赖于 Windows 集成的身份验证，例如 Kerberos 或 NTLM 身份验证。

IT 管理员通常使用以下解决方案之一向在 Azure 中运行的应用程序提供标识服务：

• 在 Azure 中运行的工作负荷与本地 AD DS 环境之间配置站点到站点 VPN 连接。
  • 然后，本地域控制器通过 VPN 连接提供身份验证。
• 使用 Azure 虚拟机（VM）创建副本域控制器，以便从本地扩展 AD DS 域/林。
  • 在 Azure VM 上运行的域控制器提供身份验证，并在本地 AD DS 环境之间复制目录信息。
• 使用在 Azure VM 上运行的域控制器在 Azure 中部署独立的 AD DS 环境。
  • 在 Azure VM 上运行的域控制器提供身份验证，但没有从本地 AD DS 环境复制的目录信息。

通过这些方法，与本地目录的 VPN 连接使应用程序容易受到暂时性网络故障或中断的影响。 如果在 Azure 中使用 VM 部署域控制器，IT 团队必须管理这些 VM，然后保护、修补、监视、备份并对其进行故障排除。

Microsoft Entra 域服务提供了替代方法，无需创建到本地 AD DS 环境的 VPN 连接，或者在 Azure 中运行和管理 VM 以提供标识服务。 作为托管服务，Microsoft Entra 域服务可降低为混合环境和仅限云环境创建集成标识解决方案的复杂性。

Microsoft混合组织的 Entra 域服务

许多组织运行混合基础结构，其中包括云和本地应用程序工作负载。 作为直接迁移策略的一部分迁移到 Azure 的旧版应用程序可以使用传统的 LDAP 连接来提供标识信息。 若要支持此混合基础结构，可将本地 AD DS 环境中的标识信息同步到 Microsoft Entra 租户。 Microsoft Entra 域服务，然后为 Azure 中的这些旧应用程序提供标识源，而无需配置和管理应用程序与本地目录服务的连接。

让我们看看 Litware Corporation（一个在本地和 Azure 资源上运行的混合组织）的示例：

• 需要域服务的应用程序和服务器工作负载部署在 Azure 中的虚拟网络中。
  • 这可能包括作为直接迁移策略的一部分迁移到 Azure 的旧应用程序。
• 若要将标识信息从其本地目录同步到其Microsoft Entra 租户，Litware Corporation 将部署 Microsoft Entra Connect。
  • 同步的标识信息包括用户帐户和组成员身份。
• Litware 的 IT 团队为此租户或对等虚拟网络中的 entra 租户启用 Microsoft Microsoft Entra 域服务。
• 然后，在 Azure 虚拟网络中部署的应用程序和 VM 可以使用 Microsoft Entra 域服务功能，例如域加入、LDAP 读取、LDAP 绑定、NTLM 和 Kerberos 身份验证和组策略。

Microsoft仅限云组织的 Entra 域服务

仅限云Microsoft Entra 租户没有本地标识源。 例如，用户帐户和组成员身份直接在 Microsoft Entra ID 中创建和管理。

现在，让我们看看 Contoso 的示例，这是一个仅限云的组织，它使用标识的 Microsoft Entra ID。 所有用户标识、其凭据和组成员身份在 Microsoft Entra ID 中创建和管理。 Microsoft Entra Connect 没有其他配置，用于同步本地目录中的任何标识信息。

• 需要域服务的应用程序和服务器工作负载部署在 Azure 中的虚拟网络中。
• Contoso 的 IT 团队为此租户或对等互连虚拟网络中的 Microsoft Entra 租户启用 Microsoft Entra 域服务。
• 然后，在 Azure 虚拟网络中部署的应用程序和 VM 可以使用 Microsoft Entra 域服务功能，例如域加入、LDAP 读取、LDAP 绑定、NTLM 和 Kerberos 身份验证和组策略。

安全管理 Azure 虚拟机

若要使用单个 AD 凭据集，可将 Azure 虚拟机（VM）加入 Microsoft Entra 域服务托管域。 此方法可减少凭据管理问题，例如在每个 VM 上维护本地管理员帐户或环境之间的单独帐户和密码。

还可以使用组策略管理和保护已加入托管域的 VM。 所需的安全基线可以应用于 VM，以根据公司安全准则将其锁定。 例如，可以使用组策略管理功能来限制可以在 VM 上启动的应用程序类型。

让我们看看一个常见的示例方案。 当服务器和其他基础结构到达生命周期结束时，Contoso 希望将当前托管在本地的应用程序迁移到云中。 其当前的 IT 标准要求托管公司应用程序的服务器必须已加入域并使用组策略进行管理。

Contoso 的 IT 管理员希望加入 Azure 中部署的 VM 域，以便更轻松地管理，因为用户随后可以使用其公司凭据登录。 加入域后，还可以将 VM 配置为使用组策略对象（GPO）符合所需的安全基线。 Contoso 不想在 Azure 中部署、监视和管理自己的域控制器。

Microsoft Entra 域服务非常适合此用例。 托管域允许你加入域的 VM、使用一组凭据并应用组策略。 由于它是托管域，因此无需自行配置和维护域控制器。

部署说明

以下部署注意事项适用于此示例用例：

• 默认情况下，托管域使用单个平面组织单位（OU）结构。 所有已加入域的 VM 都位于单个 OU 中。 如果需要，可以 创建自定义 OU。
• Microsoft Entra 域服务为每个用户和计算机容器使用一个内置 GPO。 对于其他控件，可以 创建自定义 GPO 并将其定向到自定义 OU。
• Microsoft Entra 域服务支持基本 AD 计算机对象架构。 无法扩展计算机对象的架构。

使用 LDAP 绑定身份验证的直接迁移本地应用程序

作为示例方案，Contoso 具有许多年前从 ISV 购买的本地应用程序。 应用程序目前处于维护模式的 ISV，请求对应用程序的更改非常昂贵。 此应用程序具有基于 Web 的前端，该前端使用 Web 表单收集用户凭据，然后通过执行 LDAP 绑定到本地 AD DS 环境对用户进行身份验证。

Contoso 希望将此应用程序迁移到 Azure。 应用程序应继续 as-is工作，无需更改。 此外，用户应能够使用其现有公司凭据进行身份验证，而无需进行其他培训。 对于运行应用程序的最终用户而言，这应该是透明的。

对于此方案，Microsoft Entra 域服务允许应用程序在身份验证过程中执行 LDAP 绑定。 旧版本地应用程序可以直接迁移到 Azure，并继续无缝地对用户进行身份验证，而无需更改配置或用户体验。

部署说明

以下部署注意事项适用于此示例用例：

• 确保应用程序不需要修改/写入目录。 不支持对托管域的 LDAP 写入访问权限。
• 不能直接针对托管域更改密码。 最终用户可以使用 Microsoft Entra 自助服务密码更改机制 或针对本地目录更改其密码。 然后，这些更改会自动同步并在托管域中可用。

使用 LDAP 读取访问目录的直接迁移本地应用程序

与前面的示例方案一样，假设 Contoso 有一个近十年前开发的本地业务线（LOB）应用程序。 此应用程序可识别目录，旨在使用 LDAP 从 AD DS 读取有关用户的信息/属性。 应用程序不会修改属性或写入目录。

Contoso 希望将此应用程序迁移到 Azure，并停用当前托管此应用程序的老化本地硬件。 无法重写应用程序以使用新式目录 API，例如基于 REST 的Microsoft图形 API。 需要直接迁移选项，以便将应用程序迁移到云中运行，而无需修改代码或重写应用程序。

为了帮助解决这种情况，Microsoft Entra 域服务允许应用程序针对托管域执行 LDAP 读取，以获取所需的属性信息。 应用程序不需要重写，因此直接迁移到 Azure 可让用户继续使用该应用，而无需意识到它运行的位置发生了变化。

部署说明

以下部署注意事项适用于此示例用例：

• 确保应用程序不需要修改/写入目录。 不支持对托管域的 LDAP 写入访问权限。
• 确保应用程序不需要自定义/扩展 Active Directory 架构。 Microsoft Entra 域服务不支持架构扩展。

将本地服务或守护程序应用程序迁移到 Azure

某些应用程序包括多个层，其中一个层需要对后端层（例如数据库）执行经过身份验证的调用。 AD 服务帐户通常用于这些方案。 将应用程序直接迁移到 Azure 时，Microsoft Entra 域服务允许你以相同的方式继续使用服务帐户。 可以选择使用从本地目录同步的同一服务帐户来Microsoft Entra ID 或创建自定义 OU，然后在该 OU 中创建单独的服务帐户。 使用任一方法，应用程序将继续以相同的方式对其他层和服务进行经过身份验证的调用。

在此示例中，Contoso 具有一个自定义生成的软件保管库应用程序，其中包括 Web 前端、SQL 服务器和后端 FTP 服务器。 使用服务帐户的 Windows 集成身份验证对 FTP 服务器的 Web 前端进行身份验证。 Web 前端设置为作为服务帐户运行。 后端服务器配置为授权从 Web 前端的服务帐户进行访问。 Contoso 不想在云中部署和管理自己的域控制器 VM，以便将此应用程序移动到 Azure。

对于此方案，托管 Web 前端、SQL Server 和 FTP 服务器的服务器可以迁移到 Azure VM 并加入托管域。 然后，VM 可以使用其本地目录中的相同服务帐户进行身份验证，该帐户使用 Microsoft Entra Connect 通过 Microsoft Entra ID 进行同步。

部署说明

以下部署注意事项适用于此示例用例：

• 确保应用程序使用用户名和密码进行身份验证。 Microsoft Entra 域服务不支持基于证书或智能卡的身份验证。
• 不能直接针对托管域更改密码。 最终用户可以使用 Microsoft Entra 自助服务密码更改机制 或针对本地目录更改其密码。 然后，这些更改会自动同步并在托管域中可用。

Azure 中的 Windows Server 远程桌面服务部署

可以使用 Microsoft Entra 域服务向 Azure 中部署的远程桌面服务器提供托管域服务。

有关此部署方案的详细信息，请参阅 如何将 Microsoft Entra 域服务与 RDS 部署集成。

已加入域的 HDInsight 群集

可以设置已加入托管域且已启用 Apache Ranger 的 Azure HDInsight 群集。 可以通过 Apache Ranger 创建和应用 Hive 策略，并允许用户（如数据科学家）使用基于 ODBC 的工具（如 Excel 或 Tableau）连接到 Hive。 我们将继续努力将其他工作负载（如 HBase、Spark 和 Storm）添加到已加入域的 HDInsight。

有关此部署方案的详细信息，请参阅 如何配置已加入域的 HDInsight 群集

后续步骤

若要开始， 请创建和配置 Microsoft Entra 域服务托管域。