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 3^rd 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 https://docs.microsoft.com/en-us/azure/active-directory-domain-services/password-policy

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! https://docs.microsoft.com/en-us/azure/active-directory-domain-services/concepts-replica-sets?WT.mc_id=AZ-MVP-5004159

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.”
https://docs.microsoft.com/en-us/azure/active-directory-domain-services/overview

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.

Options

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.

Summary

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.