Create an Active Directory Domain Services (AD DS) resource forest in Azure

This reference architecture shows how to create a separate Active Directory domain in Azure that is trusted by domains in your on-premises AD forest. Deploy this solution.

Secure hybrid network architecture with separate Active Directory domains

Download a Visio file of this architecture.

Active Directory Domain Services (AD DS) stores identity information in a hierarchical structure. The top node in the hierarchical structure is known as a forest. A forest contains domains, and domains contain other types of objects. This reference architecture creates an AD DS forest in Azure with a one-way outgoing trust relationship with an on-premises domain. The forest in Azure contains a domain that does not exist on-premises. Because of the trust relationship, logons made against on-premises domains can be trusted for access to resources in the separate Azure domain.

Typical uses for this architecture include maintaining security separation for objects and identities held in the cloud, and migrating individual domains from on-premises to the cloud.

For additional considerations, see Choose a solution for integrating on-premises Active Directory with Azure.


The architecture has the following components.

  • On-premises network. The on-premises network contains its own Active Directory forest and domains.
  • Active Directory servers. These are domain controllers implementing domain services running as VMs in the cloud. These servers host a forest containing one or more domains, separate from those located on-premises.
  • One-way trust relationship. The example in the diagram shows a one-way trust from the domain in Azure to the on-premises domain. This relationship enables on-premises users to access resources in the domain in Azure, but not the other way around. It is possible to create a two-way trust if cloud users also require access to on-premises resources.
  • Active Directory subnet. The AD DS servers are hosted in a separate subnet. Network security group (NSG) rules protect the AD DS servers and provide a firewall against traffic from unexpected sources.
  • Azure gateway. The Azure gateway provides a connection between the on-premises network and the Azure VNet. This can be a VPN connection or Azure ExpressRoute. For more information, see Connect an on-premises network to Azure using a VPN gateway.


For specific recommendations on implementing Active Directory in Azure, see Extending Active Directory Domain Services (AD DS) to Azure.


The on-premises domains are contained within a different forest from the domains in the cloud. To enable authentication of on-premises users in the cloud, the domains in Azure must trust the logon domain in the on-premises forest. Similarly, if the cloud provides a logon domain for external users, it may be necessary for the on-premises forest to trust the cloud domain.

You can establish trusts at the forest level by creating forest trusts, or at the domain level by creating external trusts. A forest level trust creates a relationship between all domains in two forests. An external domain level trust only creates a relationship between two specified domains. You should only create external domain level trusts between domains in different forests.

Trusts can be unidirectional (one-way) or bidirectional (two-way):

  • A one-way trust enables users in one domain or forest (known as the incoming domain or forest) to access the resources held in another (the outgoing domain or forest).
  • A two-way trust enables users in either domain or forest to access resources held in the other.

The following table summarizes trust configurations for some simple scenarios:

Scenario On-premises trust Cloud trust
On-premises users require access to resources in the cloud, but not vice versa One-way, incoming One-way, outgoing
Users in the cloud require access to resources located on-premises, but not vice versa One-way, outgoing One-way, incoming
Users in the cloud and on-premises both requires access to resources held in the cloud and on-premises Two-way, incoming and outgoing Two-way, incoming and outgoing

Scalability considerations

Active Directory is automatically scalable for domain controllers that are part of the same domain. Requests are distributed across all controllers within a domain. You can add another domain controller, and it synchronizes automatically with the domain. Do not configure a separate load balancer to direct traffic to controllers within the domain. Ensure that all domain controllers have sufficient memory and storage resources to handle the domain database. Make all domain controller VMs the same size.

Availability considerations

Provision at least two domain controllers for each domain. This enables automatic replication between servers. Create an availability set for the VMs acting as Active Directory servers handling each domain. Put at least two servers in this availability set.

Also, consider designating one or more servers in each domain as standby operations masters in case connectivity to a server acting as a flexible single master operation (FSMO) role fails.

Manageability considerations

For information about management and monitoring considerations, see Extending Active Directory to Azure.

For additional information, see Monitoring Active Directory. You can install tools such as Microsoft Systems Center on a monitoring server in the management subnet to help perform these tasks.

Security considerations

Forest level trusts are transitive. If you establish a forest level trust between an on-premises forest and a forest in the cloud, this trust is extended to other new domains created in either forest. If you use domains to provide separation for security purposes, consider creating trusts at the domain level only. Domain level trusts are non-transitive.

For Active Directory-specific security considerations, see the security considerations section in Extending Active Directory to Azure.

DevOps considerations

For DevOps considerations, see DevOps: Extending Active Directory Domain Services (AD DS) to Azure.

Cost considerations

Use the Azure pricing calculator to estimate costs. Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework.

Here are cost considerations for the services used in this architecture.

AD Domain Services

Consider having Active Directory Domain Services as a shared service that is consumed by multiple workloads to lower costs. For more information, see Active Directory Domain Services pricing.

Azure VPN Gateway

The main component of this architecture is the VPN gateway service. You are charged based on the amount of time that the gateway is provisioned and available.

All inbound traffic is free, all outbound traffic is charged. Internet bandwidth costs are applied to VPN outbound traffic.

For more information, see VPN Gateway Pricing.

Deploy the solution

A deployment for this architecture is available on GitHub. Note that the entire deployment can take up to two hours, which includes creating the VPN gateway and running the scripts that configure AD DS.


  1. Clone, fork, or download the zip file for the GitHub repository.

  2. Install Azure CLI 2.0.

  3. Install the Azure building blocks npm package.

    npm install -g @mspnp/azure-building-blocks
  4. From a command prompt, bash prompt, or PowerShell prompt, sign into your Azure account as follows:

    az login

Deploy the simulated on-premises datacenter

  1. Navigate to the identity/adds-forest folder of the GitHub repository.

  2. Open the onprem.json file. Search for instances of adminPassword and Password and add values for the passwords.

  3. Run the following command and wait for the deployment to finish:

    azbb -s <subscription_id> -g <resource group> -l <location> -p onprem.json --deploy

Deploy the Azure VNet

  1. Open the azure.json file. Search for instances of adminPassword and Password and add values for the passwords.

  2. In the same file, search for instances of sharedKey and enter shared keys for the VPN connection.

    "sharedKey": "",
  3. Run the following command and wait for the deployment to finish.

    azbb -s <subscription_id> -g <resource group> -l <location> -p azure.json --deploy

    Deploy to the same resource group as the on-premises VNet.

Test the AD trust relation

  1. Use the Azure portal, navigate to the resource group that you created.

  2. Use the Azure portal to find the VM named ra-adt-mgmt-vm1.

  3. Click Connect to open a remote desktop session to the VM. The username is contoso\testuser, and the password is the one that you specified in the onprem.json parameter file.

  4. From inside your remote desktop session, open another remote desktop session to, which is the IP address of the VM named ra-adtrust-onpremise-ad-vm1. The username is contoso\testuser, and the password is the one that you specified in the azure.json parameter file.

  5. From inside the remote desktop session for ra-adtrust-onpremise-ad-vm1, go to Server Manager and click Tools > Active Directory Domains and Trusts.

  6. In the left pane, right-click on the and select Properties.

  7. Click the Trusts tab. You should see listed as an incoming trust.

Screenshot of Active Directory forest trust dialog

Next steps