解决方案构想
本文介绍了一种解决方案构想。 云架构师可以通过本指南来帮助可视化此体系结构的典型实现的主要组件。 以本文为起点，设计一个符合工作负荷特定要求的架构合理的解决方案。
此解决方案构想说明了如何使用 Microsoft Entra 域服务在最小化可行产品 (MVP) 或概念证明 (POC) 环境中快速部署 Azure 虚拟桌面。 利用这一概念，既可无需专用连接就能将内部部署的多林 Active Directory 域服务 (AD DS) 身份扩展到 Azure，又可支持旧式身份验证。
可能的用例
此解决方案概念还适用于合并和收购、组织品牌重塑和多个本地标识要求。
体系结构
下载此体系结构的 Visio 文件。
数据流
以下步骤显示数据如何在此体系结构中以标识的形式流动。
- 复杂的混合本地 Active Directory 环境具有两个或更多 Active Directory 林。 域在单独的林中，具有不同的用户主体名称 (UPN) 后缀。 例如，带有 UPN 后缀 CompanyA.com 的 CompanyA.local，带有 UPN 后缀 CompanyB.com 的 CompanyB.local，以及一个附加的 UPN 后缀 newcompanyAB.com。
- 该环境使用 Microsoft Entra 域服务提供的两个云托管域控制器，而不是使用客户托管的域控制器（无论是本地还是在 Azure 上；若是后者，则为 Azure 基础结构即服务 [IaaS] 域控制器）。
- Microsoft Entra Connect 会将 CompanyA.com 和 CompanyB.com 中的用户同步到 Microsoft Entra 租户 (newcompanyAB.onmicrosoft.com)。 Microsoft Entra ID 中只表示用户帐户一次，不使用专用连接。
- 然后，用户以单向同步的方式从 Microsoft Entra ID 同步到托管的 Microsoft Entra 域服务。
- 将创建一个自定义且可路由的 Microsoft Entra 域服务 (aadds.newcompanyAB.com)。 newcompanyAB.com 域是已注册的域，可支持 LDAP 证书。 通常建议不要使用不可路由的域名（例如 contoso.local），因为它可能会导致 DNS 解析出现问题。
- Azure 虚拟桌面会话主机加入 Microsoft Entra 域服务域控制器。
- 可在单独的订阅和分支虚拟网络中创建主机池和应用组。
- 用户被分配到应用组。
- 用户使用 Azure 虚拟桌面应用程序或 Web 客户端 登录，并使用 john@companyA.com、jane@companyB.com 或 joe@newcompanyAB.com 等格式的 UPN，具体取决于其配置的 UPN 后缀。
- 用户会看到各自的虚拟桌面或应用。 例如，john@companyA.com 将看到主机池 A 中的虚拟桌面或应用，jane@companyB 将看到主机池 B 中的虚拟桌面或应用，而 joe@newcompanyAB 将看到主机池 AB 中的虚拟桌面或应用。
- 存储帐户（Azure 文件存储用于 FSLogix）会加入托管域 AD DS。 FSLogix 用户配置文件是在 Azure 文件存储共享中创建的。
注意
- 对于 Microsoft Entra 域服务中的组策略要求，可在已加入 Microsoft Entra 域服务的 Windows Server 虚拟机上安装组策略管理工具。
- 要从本地域控制器扩展 Azure 虚拟桌面的组策略基础结构，需要手动将其导出并导入到 Microsoft Entra 域服务。
组件
可以使用以下技术实现此体系结构：
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
首席作者：
- Tom Maher | 高级安全和标识工程师
后续步骤
- 使用 Azure 虚拟桌面的多个 Active Directory 林体系结构
- 适用于企业的 Azure 虚拟桌面
- Microsoft Entra Connect 拓扑
- 比较不同的标识选项
- Azure 虚拟桌面文档