Edit

Share via

Multiple forests with AD DS, Microsoft Entra ID, and Microsoft Entra Domain Services

Microsoft Entra ID
Microsoft Entra
Azure Files
Azure Virtual Desktop

Solution ideas

This article describes a solution idea. Your cloud architect can use this guidance to help visualize the major components for a typical implementation of this architecture. Use this article as a starting point to design a well-architected solution that aligns with your workload's specific requirements.

This solution idea illustrates how to deploy Azure Virtual Desktop rapidly in a minimum viable product (MVP) or a proof of concept (POC) environment with the use of Microsoft Entra Domain Services. Use this idea to both extend on-premises multi-forest Active Directory Domain Services (AD DS) identities to Azure without private connectivity and support legacy authentication.

Potential use cases

This solution idea also applies to mergers and acquisitions, organization rebranding, and multiple on-premises identities requirements.

Architecture

Diagram of Azure Virtual Desktop with Microsoft Entra Domain Services.

Download a Visio file of this architecture.

Dataflow

The following steps show how the data flows in this architecture in the form of identity.

  1. Complex hybrid on-premises Active Directory environments are present, with two or more Active Directory forests. Domains live in separate forests, with distinct User Principal Name (UPN) suffixes. For example, CompanyA.local with UPN suffix CompanyA.com, CompanyB.local with UPN suffix CompanyB.com, and an additional UPN suffix, newcompanyAB.com.
  2. Instead of using customer-managed domain controllers, either on-premises or on Azure (that is, Azure infrastructure as a service (IaaS) domain controllers), the environment uses the two cloud-managed domain controllers provided by Microsoft Entra Domain Services.
  3. Microsoft Entra Connect syncs users from both CompanyA.com and CompanyB.com to the Microsoft Entra tenant, newcompanyAB.onmicrosoft.com. The user account is represented only once in Microsoft Entra ID, and private connectivity isn't used.
  4. Users then sync from Microsoft Entra ID to the managed Microsoft Entra Domain Services as a one-way sync.
  5. A custom and routable Microsoft Entra Domain Services domain name, aadds.newcompanyAB.com, is created. The newcompanyAB.com domain is a registered domain that supports LDAP certificates. We generally recommend that you not use non-routable domain names, such as contoso.local, because it can cause issues with DNS resolution.
  6. The Azure Virtual Desktop session hosts join the Microsoft Entra Domain Services domain controllers.
  7. Host pools and app groups can be created in a separate subscription and spoke virtual network.
  8. Users are assigned to the app groups.
  9. Users sign in by using either the Azure Virtual Desktop application or the web client, with a UPN in a format such as john@companyA.com, jane@companyB.com, or joe@newcompanyAB.com, depending on their configured UPN suffix.
  10. Users are presented with their respective virtual desktops or apps. For example, john@companyA.com is presented with virtual desktops or apps in host pool A, jane@companyB is presented with virtual desktops or apps in host pool B, and joe@newcompanyAB is presented with virtual desktops or apps in host pool AB.
  11. The storage account (Azure Files is used for FSLogix) is joined to the managed domain AD DS. The FSLogix user profiles are created in Azure Files shares.

Note

  • For Group Policy requirements in Microsoft Entra Domain Services, you can install Group Policy Management tools on a Windows Server virtual machine that's joined to Microsoft Entra Domain Services.
  • To extend Group Policy infrastructure for Azure Virtual Desktop from the on-premises domain controllers, you need to manually export and import it to Microsoft Entra Domain Services.

Components

You implement this architecture by using the following technologies:

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal author:

  • Tom Maher | Senior Security and Identity Engineer

Next steps