Don’t Use Azure AD Domain Services to Replace Windows Domain Controllers

Azure AD Domain Services

Don’t Use Azure AD Domain Services to Replace Windows Domain Controllers

Azure AD Domain Services

I’ve been sitting on this topic for a while.  I typically like to pass along information that helps people better understand Azure and other Microsoft products absent of my option.  However, this post is slightly opinionated, an opinion that was formulated after seeing problems users ran into while trying to use Azure AD as a replacement for Windows AD. 

Azure Active Directory Domain Services (Azure AD DS) is not a replacement for Windows Active Directory.  I understand the confusion, one of my most popular videos is on the difference between Azure AD DS, Windows AD and Azure AD (here).  At a high level, both Azure AD DS and Windows AD offer network-based authentication with Kerberos and NTLM support.  Azure AD DS is compatible with Windows AD.

Based on online forums and social media posts, The compatibility between Azure AD DS and Windows AD has caused problems.  The problem usually starts with something like: “We want to get rid of on-premises domain controllers” or “I was given the directive that we will no longer support Windows AD.”  Azure AD DS is a Platform as a Service (PaaS) offering, and it’s understandable how, given these directives, moving from Windows AD to Azure AD DS may make sense.

However, Azure AD DS is not intended as a replacement for Windows AD.  Before we go over what it’s intended for, let’s consider the limitations of Azure AD DS that make it a wrong choice as a replacement to Windows AD. 

Azure AD DS Limitations

No Hybrid Azure AD Join

A client computer can be joined to AD DS (Windows or Azure) or to Azure AD.  For client computers joined to Windows AD, Azure AD Connect Sync can hybrid join them to Azure AD.  Azure AD Connect Sync does not support Azure AD DS and, therefore, client computers cannot be Hybrid Azure AD Joined if a member of an Azure AD DS domain.  These client computers cannot be part of services that require Azure AD Join or Hybrid Azure AD join, such as Universal Print or Conditional Access Policies.

No Enterprise or Domain Admin

There are no Enterprise or Domain admin accounts in Azure AD DS.  Instead, there is a group called AAD DC Administrators used to manage Azure AD DS.  Accounts in this group have rights such as local administrator on member servers and administrative rights required to manage Azure AD DS.  The Domain and Enterprise Administrator permissions are reserved for the Azure AD DS service.

No Active Directory Certificate Services Support

The first requirement for installing Active Directory Certificate Services is to log in as a member of the Enterprise Admin Group.  As stated, these accounts do not exist in Azure AD DS, and therefore, AD Certificate Service is not supported in Azure AD DS.  That rules out certificate-based features such as smart card authentication.

Schema cannot be Extended

Azure AD DS does not support extending the schema.  Lack of schema extension rules out any applications, both Microsoft and 3rd party, that require a schema extension.

Limited Group Policy Support

Azure AD DS is a PaaS offering, meaning customers don’t have to log in and manage the Domain Controllers.  With that said, there is no access to server resources such as the sysvol folder.  Azure AD DS does support a default set of group policies.  However, it is not possible to add ADMX files to the sysvol folder.

Also, there is a default policy for account lockouts applied to all Azure AD DS users.  You can create a new policy with more restrictive settings, but you can’t change the default policy.
Update 8/31/2021
Someone pointed out the link below. Unfortunately, I can’t find who it was to give them credit. It is possible to change the default password In Azure AD DS policy from the Azure Portal

Limited Redundancy

A best practice with Windows AD was to put a DC as close to users as possible.  It is common to do this by deploying Domain Controllers in branch locations to process logins locally and provide login services if WAN connectivity failed.  An Azure AD DS instance is limited to two domain controllers in a single region.  If that region goes down or the network connectivity is disrupted, login processing would become unavailable.

Update 9/7/2021
It is possible to add up to 5 replicas with the enterprise SKU of Azure AD DS. Thanks to G. Jongeneel for pointing this out!

Azure AD DS has a Different DNS Name

Azure AD DS requires a publicly routable domain when deployed.  The domina name is a different domain from the on-premises domain and the Azure AD domain.  User replicated from the source Azure AD domain can log in with their Azure AD UPN, but any users provisioned from Azure AD DS will use the Azure AD DS domain suffix.  This situation is manageable but confusing for users and support.

No Forest Trusts

There are two types of Azure AD DS forests.  A User forest synchronizes all objects from Azure AD.  Included are users accounts sourced from Windows AD, providing Azure AD Connect Sync is in place between Windows AD and Azure AD.  This forest type does not support forest trusts.  Forest trusts are common for larger organizations, or during merger and acquisition activities that require sharing resources across disjoined forests.

Technically, the second Azure AD DS forest type, a resource forest, does support trusts relationships.  It does not, however, synchronize objects from Azure AD.  Instead, it’s used for resources that rely on a trust relationship with a Windows AD domain for access.

Update 6/18/2022
The Microsoft documentation now indicates a one-way forest trust is is available with a user or resource forest.

Not Publicly Available

One frequent question I see is a version of “now that I have Azure AD DS, how do I join my laptop to it?”  Joining a client to Azure AD DS requires a private network connection, VPN, or ExpressRoute, for the same reason joining a Windows AD domain requires one. There are significant security risks to exposing Active Directory Domain Services to the internet. 

No MSIX App Attach Support

Update 8/26/2021
Azure Virtual Desktop supports Azure AD DS.  However, MSIX App Attach is not supported in environments that use Azure AD DS for the directory service (Link.)  This is because the computer objects in Azure AD DS are not synchronized to Azure AD and, therefore, the required RBAC roles cannot be applied to the computer object.

What is Azure AD DS for?

You may question the point of Azure AD DS if it comes with all these limitations, but it does have a valid use case.  Below is a paragraph from the Microsoft Azure AD DS Overview Documentation.

“An Azure AD DS managed domain lets you run legacy applications in the cloud that can’t use modern authentication methods, or where you don’t want directory lookups to always go back to an on-premises AD DS environment. You can lift and shift those legacy applications from your on-premises environment into a managed domain, without needing to manage the AD DS environment in the cloud.”

Notice one word that’s missing from this paragraph: clients.  Azure AD DS provides a way to move applications that require network authentication methods, Kerberos and NTLM, into Azure without extending an on-premises Windows AD directory to Azure.  It is not intended for client and device management or as a direct replacement for Windows AD.

Moving to Modern Authentication

As stated in the beginning, most attempts to move to Azure AD DS start with “We want to get rid of on-premises domain controllers” or “I was given the directive that we will no longer support Windows AD.”  If you are one of those facing this directive, I suggest reframing the goal to “we need to move away from Kerberos and NTLM Windows AD Authentication.”  This becomes a much more tangible and achievable goal.

Replacing Active Directory Domain Services with Azure AD Join and leveraging modern applications such as Teams, SharePoint and OneDrive will alleviate the need for Windows AD authentication.  Use Microsoft Endpoint Management and Intune to manage devices instead of Group Policies.  This path removes the underlying dependency on Active Directory Domain Services and, thereby, the need for domain controllers.


An attempt to move away from Active Directory Domain Services may be short-lived due to applications or services that require AD DS.  In that case, the organization has two options, Move to Azure AD DS and accept the limitations, or continue with Windows Domain Controllers.

Accept AD DS Limitations

Sometimes directives are mandated despite the repercussions.  If that’s the case, you will have to accept the limitations. That may be fine as a stop-gap for a legacy application but not as a solution for managing enterprise clients.  If Azure AD DS is used for managing clients, consider how the organization will migrate to Windows AD when the limitations make the service no longer viable.

Stay with Windows AD

If the organization requires AD DS and Azure AD DS limitations won’t fit the environment, the only other option is to stay with Windows AD.  Windows AD can exist as IaaS VM’s in Azure, and unlike Azure AD DS, redundant Windows Domain Controllers can be deployed to multiple regions to provide high availability.  Add ExpressRoute or VPN to support a hybrid environment of on-premises and cloud-based Windows AD Domain Controllers.

Prices vary by region and size, but two IaaS VM’s used for Domain Controllers can be provisioned at close to the same monthly price as Azure AD DS.


At first sight, it may be tempting to think of Azure AD DS as a replacement for Windows AD.  However, that’s not the intent of the product.  Azure AD DS has limitations that make it less than ideal for a direct replacement to Windows AD.  Recognize how these limitations impact the deployment now and into the future.   

15 thoughts on “Don’t Use Azure AD Domain Services to Replace Windows Domain Controllers”

  1. ”The domina name is a different domain from the on-premises domain and the Azure AD domain. ”
    Thats not true! You can have the same,

      1. And just for clarity whilst you can use the exact smae name – that in no way links them or makes them the same domain even if there is network connectivity between AD DS DC’s and AAD DS. They will always be two seperate domains just with the same name! Have seen a number of customers out there making this assumption hence the comment. Great article BTW.

  2. Just a little extra information on the limited redundancy:

    Can I fail over Azure AD Domain Services to another region for a DR event?
    Yes, to provide geographical resiliency for a managed domain, you can create an additional replica set (Enterprise SKU) to a peered virtual network in any Azure region that supports Azure AD DS. Replica sets share the same namespace and configuration with the managed domain. You can create a maximum of five replica sets – the initial replica set for the managed domain, plus four additional replica sets. Replica sets must be in the same subscription as the managed domain.

  3. You can copy the admx group policy to the \\yourdomain\sysvol\yourdomain\Policies\PolicyDefinitions

    MSIX attach will work with netapp storage.

  4. Is the statement “No Active Directory Certificate Services Support” still true? Is there a official support page from microsoft with this information?

  5. Hi Travis.
    I´ve a common scennario where all the computers and servers and joined to a local AD.
    This AD via Entra Connect Sync replicas users and grups to Entra ID.

    Now i´ve been asked to add Entra Domain Service and if possible delete the local ADs.
    If I create a new domain in Entra Domain Service and delete my 2 local ADs, the questions are;
    -How the computers (Windows 10) and servers (windows 2016) will continue to do the sign in against Entra Domain Service?
    -Do I have to unjoin PCs and servers from my local domain and join to Entra Domain Service?
    -Imagine I dont have those limit that you have pointed out, what other conserns would you imagine some will face if they delelte the local ADs and start using only Entra Domain Service.


    1. Entra DS is a new forest/domain. The computers will need to be removed from the old and added to the new Entra DS Domain. You will need private network connectivity between any on-prem computers and Entra DS, either ExpressRoute or VPN. Login could be limited if that connection goes down. Entra DS is not available over the internet. There is no Hybrid Entra ID join as pointed out in the article.
      Good luck!

  6. This seems like another one of those contradictory situations with MS/Azure and the Future state – the road that most/everyone is being steered down as passengers.

    One thing I am still trying to understand is how to provision a fundamental requirement for a file share where you can set ACLs that is hosted in Azure. I have established that its not do-able in a PURE AAD/Entra ID setup. Do Domain Services help here?

    To clarify, I am talking a fileshare in an azure storage account. Again, I specifically point out a need for ACLs in the fileshare (i.e. the folders) – so ‘token’ authentication does not help. This really seems to be an omission that no-one is talking about and/or calling out. If you were starting from scratch/nothing today to setup an environment and did not want any on-prem to worry about, how would you do it?

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Click Here!
May 2024
Scroll to Top