通过

你当前正在访问 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 ID 用作独立标识解决方案，或将其与 Microsoft Entra 域服务基础结构或本地 Active Directory域服务（AD DS）基础结构集成。

Microsoft Entra ID 为 Azure 和 Microsoft 365 服务提供新式安全标识和访问管理。 可以将 Microsoft Entra ID 用于各种组织和工作负荷。 例如，具有本地 AD DS 基础结构和基于云的工作负载的组织可以使用目录同步和 Microsoft Entra ID。 目录同步可确保本地和云环境共享一组一致的标识、组和角色。 需要旧式身份验证机制的应用程序可能需要云中托管域服务的域服务，并将本地 AD DS 基础结构扩展到 Azure。

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

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

有关详细信息，请参阅 标识决策指南。

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

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

如果使用 AD DS 或域服务，则必须保护域控制器免受未经授权的访问。 域控制器很容易受到攻击，并且应该具有严格的安全控制和隔离与应用程序工作负荷。

在平台管理组中的标识订阅中部署域控制器和关联的组件，例如 Microsoft Entra 连接 服务器。 域控制器不会委派给应用程序团队。 这种隔离允许应用程序所有者使用标识服务，而无需维护这些服务，从而降低标识和访问管理服务受到损害的风险。 标识平台订阅中的资源是云和本地环境的关键安全点。

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

Azure 和本地域（混合标识）

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

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

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

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

混合标识建议

  • 若要确定标识解决方案要求，请记录每个应用程序使用的身份验证提供程序。 使用标识决策指南为组织选择适当的服务。 有关详细信息，请参阅 “比较 Active Directory 与 Microsoft Entra ID”。

  • 可以将域服务用于依赖于域服务并使用较旧的协议的应用程序。 现有 AD DS 域有时支持向后兼容性并允许旧协议，这可能会对安全性产生负面影响。 请考虑使用域服务创建不允许旧协议的新域，而不是扩展本地域。 将新域用作云托管应用程序的目录服务。

  • 将复原能力作为 Azure 中混合标识策略的关键设计要求。 Microsoft Entra ID 是一个 全局冗余的基于云的系统 ，但域服务和 AD DS 不是。 在实现域服务和 AD DS 时，请仔细规划复原能力。 设计任一服务时，请考虑使用多区域部署来确保发生区域性事件时继续执行服务操作。

  • 若要将本地 AD DS 实例扩展到 Azure 并优化部署，请将 Azure 区域合并到 Active Directory 站点设计中。 在 AD DS 站点和服务中为计划部署工作负荷的每个 Azure 区域创建站点。 然后，在 AD DS 站点和服务中为计划在该区域中部署的每个 IP 地址范围创建新的子网对象。 将新子网对象与创建的 AD DS 站点相关联。 此配置可确保域控制器定位器服务将授权和身份验证请求定向到同一 Azure 区域中最近的 AD DS 域控制器。

  • 评估设置来宾、客户或合作伙伴以便他们可以访问资源的方案。 确定这些方案是涉及 Microsoft Entra B2B 还是为客户Microsoft Entra 外部 ID。 有关详细信息，请参阅Microsoft Entra 外部 ID。

  • 请勿使用 Microsoft Entra 应用程序代理 进行 Intranet 访问，因为它会增加用户体验的延迟。 有关详细信息，请参阅 Microsoft Entra 应用程序代理规划和Microsoft Entra 应用程序代理安全注意事项。

  • 考虑可用于将本地 Active Directory与 Azure 集成以满足组织要求的各种方法。

  • 如果Active Directory 联合身份验证服务（AD FS）与 Microsoft Entra ID 联合，则可以使用密码哈希同步作为备份。 AD FS 不支持 Microsoft Entra 无缝单一登录（SSO）。

  • 确定云标识的正确 同步工具 。

  • 如果对使用 AD FS 有要求，请参阅 在 Azure 中部署 AD FS。

  • 如果使用 Microsoft Entra 连接作为同步工具，请考虑在与主要 Microsoft Entra 连接 服务器不同的区域中部署过渡服务器，以便进行灾难恢复。 或者，如果不使用多个区域，请实现可用性区域以实现高可用性。

  • 如果使用 Microsoft Entra Cloud Sync 作为同步工具，请考虑在多个区域中的不同服务器上至少安装 三个代理 ，以便进行灾难恢复。 或者，可以在不同的可用性区域中跨服务器安装代理以实现高可用性。

重要

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

Microsoft Entra ID、域服务和 AD DS

若要实现 Microsoft 目录服务，请让管理员熟悉以下选项：

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

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

  • 部署域服务或将本地环境集成到 Azure 中时，请尽可能将可用性区域与 可用性区域 配合使用以提高可用性。 另请考虑跨多个 Azure 区域进行部署，以提高复原能力。

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

Microsoft Entra ID 和 AD DS 建议

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

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

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

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

  • 使用 Azure 虚拟网络 Manager 强制实施适用于虚拟网络的标准规则。 例如，如果需要 Active Directory 标识服务，可以使用 Azure Policy 或虚拟网络资源标记将登陆区域虚拟网络添加到网络组。 然后，可以使用网络组，仅允许从需要域控制器子网的应用程序访问，并阻止来自其他应用程序的访问。

  • 保护应用于域控制器 VM 和其他标识资源的基于角色的访问控制（RBAC）权限。 在 Azure 控制平面上具有 RBAC 角色分配的 管理员istrators（例如参与者、所有者或虚拟机参与者）可以在 VM 上运行命令。 确保只有经过授权的管理员才能访问标识订阅中的 VM，并且不会从更高的管理组继承过度宽松的角色分配。

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

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

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

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

下一步

登陆区域标识和访问管理