Overview

The process of deploying an Active Directory domain controller on an Azure VM is similar to the process of deploying a domain controller in an on-premises environment. One primary difference is that when you deploy a domain controller in Azure, you must place the Active Directory database on the data disk of an Azure VM to avoid potential database corruption. Database corruption might occur because of the read and write cache settings of the operating system disk on the Azure VM. Azure provides multiple options for implementing directory and identity services using AD DS in Azure. The different considerations and requirements are based on the deployment scenario that you select.

Deploy AD DS only on an Azure VM

This scenario involves creating a VNet, but doesn’t require cross-premises connectivity. Typically, this deployment starts with a new forest and all the domain controllers run only on Azure VMs. In this scenario, you should consider setting static IP addresses for domain controllers. This scenario is common for:

  • Apps that depend on Kerberos authentication, but don’t have any requirements that are related to on-premises directory services.
  • Greenfield deployments where there’s no existing on-premises AD DS environment.

Deploy AD DS in both an on-premises infrastructure and on an Azure VM

This scenario is common for apps that are LDAP–aware and that support Windows-integrated authentication. This scenario requires creating a VNet with cross-premises connectivity and proper IP address allocation for VMs that are running in the cloud.

The primary goal of this scenario is to optimize the cost of a solution, considering that inbound traffic (ingress) is free but not outbound traffic (egress). This is because systems and applications in Azure would refer to the AD DS domain controllers in Azure for authentication, LDAP lookups, and name server resolution. This scenario provides faster performance and a better sign-in experience for users who access the apps by authenticating to the cloud-based domain controllers.

When deploying AD DS in an on-premises environment and on an Azure VM, there are multiple options that Azure supports, as described in the following table.

Deployment option Description
Deploy an additional AD DS domain controller to an Azure VM If your application is hosted partly on-premises and partly in Azure, it may be more efficient to replicate AD DS in Azure. This can reduce the latency caused by sending authentication requests from the cloud back to AD DS running on-premises. This architecture is commonly used when the on-premises network and the Azure virtual network are connected by a virtual private network (VPN) or ExpressRoute connection. This architecture also supports bidirectional replication, meaning you can make changes either on-premises or in the cloud, and both sources will be kept consistent. Typical uses for this architecture include hybrid applications in which functionality is distributed between on-premises and Azure, and applications and services that perform authentication using Active Directory.
Deploy a separate Active Directory forest or domain to Azure that is trusted by domains in your on-premises AD forest 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 includes creating an AD DS domain in Azure that is a member of the same AD forest as the on-premises domain. In this scenario, creating a trust relationship between the different domains is not required because domains in the same forest inherently (automatically) trust each other. Alternatively, you can create an AD DS forest in Azure with a one-way outgoing or a two-way bidirectional trust relationship with an on-premises domain. In this scenario, the forest in Azure contains a domain that doesn’t exist on-premises. Because of the trust relationship, sign-ins 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 kept in the cloud, and migrating individual domains from on-premises to the cloud.

Deploy and configure Active Directory Domain Services domain controllers in Azure VMs

When planning to deploy AD domain controllers in Azure, there are some important things for Contoso IT staff to consider: networking, AD DS sites, and trust relationships.

Deployment considerations

  • Network recommendations. Configure the VM network interface (NIC) for each AD DS server with a static, private IP address for full DNS support. You must also configure the Active Directory subnet network security group (NSG) rules to permit incoming traffic from on-premises and outgoing traffic to on-premises.

Because of security concerns, you should NOT configure the VM NIC for any domain controller with a public IP address.

  • Inter-site connectivity. A key design element is inter-site connectivity between your on-premises environment and Azure. To ensure that Azure-hosted VMs can communicate with internal domain controllers, you must set up a VNet with site-to-site connectivity back to your on-premises network, or you must use ExpressRoute. Cross-premises connectivity requires a VPN server that supports incoming connections from Azure, a static public IP address on your internet connection, and a dynamic gateway for the VNet to establish connectivity with the on-premises infrastructure.

  • Active Directory sites. You must configure sites in AD DS so that you can control replication traffic between the on-premises and Azure-based domain controllers. Knowledge Consistency Checker (KCC) controls the replication process, with intra-site replication relying on a bidirectional ring topology that assumes connections with high bandwidth and that are permanently available. Replication traffic is not scheduled, and updates are optimized for speed. By contrast, inter-site replication uses a least-cost spanning tree topology with a default three-hour interval that can be restricted to certain times of the day or week.

  • Trust relationship. A trust relationship is required in the scenario where your on-premises AD domain is contained within a different AD forest from your AD domain in Azure. To enable authentication of on-premises users in Azure, the domain in Azure must trust the logon domain in the on-premises forest. Similarly, if Azure provides a logon domain for external users, it might 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 transitive trust relationship between all the domains in the two forests. Conversely, an external domain level trust only creates a non-transitive trust relationship between two specified domains. 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 in another forest (known as the outgoing domain or forest).
    • A two-way trust enables users in either domain or forest to access resources in the other.

You should only create external domain-level trusts between domains in different forests.

Scenario On-premises trust Azure trust
On-premises users require access to resources in Azure, but not vice versa One-way, incoming One-way, outgoing
Users in Azure require access to resources located on-premises, but not vice versa One-way, outgoing One-way, incoming
Users in Azure and on-premises both require access to resources in Azure and on-premises Two-way, incoming and outgoing Two-way, incoming and outgoing
  • Read-only domain controllers (RODCs). This arrangement reduces the amount of egress traffic and the resulting Azure service charges. RODCs do not work in situations where a service or application needs write access to AD DS.

  • Flexible single master operations (FSMO) roles and global catalog placement. Regardless of your domain topology, you should configure all of your Azure-based domain controllers as global catalog servers. This arrangement prevents global catalog lookups and evaluations of universal group memberships from having to traverse from Azure to the on-premises global catalog, thus incurring egress network traffic charges. If Azure domain controllers are in a separate forest, its operation masters need to be hosted in Azure. If your Azure domain controllers are in a separate domain, you will need to configure the domains primary domain emulator master, relative ID master, and infrastructure master on those VMs in Azure.

You might consider designating one or more servers in each domain as standby operations masters in case connectivity to a server acting as a FSMO role fails.

  • Availability. You should provision at least two AD domain controllers for each domain. This enables automatic replication between servers. You should also consider creating an availability set for the AD domain controller VMs and configure at least two servers for each availability set.

Because requests to AD domain controllers are distributed across all domain controllers within a domain, you don’t need to configure a load balancer to direct traffic to controllers within the domain.

  • Back up and restore. Use the same procedure as for an on-premises domain controller to back up the system state on a domain controller. You should avoid copying, or cloning, the virtual hard drive as this could introduce an update sequence number rollback effect. This might also prevent the database from starting as the AD DS database file on the virtual hard drive might not be in a consistent state when it’s copied.

  • Management. You should not shut down an AD domain controller VM using the Azure portal. Instead, you should shut down and restart from the guest (OS). Shutting down the AD domain controller through the Azure portal causes the Azure VM to be deallocated, which resets both the Active Directory repository’s VM-GenerationID and invocationID. This discards the AD DS relative identifier (RID) pool and marks the sysvol folder as nonauthoritative. It might also require reconfiguration of the domain controller.

  • Monitoring. Monitor the resources of the domain controller VMs and the AD DS services, and create a plan to quickly correct any problems. For example, you can use Azure Monitor to analyze the performance of your infrastructure, which enables you to monitor and diagnose networking issues without signing in to your VMs. You can use Application Insights to provide metrics and logs to verify the state of your infrastructure.

The requirements for creating a domain controller on an Azure VM as a replica domain controller or in a new forest are similar. Both scenarios require a storage account for creating the OS and data disk for the VM, and as a best practice you should configure the domain controller with static IP addresses. However, in the first scenario, you must configure a VNet for cross-premises connectivity by using site-to-site VPN or ExpressRoute.

Install a replica Active Directory domain controller in an Azure VM

Having completed the planning process, IT staff at Contoso must be ready to perform one of the following procedures:

  • Deploy an additional AD DS domain controller to an Azure VM.
  • Deploy a separate AD forest or domain to Azure that is trusted by domains in your on-premises AD forest.

In this unit, you’ll learn how to implement a replica domain controller on an Azure VM. You’ll need to be able to perform the following tasks to complete this procedure:

  • Create an Azure VNet with cross-premises connectivity.
  • Create a storage account.
  • Create a VM and assign an IP address.
  • Install the AD DS and DNS roles on an Azure VM.

Create an Azure virtual network with a site-to-site VPN

When you create an Azure VNet for a site-to-site VPN, you must specify:

  • The name of the virtual network.
  • The DNS server addresses that point to your on-premises DNS servers.
  • Site-to-site VPN connectivity with the on-premises infrastructure. This involves creating a dynamic gateway with a public IP address for establishing a site-to-site VPN tunnel with the on-premises VPN device.
  • The local network that defines the IP address assignment for the on-premises network.
  • Virtual network address spaces that define the IP address range for VMs that run in Azure.

The address range cannot overlap the address space for your on-premises network.

Additionally, you must configure an on-premises VPN device with a public IP address and the configuration rules that will connect to the previously created dynamic gateway. You can use ExpressRoute instead of site-to-site VPN for cross-premises connectivity. With ExpressRoute, you can extend your on-premises networks into Azure over a dedicated private connection that is provided by a connectivity provider. ExpressRoute connections use dedicated lines instead of a public internet connection and provide faster speeds, more reliability, and lower latency.

To create and provision an ExpressRoute circuit, perform the following high-level steps:

  1. In Windows PowerShell, import the ExpressRoute module by running the following command:
Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\ExpressRoute\ExpressRoute.psd1'
  1. Obtain the supported list of providers, locations, and bandwidths by running the following command:
Get-AzureDedicatedCircuitServiceProvider
  1. Create an ExpressRoute circuit by running the following command:
New-AzureDedicatedCircuit -CircuitName $CircuitName -ServiceProviderName $ServiceProvider -Bandwidth $Bandwidth -Location $Location -sku Premium - BillingType MeteredData
  1. Send the service key to your connectivity provider for provisioning.
  2. Create your routing configuration.
  3. Link a virtual network to the ExpressRoute circuit.

Create a storage account

  1. Use the following procedure to create a storage account:
  2. Sign in to the Azure portal.
  3. Search for and select Storage accounts, and then select Add.
  4. Select the Azure subscription and resource group that you want to use for the new storage account.
  5. Enter a name for your storage account, and select a location.
  6. Select a performance category.
  7. Select the account type.
  8. Specify the type of storage replication.
  9. Choose whether to enable secure transfer.
  10. Select Review + Create.

Image alt

The following table describes the configurable options when creating a storage account.

Option Explanation
Performance Standard storage accounts use magnetic drives and are the least expensive. Use for applications that require bulk storage or where data is accessed infrequently. Premium storage accounts use solid state drives (SSD) and offer consistent, low-latency performance. For this scenario, choose Premium.
Account kind General purpose storage accounts provide storage for blobs, files, tables, and queues in a unified account. Choose StorageV2 (general purpose v2) for this scenario.
Replication The data in your Azure storage account is always replicated to ensure durability and high availability. Microsoft recommends using zone-redundant storage (ZRS), geo-redundant storage (GRS), or geo-zone-redundant storage (GZRS) for this scenario.
Access tier The Hot Access Tier is ideal for frequently accessed data, and should be selected for this scenario.

Create a VM and assign an IP address

You must create a VM with a static IP address from the range in the VNet scope. You can use the Azure portal or the Azure module for Windows PowerShell to create a VM with the Windows Server operating system, and then attach one or more data disks for storing the database, logs, and SYSVOL.

To create a VM with a static IP configuration, you can use the following procedure in Azure CLI:

  1. Sign in to the Azure CLI.
  2. Run the following command to create a NIC, replacing the resource group, name, location, subnet, IP address, and VNet name with values appropriate to your organization and scenario:
az network nic create \
--resource-group ContosoResourceGroup \
--name ContosoNIC4 \
--location eastus \
--subnet ContosoVM1Subnet \
--private-ip-address 10.0.0.10 \
--vnet-name ContosoVM1VNET
  1. Create a VM using the following command, replacing the resource group, name, location, and nics values with values appropriate to your organization and scenario:
az vm create \
--resource-group ContosoResourceGroup \
--name ContosoDC01 \
--location eastus \
--image Win2019Datacenter \
--admin-username adminuser \
--nics ContosoNIC4
  1. Start the VM. Image alt

Install and configure DNS and AD DS server roles

To promote the server to a domain controller, you must add and then configure AD DS. You can add the AD DS role by using Add Roles and Features in Server Manager or by using the following Windows PowerShell cmdlet:

Add-WindowsFeature ADDS-Domain-Controller

AD DS setup allows you to automatically add the DNS role to the server. You can also install it later by using Add Roles and Features in Server Manager or by running the following Windows PowerShell cmdlet:

Add-WindowsFeature DNS

Place the Active Directory database on a data drive with caching turned off.

Install a new Active Directory forest on an Azure VNet

Having completed the planning process, you must perform one of the following procedures:

  • Deploy an additional AD DS domain controller to an Azure VM.
  • Deploy a separate AD forest or domain to Azure that is trusted by domains in your on-premises AD forest. In this unit, you’ll learn how to implement a new Active Directory forest in Azure.

Create a new Active Directory forest in Azure

The requirements to implement a new Active Directory forest in Azure are similar to that needed to create a replica domain controller. The main difference is that you need to create an Azure virtual network, but there are no requirements for cross-premises connectivity. Furthermore, the new Active Directory forest most likely will be the single Active Directory site, and in that case, all domain controllers should be global catalogs.

To implement a new Active Directory forest in Azure, perform the following procedure:

  1. Create an Azure VNet by specifying:
  • The name of the virtual network.
  • The DNS server addresses that point to the IP address of your new domain controller.
  • Virtual Network Address Spaces that define the IP address range for the VMs that run in Azure.
  1. Create the VMs to run both the domain controller and DNS server roles, using the procedure outlined in the preceding unit.
  2. Install the AD DS and DNS server roles, using the procedure outlined in the preceding unit.

At the end of both processes, to increase security, you can implement access control on the endpoints, or you can design network security groups to limit and control access on domain controllers.