检查 Microsoft Entra 域服务

已完成

对于如今的大多数组织,业务线 (LOB) 应用程序部署在作为域成员的计算机和设备上。 这些组织使用基于 AD DS 的凭据进行身份验证,并且组策略对这些凭据进行管理。 考虑将这些应用移动到 Azure 中运行时,一个关键问题是如何为这些应用提供身份验证服务。 为了满足此需求,可以选择在本地基础结构和 Azure IaaS 之间实现站点到站点虚拟专用网 (VPN),也可以从本地 AD DS 部署副本域控制器作为 Azure 中的虚拟机 (VM)。 这些方法可能会产生额外的成本和管理工作量。 此外,这两种方法之间的区别是:在第一个方法中,身份验证流量需要跨越 VPN;而在第二个方法中,复制流量需要跨越 VPN,而身份验证流量保留在云中。

Microsoft 提供了 Microsoft Entra 域服务来作为这些方法的替代方法。 此服务作为 Microsoft Entra ID P1 或 P2 层的一部分运行,它向 Microsoft Entra 租户提供组策略管理、域加入和 Kerberos 身份验证等域服务。 这些服务与本地部署的 AD DS 完全兼容,因此使用它们时无需在云中部署和管理其他域控制器。

Diagram that shows the Microsoft Entra Domain Services Overview.

由于 Microsoft Entra ID 可以与本地 AD DS 集成,因此在实现 Microsoft Entra Connect 时,用户可以在本地 AD DS 和 Microsoft Entra 域服务中使用组织凭据。 即使未在本地部署 AD DS,也可以选择使用 Microsoft Entra 域服务作为仅限云的服务。 这样你便有了与本地部署的 AD DS 类似的功能,而无需在本地或云中部署单个域控制器。 例如,组织可以选择创建 Microsoft Entra 租户并启用 Microsoft Entra 域服务,然后在其本地资源和 Microsoft Entra 租户之间部署虚拟网络。 可为此虚拟网络启用 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 筛选器或安全组筛选功能。

通过使用 Microsoft Entra 域服务,可以自由地将使用 LDAP、NTLM 或 Kerberos 协议的应用程序从本地基础结构迁移到云。 还可以在 VM 上使用 Microsoft SQL Server 或 Microsoft SharePoint Server 等应用程序,或者在 Azure IaaS 中部署这些应用程序,而无需使用云中的域控制器或与本地基础结构连接的 VPN。

可以使用 Azure 门户启用 Microsoft Entra 域服务。 此服务根据目录的大小按小时收费。