Using Azure Active Directory Domain Services with ARM VNets

It’s been a while since my last post – a combination of extended leave and being busy I guess. Even so, I’m back to helping Microsoft customers and hope to share what I learn from those experiences through this blog. So onto the topic of the day …

Imagine you’ve made an effort moving your Azure resources away from Azure Service Manager (classic) and onto Azure Resource Manager (ARM). Everything is going well and you decide there’s a need to utilize Azure Active Directory Domain Services (AAD DS).

Note: If you’re not sure what Azure Active Directory Domain Services is all about, head over to the documentation pages here - – short story is that your Azure Active Directory tenant is presented to a VNet of your choosing as a pair of Domain Controllers allowing Azure IaaS hosted VMs to perform domain joins, LDAP lookups etc..

Problem: At the time of writing, AAD Domain Services doesn’t support an ARM VNet – only classic VNets are supported. ARM VNet support is coming but it’s not there yet.

Solution: Create a site-to-site VPN between a classic VNet and the ARM VNet using the AAD DS IP addresses as the DNS servers for the ARM VNet


I’ll keep this walkthrough pretty brief. I don’t want to repeat content that is already out there and readily available – just tie it together in a way that makes it easy for you.

I have a resource group and VNet using ARM as follows – Blog-ARM-VNet is configured with address space and a subnet called Subnet-0, address range


It’s important to note that for steps coming later, a gateway subnet should also be created. In my case, the Blog-ARM-VNet appears as


I also have a classic VNet called Blog-ASM-VNet with adderess space and a subnet called Subnet-1, address range


Now I hook them together with a site-to-site VPN. The steps to do this are covered really well over here - After stepping through this guide my classic and ARM VNets are connected


The next thing I want to do is enabled Azure Active Directory Domain Services on my classic VNet. The steps to do this are covered really well at After following this guide, I have


Notice the two IP addresses assigned to AAD DS. I’ll add these as DNS servers to my ARM VNet


After I add a virtual machine to my ARM VNet and connect to it, I can use and treat AAD DS just as if I had Azure IaaS VMs deployed as Domain Controllers (well there are differences but you can read about those at the documentation link posted above)






Comments (6)
  1. Lester W says:

    What is the best practice here if I now want to have a site-to-site VPN to my on-premise network AND I wish my on-premise machines to be able to see the AAD DS (in the CLassic VNET) as well as the VMs in the ARM VNET?

    1. Mark Renoden says:

      To my understanding, AAD DS is not intended to be used by on-premises resources. It’s specifically for vNets that don’t have connectivity to on-premises where traditional DCs reside.

  2. Lester W says:

    By the way, you can also use a VNET-to-VNET Peering between the Classic and ARM VNET.

      1. MI_CHI says:

        Looking at the peering link Lester, it seems you can’t use gateway transit between deployment models, so I was forced to look at connecting the classic vnet to my ExpressRoute to access on premise DNS. However, you need to create a virtual network gateway and a Standard skew is ~$150 per month, so really makes it unattractive. I did get it working though. I really think AADDS with ARM network support is needed to make a “mostly cloud” deployment whereby everything resides in the cloud but Azure resources can access on prem resources by name using a DNS forwarder to on-premise DNS. No on prem AD access though.

Comments are closed.

Skip to main content