许多组织希望利用 Azure 虚拟桌面创建具有多个本地 Active Directory 林的环境。
本文扩展了企业级 Azure 虚拟桌面一文中介绍的体系结构。 它旨在帮助你了解如何使用 Microsoft Entra Connect 将用户从本地 Active Directory 域服务 (AD DS) 同步到 Microsoft Entra ID,从而集成多个域和 Azure 虚拟桌面。
体系结构
下载此体系结构的 Visio 文件。
数据流
在此体系结构中,标识流的工作方式如下:
- Microsoft Entra Connect 会将 CompanyA.com 和 CompanyB.com 中的用户同步到 Microsoft Entra 租户 (NewCompanyAB.onmicrosoft.com)。
- 在各自的订阅和分支虚拟网络中创建主机池、工作区和应用组。
- 用户被分配到应用组。
- 主机池中的 Azure 虚拟桌面会话主机使用 Azure 中的域控制器 (DC) 加入域 CompanyA.com 和 CompanyB.com。
- 用户使用 Azure 虚拟桌面应用程序或 Web 客户端 登录,并使用 user@NewCompanyA.com、user@CompanyB.com 或 user@NewCompanyAB.com 等格式的用户主体名称 (UPN),具体取决于其配置的 UPN 后缀。
- 用户会看到各自的虚拟桌面或应用程序。 例如,CompanyA 中的用户可看到工作区 A 主机池 1 或 2 中的虚拟桌面或应用程序。
- 在相应存储帐户的 Azure 文件存储共享中创建 FSLogix 用户配置文件。
- 从本地同步的组策略对象 (GPO) 应用于用户和 Azure 虚拟桌面会话主机。
组件
此体系结构使用与企业级 Azure 虚拟桌面体系结构中列出的相同组件。
此外,此体系结构使用以下组件:
暂存模式下的 Microsoft Entra Connect:适用于 Microsoft Entra Connect 拓扑的暂存服务器为 Microsoft Entra Connect 实例提供额外的冗余。
Azure 订阅、Azure 虚拟桌面工作区和主机池:你可以使用多个订阅、Azure 虚拟桌面工作区和主机池来满足管理边界和业务需求。
方案详细信息
此体系结构示意图示包含以下元素的典型方案:
- Microsoft Entra 租户可用于名为 NewCompanyAB.onmicrosoft.com 的新公司。
- Microsoft Entra Connect 可将用户从本地 AD DS 同步到 Microsoft Entra ID。
- 公司 A 和公司 B 都有单独的 Azure 订阅。 在图中,这两家还有一个称为“订阅 1”的共享服务订阅。
- 使用共享服务中心虚拟网络实现了 Azure 中心辐射型体系结构。
- 复杂的混合本地 Active Directory 环境具有两个或更多 Active Directory 林。 域位于不同的林中,每个域都有不同的 UPN 后缀。 例如,带有 UPN 后缀 CompanyA.com 的 CompanyA.local,带有 UPN 后缀 CompanyB.com 的 CompanyB.local,以及一个附加的 UPN 后缀 NewCompanyAB.com。
- 这两个林的域控制器位于本地和 Azure 中。
- Azure 中存在用于 CompanyA.com、CompanyB.com 和 NewCompanyAB.com 的已验证的域。
- 使用 GPO 和旧式身份验证,例如 Kerberos、NTLM(Windows 新技术 LAN 管理器) 和 LDAP(轻量级目录访问协议)。
- 对于仍依赖于本地基础结构的 Azure 环境,在本地和 Azure 之间设置了专用连接(站点到站点 VPN 或 Azure ExpressRoute)。
- Azure 虚拟桌面环境由每个业务部门的 Azure 虚拟桌面工作区和每个工作区的两个主机池组成。
- Azure 虚拟桌面会话主机已加入到 Azure 中的域控制器。 即 CompanyA 会话主机加入 CompanyA.local 域,CompanyB 会话主机加入 CompanyB.local 域。
- Azure 存储帐户可以使用适用于 FSLogix 配置文件的 Azure 文件。 将为每个公司域(即 CompanyA.local 和 CompanyB.local)创建一个帐户,并将该帐户加入到相应的域。
注意
Active Directory 域服务是许多混合环境中的自托管本地组件,而 Microsoft Entra 域服务提供托管域服务,这些服务具有一部分完全兼容的传统 AD DS 功能,例如域加入、组策略、LDAP 和 Kerberos/NTLM 身份验证。 有关这些组件的详细比较,请参阅比较自托管的 AD DS、Microsoft Entra ID 和托管的 Microsoft Entra 域服务。
解决方案构想使用 Microsoft Entra 域服务的多个 Azure 虚拟桌面林以云托管的 Microsoft Entra 域服务为例讨论了此体系结构。
可能的用例
以下是此体系结构的一些相关用例:
- 合并和收购、组织品牌重塑和多个本地标识
- 复杂的本地 Active Directory 环境(多林、多域、组策略 (GPO) 要求和旧式身份验证)
- 具有 Azure 虚拟桌面的本地 GPO 基础结构
注意事项
基于此体系结构设计工作负荷时,请牢记以下构想。
组策略对象
若要扩展 Azure 虚拟桌面的 GPO 基础结构,本地域控制器应同步到 Azure 基础结构即服务 (IaaS) 域控制器。
将 GPO 基础结构扩展到 Azure IaaS 域控制器需要专用连接。
网络和连接性
域控制器是共享组件,因此需要将其部署在此中心辐射型体系结构中的共享服务中心虚拟网络。
Azure 虚拟桌面会话主机通过其各自的中心/辐射虚拟网络对等互连加入 Azure 中的域控制器。
Azure 存储
以下设计注意事项适用于用户配置文件容器、云缓存容器和 MSIX 包:
在此方案中,可以使用 Azure 文件存储和 Azure NetApp 文件。 根据预期性能和成本等因素选择合适的解决方案。
Azure 存储帐户和 Azure NetApp 文件一次只能加入一个 AD DS。 在这些情况下,需要多个 Azure 存储帐户或 Azure NetApp 文件实例。
Microsoft Entra ID
在用户加入多个本地 Active Directory 林的方案中,只有一个 Microsoft Entra Connect 同步服务器可以连接到 Microsoft Entra 租户。 这种情况的一个例外是在暂存模式下使用 Microsoft Entra Connect 服务器。
支持以下标识拓扑:
- 多个本地 Active Directory 林。
- 一个或多个资源林信任所有帐户林。
- 完整网格拓扑允许用户和资源位于任何林中。 通常,林之间建立了双向信任。
有关更多详细信息,请参阅“Microsoft Entra Connect 拓扑”中的“暂存服务器”一节。
作者
本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。
首席作者:
- Tom Maher | 高级安全和标识工程师
后续步骤
有关详细信息,请参阅以下文章:
- Microsoft Entra Connect 拓扑
- 比较不同的标识选项:自托管的 Active Directory 域服务 (AD DS)、Microsoft Entra ID 和 Microsoft Entra 域服务
- Azure 虚拟桌面文档