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 datacenter. 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 allows you to join computers and sign into them using the accounts we have created in or synced with AAD. AAD DS also 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
- To Enable password sync – each user that will use the service should reset their password to sync to the new service. Until this is complete, passwords will not be fully synced (for cloud accounts this means update the user passwords in AAD; for synced accounts this means update passwords on-premises).
TIP: If you create a custom domain name, take care with existing DNS namespaces. It’s recommended to use a domain name separate from any existing Azure or on-premises DNS name space.
For example, if you have an existing DNS name space of contoso.com, create a managed domain with the custom domain name of aaddscontoso.com. If you need to use secure LDAP, you must register and own this custom domain name to generate the required certificates.
You may need to create some additional DNS records for other services in your environment, or conditional DNS forwarders between existing DNS name spaces in your environment. For example, if you run a webserver that hosts a site using the root DNS name, there can be naming conflicts that require additional DNS entries.
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:
- Group policy capabilities have evolved since release and continue to incorporate new polices on a routine basis
- 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
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 datacenter, 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 AAD DS feature costs approximately $112 per month for organizations with fewer than 25,000 directory objects.
Hopefully this helps you to understand the Domain Services feature for Azure Active Directory, why it exists, and how you can use it in your cloud solutions for your organization.
