Replacing Windows AD with Azure AD Domain Services?
Recently, I have received several questions regarding Azure Active Directory Domain Services; the main question being “Can I replace my domain controller VMs with Azure ADDS in Azure?”
The answer as with most other queries is “it depends.. what do you currently use your domain controllers for?”
Azure ADDS is like a middle-ground between a full blown Windows ADDS in a VM and Azure AD. It is PaaS-like, charged hourly, allows for domain-joined Windows servers, provides secure LDAP and has limited group policy functionality.
The features below are NOT available with Azure ADDS so if you need these, stick with traditional Windows AD Domain Controller VMs:
- Multi-region ADDS or disaster recovery to another Azure region.
- Ability to extend the directory schema.
- Upgrading the domain/forest functional level.
- Extensive use of group policies and users in multiple Organizational Units (OUs).
- Support for DFS-R file replication.
However, if your requirements are simple where you have a few Windows servers in a single Azure region and just want to join them to a domain (maybe due to having an older version of SQL Server), then yes, Azure ADDS can be used instead of having two Windows AD Domain Controllers in a VM to reduce on the running and administrative costs.
The first thing to choose when deploying Azure AD Domain Services (ADDS) is the SKU to select. The tier depends on the load, number of objects, frequency of backups and if resource forest is required.
The next important decision is the domain name. The local Azure AD domain is normally populated (*.onmicrosoft.com) but a routable domain is highly recommended especially if secure LDAP will be used due to certificate requirements.
IMPORTANT: The prefix of the DNS domain name MUST NOT EXCEED 15 characters. This is because the prefix will become the domain NETBIOS name and limited to 15 characters.
Select an empty subnet and choose if all Azure AD objects will be replicated to Azure ADDS or just a filtered scope.
Once Azure ADDS is provisioned, a new Azure AD group is created called “AAD DC Administrators” and users in this group will have administrative rights.
The next required step is to configure your VMs in Azure to point to the provisioned domain controllers IP addresses. This can be done by either configuring each VM’s DNS settings to point to the Azure ADDS IP addresses or to configure the DNS on the VNET.
Note that you will need to restart your VMs to utilize the new DNS servers from the VNET. Alternatively, you could run “ipconfig /renew” to get the updated DNS servers on each VM.
The next step is very important, you will need to enable password hash sync from Azure AD to Azure ADDS then reset the password of the users who will login to Azure ADDS so that the password hash can be generated. If you do not complete this, you will NOT be able to login or join Windows servers to the new ADDS domain.
Once completed, you can now join your first Windows Server VM to Azure ADDS. The process is the same as joining a Windows Server to a Windows AD domain controller and you will need to use user credentials from a user in the AAD DC Administrators group to complete the process.
Azure ADDS provisions 2 domain controllers but you will NOT be able to access them directly nor log into them via RDP. Instead, you will need a bastion host (windows administrative host) and install Active Directory Tools and Group Policy Management Tool to administer Azure ADDS if required.
When a Windows server is joined to Azure ADDS, it is placed in the built-in ADDDC Computer OU.
All users which were synced from Azure AD is placed in the built-in AADDC Users OU. If you do not limit the sync scope, the sync will also include any Azure AD guest users from different Azure AD tenancies.
Azure AD guest accounts are synced with the UPN set to the originating Azure AD tenancy of the guest account user.
Moving user accounts from the built-in “AADDC Users” OU is NOT supported. If you attempt to move a user object to another OU, you will be presented with an “Access is denied” error.
Another interesting observation is that the AAD DC Administrators group does NOT have Domain Admin rights to Azure ADDS. If you try to add any accounts to the Domain Admins group, you will get an error stating that you do not have permissions to modify this group.
The only account with Domain Admins rights is a built-in account called “dcaasadmin”.
As with Windows Group Policies, you will have access to edit the built-in computer and user group policies linked to the “AADDC Computers” and “AADDC Users” OUs respectively. You could create new GPOs as well and create new OUs but as user objects cannot be moved, there is not much reason to do so.
Note: The Default Domain Policy is NOT editable and greyed out.
With regards to the domain functional level, the level is currently set to Windows Server 2012 R2 and cannot be raised.
IMPORTANT: Azure AD to Azure ADDS synchronisation is one-way! Changes made to Azure ADDS will NOT be sync’ed back to Azure AD.
Microsoft used to mention a sync schedule of approximately 20-30 minutes between Azure AD to ADDS. However, this has been removed from their documentation as there is no SLG on synchronisation.
The Azure Portal’s Azure ADDS section has a Health monitor which lists the last time the sync took place BUT according to the comments section of the documentation (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/synchronization), MS mentions that the timestamp is only updated once per hour and doesn’t accurately reflect when the sync had occurred.
If you are experiencing abnormally slow sync times, Microsoft suggests logging a support ticket so that they can troubleshoot the issue.
In conclusion, Azure ADDS provides a cost effective solution to run “simplified” Active Directory functions as a PaaS service as not having to administer and patch additional servers each month reduces administrative overhead.
As mentioned, it’s not for everyone but it does bridge a gap between Azure AD and traditional full blown Windows AD Domain Controllers.