Azure Active Directory Domain Services

When it comes to identity management Active directory have a long history plus many Enterprise companies rely on it. With the shift towards cloud based solutions and public cloud wave customers and Microsoft both has to think about how they manage their end user identities.

Right now Active Directory can be extending to cloud in couple of ways,

  1. Extend Active Directory to Azure by deploying DC in Azure and replicate with on premise Domain controller
  2. Extend on premise Active Directory with Azure Active Directory.

Latest option is AADDS (Azure Active Directory Domain Services). Think this is as Active Directory born purely in cloud. Your Azure virtual machines can be joined to Azure born Active Directory service. If you’re purely cloud born company and focus on clod based application this is ideal startup for you. Apart from that still you can import your on premise directory focus application to the cloud. Azure Active Directory Domain Service provided Windows Server Active Directory compatible set of API’s and protocols, delivered as a managed Azure service. This means as part of Azure AD you can now turn on support for all the critical directory capabilities your application and server VM’s need, including Kerberos, NTLM, Group Policy and LDAP.

So with this new AADDS you’ll get the ability to take any on-premises application that depends on Windows Server Active Directory and run it in Azure Infrastructure Services without having to worry about running, maintaining or patching Active Directory Domain Controller VMs. Those tasks will be taken care from Microsoft Azure team. (Isn’t this sound cool?)

Ok let’s have a high level steps how we can enable this new service.

  1. Create a Directory Service in the Azure portal,

    Make sure your domain name is a unique name.

  2. Create the ‘AAD DC Administrators’ group – Using the Azure management portal, create a group called ‘AAD DC Administrators’ and add all users who need to be administrators on the managed domain to it. These administrators will be able to join machines to the domain and to configure group policy for the domain.

  3. Select / Create the Azure virtual network in which to enable Azure AD Domain Services – you’ll need to create Azure virtual network to be associate with the AADDS. Ensure you pick a virtual network that satisfies the following criteria:


  • The virtual network belongs to a region supported by Azure AD Domain Services. See the region page for details.
  • Ensure the virtual network is a regional virtual network and doesn’t use the legacy affinity groups mechanism.
  • Ensure your workloads deployed in Azure Infrastructure services are connected to this virtual network.

  1. Enable Azure AD Domain Services for your Azure AD tenant – Enabling Azure AD Domain Services for your Azure AD tenant is a simple process. Navigate to the Azure AD tenant and click on the ‘Configure’ tab of your directory. You will notice a new section titled ‘Domain Services’.

    During this time make sure to select the correct virtual network you’ve created in the Step 3. You can also select custom domain name if you’ve already completed that step previously.

    Once the provision completed from Azure side you’ll see two Azure ADDS IP address will be available for you. Don’t be surprised if you don’t see two IP address at once. It can take 20-30 minutes for the first IP address to be displayed and another 20-30 minutes for the second IP to be available.

  2. Update DNS settings for the Azure virtual network – At this point, you can set these IP addresses as the DNS servers for the virtual network in which you had enabled Azure AD Domain Services. This enables virtual machines within that virtual network to ‘see’ the domain and connect to it for domain join, LDAP, authentication etc.

  3. Enable synchronization of legacy credential hashes to Azure AD Domain Services – This is an important step that you need to complete in order to use the domain you have just created. By default, Azure AD does not store the credential hashes required for NTLM/Kerberos authentication. You need to populate these credential hashes in Azure AD so users can use them to authenticate against the domain. The steps involved in populating these hashes Azure AD Domain Services are different for cloud-only and synced tenants.


    Cloud-only tenants – If your organization is a cloud-only Azure AD tenant, users that need to use Azure AD Domain Services will need to change their passwords. This step causes the legacy credential hashes required by Azure AD Domain Services for Kerberos and NTLM authentication to be generated in Azure AD and populated into Azure AD Domain services. You can either expire passwords for all users in the tenant that need to use Azure AD Domain Services or instruct these end-users to change their passwords.


    Users can use Azure AD’s self-service password change mechanism from the Azure AD Access Panel page in order to change their passwords. After users change their password, the hashes will be populated into Azure AD Domain Services. After the population is complete, users can then login to the domain using their newly changed password. Note that this is a one-time process and subsequent password changes will work automatically with Azure AD Domain Services.

  4. Going further you’ve completed most of the steps to use the ADDS service. If you’re creating the a new VM in the creation process you can select which virtual network VM should be provision. This will help the VM to receive the relevant DNS details.

    That’s about it! Azure AD Domain Services should be configured for your Azure AD tenant. Next step is to try out few scenarios in your new tenant like adding Azure VM to domain, importing on premise application…etc. You can get few scenario ideas from here.

Talk about pricing Azure AD Domain Services are available for all SKUs of Azure AD – i.e. Free, Basic and Premium. Azure Active Directory Domain Services usage is charged per hour, based on the total number of objects in your Azure Active Directory tenant, including users, groups, and domain-joined computers. Each tier supports a certain average user workload, 

Tier/Number of directory objects 1, 2

Approximate supported user workload

Preview price 2

General availability price 2

Less than 5,000

~1,250 users

Tier not available in preview


5,001 to 25,000

~6,250 users



25,001 to 100,000

~25,000 users

Tier not available in preview


Greater than 100,000

Contact us

Tier not available in preview

Contact us

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.