Azure AD Domain Services Gets a Few Improvements
Azure AD Domain Services – A Reminder
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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
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:
- You can view the health of Azure AD DS, depicted as Running, Needs Attention (Warning), Needs Attention (Critical), or Deploying.
- It monitors backup and synchronization health.
- Alerting for issues
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.
Better Security Options
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:
- NTML v1
- Synchronization of NTLM password hashes from an on-premises domain (via Azure AD Connect)
- TLS v1
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.
Fine-Grained Password Policy
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.