Azure AD DS vs Self-Managed AD DS: Microsoft Entra Domain Services Compared

Azure AD DS vs Self-Managed AD DS: Microsoft Entra Domain Services Compared

Originally published 26 September 2020 · Reviewed 5 November 2026

Searches for "Azure AD DS vs on-premises AD" and "AAD vs ADDS" usually come from the same decision: an application in Azure still expects Active Directory, and someone has to decide who runs the domain controllers. This article compares the two ways to get Active Directory Domain Services (AD DS) for cloud workloads, and shows where Microsoft Entra ID fits beside them.

A naming note first. Microsoft renamed Azure Active Directory to Microsoft Entra ID, and Azure AD Domain Services (Azure AD DS) became Microsoft Entra Domain Services. The features did not change with the name. Older posts, error messages and Stack Overflow answers still say Azure AD DS, so this article uses both names.

The two models

You can provide AD DS to applications and virtual machines in Azure in two ways:

• A managed domain. You turn on Microsoft Entra Domain Services for a tenant. Microsoft deploys and maintains the domain controllers, the operating system and the patching. You consume the domain.
• A self-managed domain. You build Windows Server virtual machines, promote them to domain controllers and look after them like any other AD DS deployment, either as a separate cloud-only forest, as a resource forest with a trust to your on-premises forest, or as extra domain controllers for your existing domain reached over VPN or ExpressRoute.

The managed domain deliberately offers a smaller feature set. There is no forest, domain, site or replication topology for you to design, which removes much of the work and also much of the control.

Feature comparison

The table follows Microsoft's published comparison of managed and self-managed domains.

If a vendor application insists on a schema extension, such as some older messaging or inventory products, a managed domain cannot host it. If an application only needs to join machines, read users and groups over LDAP and authenticate with Kerberos, a managed domain is often enough.

How identities get into a managed domain

A managed domain synchronises one way from Microsoft Entra ID. Users, groups and credential hashes flow into the managed domain; objects you create inside the managed domain do not flow back. If your users also exist in an on-premises AD DS, Microsoft Entra Connect synchronises them to Microsoft Entra ID first, and Entra Domain Services receives them from there.

Passwords need attention. Entra Domain Services needs the password hashes that NTLM and Kerberos use. For hybrid users that means password hash synchronisation. Microsoft also notes that if on-premises AD DS is federated with AD FS and password hash sync is not enabled, no current password hash is available to the managed domain, so it cannot validate those users' credentials. Plan this before you promise an application that "everyone can sign in".

How this differs from Microsoft Entra ID

Microsoft Entra ID and AD DS are not two editions of one product. Entra ID is a cloud identity service built around OAuth and OpenID Connect, device identity and Conditional Access. It has no domain controllers, no Group Policy and no LDAP server of the traditional kind. Devices that are Microsoft Entra joined authenticate with those modern protocols and are managed with mobile device management such as Intune. Servers that join a managed domain authenticate with Kerberos and NTLM and are managed with Group Policy, and they must be on, or peered with, the virtual network that holds the managed domain.

A rough rule: end-user laptops and phones belong in Entra ID, with hybrid join if they must also stay joined to an on-premises domain. Servers running legacy applications in Azure belong in a domain, either managed or self-managed.

Choosing

Lean towards Microsoft Entra Domain Services when:

• the workload is a lift-and-shift of an application that needs Kerberos, NTLM, LDAP or domain join in Azure;
• you have no spare capacity to run, patch and back up domain controllers;
• you can live without schema extensions and Domain Admin rights.

Lean towards self-managed AD DS when:

• you must extend the schema or need full administrative control;
• you want the cloud domain controllers to be part of your existing domain, with normal replication;
• a vendor requires a specific forest design, or account-based Kerberos delegation.

Lean towards neither when the applications already support modern authentication. They can use Microsoft Entra ID directly, and a domain adds cost and attack surface you do not need.

Common mistakes

Teams most often run into trouble in three places. The first is assuming a managed domain is an extension of the on-premises domain; Microsoft describes it as a stand-alone domain, so it has its own namespace and its own Group Policy. The second is forgetting the network: servers can only join the managed domain if they can reach it, which usually means peering virtual networks and pointing their DNS at the managed domain controllers. The third is treating the administration model as a detail. In a managed domain you receive delegated administrator rights through a dedicated group, not the Domain Admin account you may be used to, so scripts and tools that assume full rights can fail.

Questions to answer before you choose

1. Which applications need Kerberos, NTLM or LDAP, and can any of them move to modern sign-in instead?
2. Do any of them require a schema extension or a Domain Admin account?
3. Where will the workloads run, and can they reach the virtual network with the managed domain?
4. How will password hashes reach the managed domain, and is any user population federated without password hash sync?
5. Who will own domain controller patching, backups and monitoring if you self-manage?

Microsoft references

• Compare self-managed Active Directory Domain Services, Microsoft Entra ID, and managed Microsoft Entra Domain Services, reviewed 5 November 2026.
• New name for Azure Active Directory, including the renamed Domain Services, reviewed 5 November 2026.

This article was first published on 26 September 2020. It was rewritten on 5 November 2026 to use current product names and to match Microsoft's published comparison. Microsoft's live documentation takes precedence if it has changed since.