Azure Answered – Macquarie Cloud Services Fortnightly Blog Series.

May 1 2020, by Raymond Phoon | Category: Cloud Services

Welcome to the first edition of our TreAzure Trove fortnightly blog series. With the recent launch of our Azure business & key strategic agreement with Microsoft, we’ve been helping organisations navigate any Azure related queries. On a fortnightly basis, our resident experts will be dissecting these first-hand queries and provide insights accordingly.

Our first edition will look at the following question submitted by a customer recently:

Can I replace my domain controller VMs with Azure Active Directory Domain Services (ADDS) in Azure?

The answer as with most other queries is “it really depends… what do you currently use your domain controllers for?”

Azure ADDS plays a middle-ground between a full-blown Windows ADDS in a VM and Azure AD. It’s 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:

  • 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.

If the features listed above are required, you’re best off sticking with traditional Windows AD Domain Controller VMs. However, if your requirements are straightforward where you have a few Windows servers in a single Azure region and just want to join them to a domain (perhaps 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.

TreAzure Trove - Azure ADDS image 1

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.

TreAzure Trove - Azure ADDS image 2

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.

TreAzure Trove - Azure ADDS image 3

Note: 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 don’t complete this, you will not be able to login or join Windows servers to the new ADDS domain.

TreAzure Trove - Azure ADDS image 4

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 two 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.

TreAzure Trove - Azure ADDS image 5

When a Windows server is joined to Azure ADDS, it is placed in the built-in ADDDC Computer OU.

TreAzure Trove - Azure ADDS image 6

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.

TreAzure Trove - Azure ADDS image 7

Azure AD guest accounts are synced with the UPN set to the originating Azure AD tenancy of the guest account user.

TreAzure Trove - Azure ADDS image 8

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.

TreAzure Trove - Azure ADDS image 9

 

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.

TreAzure Trove - Azure ADDS image 10

The only account with Domain Admins rights is a built-in account called “dcaasadmin”.

TreAzure Trove - Azure ADDS image 11

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’s not much reason to do so.

TreAzure Trove - Azure ADDS image 12

Note: The Default Domain Policy is not editable and greyed out.

TreAzure Trove - Azure ADDS image 13

With regards to the domain functional level, the level is currently set to Windows Server 2012 R2 and cannot be raised.

TreAzure Trove - Azure ADDS image 14

IMPORTANT: Azure AD to Azure ADDS synchronisation is one-way! Changes made to Azure ADDS will NOT be sync’ed back to Azure AD.

TreAzure Trove - Azure ADDS image 15

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), Microsoft mentions that the timestamp is only updated once per hour and doesn’t accurately reflect when the sync had occurred.

TreAzure Trove - Azure ADDS image 16

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.

We hope you found this deep-dive insightful. Macquarie Cloud Services is Australia’s most recommended cloud provider with an industry leading NPS score of +83. Whether you’re already on Azure or are considering a move to Azure, we’re now offering a 2-hour free Azure Consult tailored to your environment.

Click here to get in touch with the team or email hello@macquariecloudservices.com with a question or topic to feature in an upcoming blog.

Ray Phoon, Senior Cloud Architect Azure