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 - https://azure.microsoft.com/en-us/documentation/services/active-directory-ds/ – 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

Walkthrough

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 10.1.0.0/16 and a subnet called Subnet-0, address range 10.1.0.0/24.

AADDS01

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

AADDS01a

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

AADDS02

Now I hook them together with a site-to-site VPN. The steps to do this are covered really well over here - https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-arm-asm-s2s-howto/. After stepping through this guide my classic and ARM VNets are connected

AADDS03

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 https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-getting-started/. After following this guide, I have

AADDS04

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

AADDS05

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)

AADDS06

AADDS07

AADDS08

AADDS09

AADDS10

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.
    https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-different-deployment-models-portal

      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.

Skip to main content