A very common misconception about Azure Active Directory is that it can replace your on-premises Windows Server Active Directory (WSAD). To be fair, the fact that the words “Active Directory” are in the title is probably what causes the most confusion. However, even in WSAD, saying Active Directory is not descriptive enough anymore. Think of WSAD or Active Directory as just the umbrella for the actual services running beneath it like Domain Services (DS), Federation Services, Certificate Services, and so on.
If you want an Active Directory domain in your network, you would install the Active Directory Domain Service role and applicable features on your server(s). This has been the case for quite some time. It is the DS role that provides the Active Directory database and feature-set that we have come to know and love (or like or hate; I don’t judge).
When Microsoft introduced Azure Active Directory, they specifically left out Domain Services from the name because it isn’t domain services at all. It is an identity solution that allows us to store users with their passwords and other settings, groups, and contacts. But there are no computer accounts, no Group Policy, and no domain controllers. You can’t join computer accounts to Azure Active Directory in the way we are used to and then use AAD accounts to sign into those computers.
It doesn’t matter if you’re syncing WSAD to AAD. Your computers and servers are completely unaware of the identity store. So even though you might be using AAD Connect to sync your on-premises Active Directory users, groups and contacts to AAD, we still can’t use those accounts to sign into a server or workstation.
Where this has caused the biggest issue is when we spin up virtual machines in an Azure subscription. We would like to join those machines to our domain without having to host a domain controller in Azure that replicates back to our on-premises data center. Even when syncing, the servers in Azure are not able to join the AAD service you have running because it is not Domain Services.
Windows 10 and Windows Server 2016 does have a way to register with Azure AD, but any devices running older operating systems will still have an issue if you want to move your domain to the cloud.
Here is the good news! Microsoft created the Azure Active Directory Domain Services feature as an add-on to Azure Active Directory. AAD Domain Services or AAD DS is the feature of AAD that gets us what we have been looking for: a way to use AAD to join computers and sign into them using the accounts we have created in or synced with AAD. This feature was in preview for about a year and has recently gone GA. We took some time to get to know it, and we are very pleased with the service. The feature includes the ability to set up organizational units and some basic group policies.
The components required to use the service is a specific group in AAD and a virtual network with a subnet. That’s it. The group is used by AAD as the equivalent to “Domain Administrators” in WSAD. The network and subnet is required because the DS feature generates two Windows Service virtual machine instances with the Active Directory Domain Services role and applicable features. Those two machines are placed in the virtual network and subnet, and they are then accessed by all the other virtual machines you deploy to that virtual network.
The steps to set up the AAD DS feature are straight-forward:
- Create the administrative group – you have to use the name “AAD DC Administrators”
- Create or select a virtual network for the DS server instances
- Enable Azure AD DS in the Azure portal
- Update the DNS settings for the virtual network to point to the new DS server instances
- Enable password sync – for cloud accounts this means update the user passwords in AAD; for synced accounts this means update passwords on-premises
This process from start to finish without an existing virtual network took about 30 minutes to complete. Once that was done, we could deploy a new virtual machine, add it to the new AAD DS domain, and use our AAD credentials to sign into the server.
But we do have some caveats:
- The DS feature is currently administered using the classic portal
- The virtual network the DS Servers join must be a classic virtual network
- Group policy capabilities are limited but growing
- Policy settings and OU structure are unique to the DS in Azure, and there is no syncing of policies or OU’s from on-premises to Azure AD DS
The virtual network requirement is our least favorite restriction. We have fully converted to Azure Resource Manager (ARM) based resources and are using templates to deploy my environments. It is one of our favorite features of Azure, so we were a bit disappointed when we saw it, but this is a small limitation that will probably be resolved soon. With the VNet peering, you can create a classic virtual network for the DS servers and then deploy an ARM-based virtual network that you can pair with the classic virtual network. This lets us deploy ARM virtual machines to our ARM virtual network and still join the AAD DS domain.
In regards to the Policy and OU caveat, we mention this only because if you have time invested in Group Policies for configuration of servers, then this may not be the feature for you. You would need to recreate those policies in the AAD DS servers, and that assumes the settings you have applied are available in the group policy feature in AAD DS. Also, you will need to recreate any OU structure because those do not currently sync.
What Scenario(s) Does This Apply To?
It applies to any company that doesn’t want to set up a site to site connection with Azure to deploy a domain controller in an Azure subscription that has the ability to replicate back to the on-premises domain controllers. All you have to do is set up AAD Connect (which most companies using Office 365 already do), then set up AAD DS, and now you can have servers running in Azure that let you log into them using your on-premises credentials without having to set up a VPN or ExpressRoute site to site connection. You also don’t have to convince your security people that a domain controller or two in the cloud will be safe.
Lastly, the service is priced quite well. If you wanted to set up your own virtual machines in Azure that are domain controllers that replicate back to your data center, the cost would be over $450 a month. This is the cost for two virtual machines and the VPN connection. This does not include the storage for those machines or the bandwidth charge generated by the replication traffic. The new AAD DS feature costs $111.60 per month for organizations with fewer than 25,000 directory objects.
I hope this helps you to understand the new Domain Services feature for Azure Active Directory, why it exists, and how you can use it in your cloud solutions for your organization.