What Is Azure AD DS? Microsoft Entra Domain Services Explained

What Is Azure AD DS? Microsoft Entra Domain Services Explained

Originally published 26 September 2020 · Reviewed 5 November 2026

Searches for "Azure AD DS" and "Azure Active Directory Domain Services" lead to the same service, which Microsoft now calls Microsoft Entra Domain Services. This article explains what it is, how it works, and the points that surprise people after the first deployment. The service is the same; only the name changed when Azure Active Directory became Microsoft Entra ID.

What Azure AD DS provides

Azure AD DS gives you a managed Active Directory domain without domain controllers that you have to run. Microsoft documents the following services as available in a managed domain:

• domain join for Windows virtual machines;
• Group Policy and a custom organisational unit structure;
• LDAP, including secure LDAP (LDAPS);
• Kerberos and NTLM authentication.

The point is compatibility. Many business applications were written for Windows-integrated authentication or an LDAP bind and cannot use OAuth or OpenID Connect. Moving such an application to an Azure virtual machine normally means standing up domain controllers too. A managed domain removes that extra work.

How it works

When you create a managed domain, you choose a unique DNS namespace and a region, and the platform deploys a pair of Windows Server domain controllers in that region. Microsoft calls the pair a replica set. You do not log on to those controllers, patch them or back them up; the platform does.

Identity flows one way. Users, groups and the credential hashes needed for NTLM and Kerberos are synchronised from Microsoft Entra ID into the managed domain. You can create objects directly in the managed domain, such as organisational units, extra groups or computer accounts, but those objects stay there and are not synchronised back to Microsoft Entra ID.

If your organisation also has an on-premises Active Directory, Microsoft Entra Connect synchronises users from it to Microsoft Entra ID, and the managed domain receives them from Microsoft Entra ID. The managed domain therefore works with cloud-only tenants and hybrid tenants alike, and the feature set is the same for both. In a cloud-only tenant, you do not need any on-premises directory to use it.

What it is not

It is not a domain controller you can promote into your existing forest. Microsoft describes the managed domain as stand-alone, so it has its own namespace, and it does not replicate with on-premises domain controllers. If you need your on-premises users to authenticate to resources in the managed domain, you use the synchronisation path above, or a forest trust where your SKU supports it.

It also does not make Active Directory unnecessary. Microsoft Entra ID, the identity platform behind Microsoft 365, is a separate service for modern authentication and device identity. Azure AD DS sits beside it for legacy protocols.

Limits worth knowing before you build

• No schema extensions and no Domain Admin or Enterprise Admin rights. Administration is delegated through a dedicated administrators group.
• Kerberos constrained delegation is resource-based only. Applications that need account-based delegation will not work.
• Forest trusts need the Enterprise SKU. Plan SKU and cost around that if you need trusts to an on-premises forest.
• Password hashes must reach the domain. For synchronised users, this means password hash synchronisation. If an on-premises domain is federated through AD FS and password hash sync is not enabled, the managed domain has no current hash for those users and cannot validate their credentials.
• Network placement matters. Virtual machines join the domain over the virtual network that hosts it, or a peered network, and need DNS pointed at the managed domain controllers.

Resilience

Because the managed domain runs on at least two domain controllers, it is built to tolerate the loss of one. In regions that support availability zones, Microsoft distributes the controllers across zones. You can also add replica sets in other regions to give legacy applications geographic disaster recovery if a region goes offline. Check the current documentation for the regions and SKUs that support replica sets before you plan around them, because availability changes over time.

When to use it, and when not to

Use a managed domain when the workload needs classic Active Directory protocols and the team does not want to operate domain controllers. Do not use it just because an application "uses AD" if the application can do OpenID Connect or SAML with Microsoft Entra ID, because the domain adds cost, network dependencies and another set of accounts to review.

For a side-by-side decision, read our comparison of the managed domain with self-managed AD DS. For the on-premises and hybrid picture, the key differences article explains where hybrid join fits.

Cost and operations in practice

Entra Domain Services is billed per hour by SKU, so a managed domain that nobody uses still costs money. Treat it like any other always-on Azure resource: tag it, record the owner, and review it when the workloads that justified it are retired. Day to day, expect to spend time on DNS, network peering, Group Policy design and checking that password hashes keep flowing, not on patching. Monitoring still matters, because an unhealthy managed domain breaks every application that depends on it. Review the health page in the Azure portal and alert on it, and test a domain join from a clean virtual machine after any change to the network.

Microsoft references

• What is Microsoft Entra Domain Services?, reviewed 5 November 2026.
• Compare directory-based services, reviewed 5 November 2026.
• New name for Azure Active Directory, reviewed 5 November 2026.

This article was first published on 26 September 2020. It was rewritten on 5 November 2026 with current product names, and it replaces the separate features-and-benefits post, which now redirects here. Microsoft's live documentation takes precedence if it has changed.