Earlier this week Microsoft announced the preview of Azure AD Domain Services (AADDS). This new functionality allows applications that are designed to run against your On Premise Active Directory to easily run in Azure (with out having to put in place domain controllers in Azure and VPN connections back to your on premise AD).
In simple terms at the click of a button you can have a ‘managed’ domain controller fully synced up with your Azure AD appear in one of your VNet’s. You can then domain join your Azure servers in the same way you would your On Premise servers.
There are a number of steps that have to be undertaken to enable Azure AD Domain Services but Microsoft have written a great blog that steps you through the process. You must complete all steps before attempting to join an Azure VM to the new AADDS domain.
Couple of points to note from my testing so far.
- Azure AD Domain Services are not yet available in all regions. If you have all your Azure infrastructure running in the Australia regions you will need to create a new VNet in either the US, Europe or Asia region to be able to enable Domain Services.
- Azure AD Domain Services uses password write back to sync passwords with Azure AD. As with AD Connect a password reset using http://myapps.microsoft.com is generally required to generate the hashes in AD before the account can be used to authenticate against the Azure AD Domain Service.
- Any user account that you put in to the AAD DC Administrators group will be added to the administrators group on any machines you join to the AADDS domain.
- As Azure AD Domain Services its a managed service you can not have Domain Administrator or Enterprise Admin privileges over the AADDS domain.
- Currently a single user and computer group policy is supported and the domain can be managed with the same tools that are used to manage on-premise AD.
Further Blog articles to come as I rebuild my Azure test environment using Azure AD Domain Services!