你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure 登陆区域中包含 Active Directory 和 Microsoft Entra ID 的混合标识

本文提供有关如何为 Azure 登陆区域设计和实现 Microsoft Entra ID 和混合标识的指导。

在云中运行的组织需要目录服务来管理用户标识和对资源的访问。 Microsoft Entra ID 是一种基于云的标识和访问管理服务,可提供强大的功能来管理用户和组。 可以将它用作独立标识解决方案,或将其与 Microsoft Entra 域服务基础结构或本地 Active Directory域服务(AD DS)基础结构集成。

Microsoft Entra ID 提供适用于许多组织和工作负载的新式安全标识和访问管理,并且是 Azure 和 Microsoft 365 服务的核心。 如果组织具有本地 AD DS 基础结构,则基于云的工作负载可能需要将目录同步到 Microsoft Entra ID,以便在本地和云环境之间实现一组一致的标识、组和角色。 或者,如果应用程序依赖于旧式身份验证机制,则可能需要在云中部署托管域服务。

基于云的标识管理是一个迭代过程。 可以从云原生解决方案开始,其中包含少量用户和初始部署的相应角色,随着迁移的成熟,可能需要使用目录同步或添加云托管域服务作为云部署的一部分来集成标识解决方案。

随着时间的推移,根据工作负荷身份验证要求和其他需求重新访问标识解决方案,例如对组织标识策略和安全要求的更改,或与其他目录服务的集成。 评估 Active Directory 解决方案时,了解 Windows Server 上的 Microsoft Entra ID、域服务和 AD DS 之间的差异。

有关标识策略的帮助,请参阅 标识决策指南

Azure 登陆区域中的标识和访问管理服务

平台团队负责管理标识和访问管理。 标识和访问管理服务是组织安全性的基础。 组织可以使用 Microsoft Entra ID 通过控制管理访问权限来保护平台资源。 此方法可防止平台团队外部的用户对配置或 Microsoft Entra ID 中包含的安全主体进行更改。

使用 AD DS 或域服务的组织还必须保护域控制器免受未经授权的访问。 域控制器对于攻击者来说特别具有吸引力,应该具有严格的安全控制和隔离与应用程序工作负荷。

域控制器和关联的组件(如 Microsoft Entra ID 连接 服务器)部署在平台管理组中的标识订阅中。 域控制器不会委派给应用程序团队。 通过提供这种隔离,应用程序所有者无需管理标识服务即可使用标识服务,并降低标识和访问管理服务遭到入侵的风险。 标识平台订阅中的资源是云和本地环境的关键安全点。

应预配登陆区域,以便应用程序所有者可以根据需要使用 Microsoft Entra ID 或 AD DS 和域服务。 根据所使用的标识解决方案,可能需要根据需要配置其他服务。 例如,可能需要启用和安全到标识虚拟网络的网络连接。 如果使用订阅自动售货过程,请在订阅请求中包含此配置信息。

Azure 和本地域(混合标识)

完全在 Microsoft Entra ID 中创建的用户对象称为 仅限云的帐户。 它们支持新式身份验证和对 Azure 和 Microsoft 365 资源的访问,以及对使用 Windows 10 或 Windows 11 的本地设备的访问权限。

但是,许多组织已经有一些长期存在的 AD DS 目录,这些目录可能与其他系统(例如业务线或企业资源规划(ERP)通过轻型目录访问协议(LDAP)集成。 这些域可能有许多已加入域的计算机和应用程序,这些计算机和应用程序使用 Kerberos 或较旧的 NTLMv2 协议进行身份验证。 在这些环境中,可以将用户对象同步到 Microsoft Entra ID,以便用户可以使用单个标识登录到本地系统和云资源。 将本地和云目录服务统一称为 混合标识。 可以将本地域扩展到 Azure 登陆区域:

  • 若要在云和本地环境中维护单个用户对象,可以通过 Microsoft Entra 连接 或 Microsoft Entra 连接 Sync 将 AD DS 域用户与 Microsoft Entra ID 同步。若要确定环境的建议配置,请参阅 Microsoft Entra 的拓扑连接

  • 若要加入域加入 Windows VM 和其他服务,可以在 Azure 中部署 AD DS 域控制器或域服务。 使用此方法,AD DS 用户可以登录到 Windows 服务器、Azure 文件存储共享和其他使用 Active Directory 作为身份验证源的资源。 还可以使用其他 Active Directory 技术,例如组策略。 有关详细信息,请参阅 Microsoft Entra 域服务的常见部署方案。

混合标识建议

重要

强烈建议迁移到 Microsoft Entra ID,除非有使用 AD FS 的特定要求。 有关详细信息,请参阅用于解除 AD FS 授权和从 AD FS 迁移到 Microsoft Entra ID 的资源。

Microsoft Entra ID、域服务和 AD DS

管理员istrators 应熟悉实现 Microsoft 目录服务的选项:

  • 可以将 AD DS 域控制器作为平台或标识管理员完全控制的 Windows 虚拟机(VM) 部署到 Azure。 此方法是一种基础结构即服务(IaaS)解决方案。 可以将域控制器加入现有 Active Directory 域,也可以托管与现有本地域具有可选信任关系的新域。 有关详细信息,请参阅 Azure 登陆区域中的 Azure 虚拟机基线体系结构。

  • 域服务 是一种 Azure 托管服务,可用于创建 Azure 中托管的新托管 Active Directory 域。 该域可以与现有域建立信任关系,并且可以从 Microsoft Entra ID 同步标识。 管理员istrators 无权直接访问域控制器,并且不负责修补和其他维护操作。

  • 将域服务或将本地环境集成到 Azure 中时,请将位置与 可用性区域 配合使用以提高可用性。

配置 AD DS 或域服务后,可以使用与本地计算机相同的方法加入 Azure VM 和文件共享。 有关详细信息,请参阅 比较基于 Microsoft 目录的服务

Microsoft Entra ID 和 AD DS 建议

  • 若要通过 Microsoft Entra ID 远程访问使用本地身份验证的应用程序,请使用 Microsoft Entra 应用程序代理。 此功能提供对本地 Web 应用程序的安全远程访问。 它不需要 VPN,也不需要对网络基础结构进行任何更改。 但是,它部署为单个实例到 Microsoft Entra ID 中,因此应用程序所有者和平台或标识团队必须进行协作以确保应用程序配置正确。

  • 评估 Windows Server 和域服务上 AD DS 的工作负载兼容性。 有关详细信息,请参阅 常见用例和方案

  • 将域控制器 VM 或域服务副本 (replica)集部署到平台管理组中的标识平台订阅中。

  • 保护包含域控制器的虚拟网络。 通过将 AD DS 服务器置于具有网络安全组(NSG)的独立子网中来防止与这些系统建立直接 Internet 连接,从而提供防火墙功能。 使用域控制器进行身份验证的资源必须具有到域控制器子网的网络路由。 仅对需要访问标识订阅中的服务的应用程序启用网络路由。 有关详细信息,请参阅在 Azure 虚拟网络中部署 AD DS

    • 使用 Azure 虚拟网络 Manager 强制实施适用于虚拟网络的标准规则。 例如,如果需要 Active Directory 标识服务,可以使用 Azure Policy 或虚拟网络资源标记将登陆区域虚拟网络添加到网络组。 然后,可以使用网络组,仅允许从需要域控制器子网的应用程序访问,并阻止来自其他应用程序的访问。
  • 保护适用于域控制器虚拟机和其他标识资源的基于角色的访问控制(RBAC)权限。 在 Azure 控制平面(例如参与者、所有者或虚拟机参与者)上具有 RBAC 角色分配的管理员管理员可以在虚拟机上运行命令。 确保只有经过授权的管理员才能访问标识订阅中的虚拟机,并且不会从更高的管理组继承过度宽松的角色分配。

  • 在多区域组织中,将域服务部署到托管核心平台组件的区域中。 只能将域服务部署到单个订阅中。 可以通过在与主虚拟网络对等互连的单独虚拟网络中添加多达四个副本 (replica)集,将域服务扩展到更多区域。 为了最大程度地减少延迟,请将核心应用程序与副本 (replica)集的虚拟网络保持接近或位于同一区域中。

  • 在 Azure 中部署 AD DS 域控制器时,请跨 可用性区域 部署它们以提高复原能力。 有关详细信息,请参阅 在可用性区域中 创建 VM 并将 VM 迁移到可用性区域

  • 身份验证可以在云端和本地进行,也可以仅在本地进行。 在标识规划过程中,探索 Microsoft Entra ID 的身份验证方法。

  • 如果 Windows 用户要求 Kerberos 用于Azure 文件存储文件共享,请考虑对 Microsoft Entra ID 使用 Kerberos 身份验证,而不是在云中部署域控制器。

后续步骤