If you are building an infrastructure-based application deployment in Azure (virtual machines) then it’s not unusual to require a domain – correctly referred to in Windows Server as Active Directory Domain Services (ADDS). ADDS provides us with a directory that has features such as organizational units (OUs), role-based access control (RBAC), and group policy objects (GPO). You can deploy some virtual machines, even modestly priced B-Series machines, to host this Windows Server role and then join the other Windows Server machines to the domain.
In The Cloud, we should want to push as many services as possible down into the fabric. This approach allows us to spend less time on the mundane and time-consuming work, and spend more time on more valuable work at the application, settings, and data layers. Azure AD Domain Services is an example of this.
Instead of building virtual machines as domain controllers which we then must maintain, patch, backup, and eventually replace with machines with a newer OS, Microsoft offers us a domain-as-a-service – and no, that is not Azure AD.
We can deploy Azure AD Domain Services which is linked to the Azure AD tenant. Under the covers, Microsoft deploys a pair of virtual machines that will act as domain controllers. The machines are connected to a virtual network of our choice in an Azure region of our choice. The domain controllers synchronize with Azure AD but, unlike Azure AD, they offer OUs, GPOs, RBAC, and classic machine join – which is supported only with Azure virtual machines (not on-premises or roaming machines).
The service allows us to run a classic domain for cloud-based machines but without the burden of managing additional machines: patching, backup, “upgrades”, and so on. Like with all cloud services, improvements are made.
Very large customers have had issues with the synchronization of hundreds of thousands of users, groups, and group memberships between Azure AD and Azure AD Domain Services – sometimes taking weeks to complete! Microsoft claims that these huge synchronizations now take “a few days”.
Under the covers, there are still machines. It’s still the same old Active Directory Domain Services in those machines, and backups are still required. Microsoft has added health monitoring:
New deployments of Azure AD Domain Services now are created using managed disks. The main benefit for us is alignment with the availability set, which should ensure higher levels of uptime for the domain service.
SMB 1 might not be the only protocol that you should kill off on your networks! We now have the ability to disable the following in Azure AD Domain Services:
You can limit which user accounts should be synchronized from Azure AD into the managed domain in Azure AD Domain Services. This will result in better security and more efficient synchronization for very large customers.
You now have more control over password policies in a managed domain, enabling longer password lifetimes (if required), and custom complexity and lockout settings for OUs.