Azure Active Directory Domain Services: Your Domain Controller as a Service

Here it comes: a new, really cool Azure AD feature that a lot of us were probably expecting for some time now. Although in Preview, it really doesn’t matter because it’s impressive. This is a new cloud service that allows you to build your entire infrastructure using a compatible Windows Server Active Directory set of APIs and protocols that your VMs may need.

In the past, when there was a need for the VMs or applications to actually “see” an Active Directory database in Azure, we’ve used these 2 specific approaches: The first one was to install a Domain Controller as a VM in Azure, let it replicate the entire AD database with the on-premises DC, so the applications or other services could be able to communicate with AD; the second one was to create a VPN connection that should connect the on-premises infrastructure and our local AD to the services that run on Azure.

Both of these approaches had some issues related to administration, reliability and cost. In case you use a site-to-site VPN, network problems could create instability of the service. On the other hand, if you create a VM and configure it as a DC, you’re fully responsible for the VM itself (patches, updates, misconfiguration issues, etc).

It seems that there was a strong demand for Azure AD Domain Services because of all these issues presented above. Now you have the option to use your own cloud based domain services and join computers to the domain, create group policy objects, use LDAP and Kerberos authentication, services that are fully compatible with what you’ve used for years now: Windows Server Active Directory on premises. And of course your users can still log on by using the same username and password, because these accounts still belong to the same AD Tenant on Azure. Really really simple concept.

Just one thing that you have to keep in mind: as of today (15 Oct 2015), Azure Active Directory Domain Services are available in the following Azure regions:

United States
- Central US
- East US
- East US2
- South Central US
- West US
Asia
- East Asia
- Southeast Asia

So let’s examine some possible scenarios that Azure AD Domain Services could be used.

Scenario 1: Cloud-only organization

In this scenario, the organization doesn’t have an on premises AD infrastructure, but the administrators want to be able to manage their infrastructure that is already configured on Azure. Let’s assume that they want to manage their Azure VMs using their corporate credentials.

In this scenario, the administrator can enable Azure AD Domain Services for their existing AD Tenant with just a few clicks. A new domain will be configured and all the user accounts that already exist in their AD Tenant will be made part of this new domain. After this, all VMs could be members of this new domain and the administrators can benefit from the usual domain services like LDAP read-bind, Kerberos and Group Policies (LDAP Write will be available through an upcoming update). The best part is that users will be able to login to these VMs using their corporate credentials.

Scenario 2: Hybrid organization

This organization has a mix of recourses, some of them on premises and some other on Azure. This company has also an on premises Windows Server Active Directory Infrastructure. These on premises AD objects are already synchronized to Azure AD by using Azure AD Connect. They have also created a virtual network in Azure with applications and VMs. Just like in the previous scenario, it’s possible to provision a new domain and all the configured user accounts, credentials and group memberships of this AD Tenant (that is synced with the on premises accounts) will be made part of the new provisioned domain. So users will be able to logon to the Azure infrastructure using their corporate credentials.

Just a note: for security reasons, this new AD domain is a standalone one; do not consider it as an extension of the on premises AD infrastructure.

Finally, let’s clarify a few things. In case you want to use VMs and you want to manage them using Azure AD Domain Services, there are some important things to consider:

Managed Domains that are created using Azure AD Domain Services support a flat OU structure. Hierarchical OUs are not supported, so all domain joined computers reside in a single flat OU.
There is a built-in GPO for the users and computers containers, so you cannot target OUs or create your own GPOs.
Azure AD Domain Services supports the base AD computer object schema. You cannot extend the computer object’s schema.
In case you want to use custom applications that need to use LDAP, make sure that the applications do not need to modify or write to the directory.
The applications that you use cannot modify the schema.
The applications cannot use LDAPS. If you don’t know what is LDAPS, you can check an older blog post here (article in Greek).
The applications cannot use certificates or smart cards for authentication.