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 团队在此或对等的虚拟网络中为 Microsoft Entra 租户启用了 Microsoft Entra 域服务。
• 然后，Azure虚拟网络中部署的应用程序和 VM 可以使用域加入、LDAP 读取、LDAP 绑定、NTLM 和 Kerberos 身份验证和组策略等Microsoft Entra域服务功能。

专用于云端的 Microsoft Entra 域服务

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

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

对于仅在云中运行且无本地同步的组织，

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

安全管理Azure虚拟机

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

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

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

Contoso 的 IT 管理员希望将部署在 Azure 中的 VM 加入域，这样能更方便地进行管理，因为用户可以使用他们的公司凭据登录。 将虚拟机（VM）加入域后，还可以通过组策略对象（GPO）来配置它们，从而符合所需的安全基线。 Contoso 不想在Azure中部署、监视和管理自己的域控制器。

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

部署说明

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

• 默认情况下，托管域使用单个平面组织单位（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 Graph 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域服务托管域。