Skip to main content

Microsoft Entra Domain Services Guide: Architecture, Use Cases, and Best Practices

Many enterprise applications were built in an era when every server, user, and device was part of a Windows domain. Those applications rely on protocols like LDAP, Kerberos, and NTLM, and on concepts like domain join and Group Policy. Today, cloud‑native identity in Azure revolves around Microsoft Entra ID, which uses modern authentication protocols—OAuth 2.0, OpenID Connect, SAML—and does not provide traditional domain controller functionality.

This creates a gap when organizations migrate legacy workloads to Azure. Rewriting every application to use modern identity protocols is expensive, risky, and often impractical in the short term. Microsoft Entra Domain Services (formerly Azure AD Domain Services) fills that gap. It delivers a managed Active Directory‑compatible domain in Azure, allowing you to run legacy applications without deploying, patching, or maintaining your own domain controllers.

This guide explains the architecture, use cases, and decision framework for Entra Domain Services. It is not a step‑by‑step deployment tutorial; rather, it focuses on helping architects and engineers decide when the service is the right tool—and when it is not.

What Is Microsoft Entra Domain Services?​

Entra Domain Services is a fully managed domain service provided by Microsoft. It deploys a pair of domain controllers in a virtual network, synchronizes identity data (users, groups, password hashes) from your Entra ID tenant, and provides a subset of Active Directory Domain Services (AD DS) capabilities without giving you domain admin or schema admin access.

You can use it to:

  • Domain‑join Azure virtual machines.
  • Authenticate applications using LDAP, Kerberos, or NTLM.
  • Apply basic Group Policy objects (GPOs) to managed resources.
  • Support legacy workloads that cannot be modernized immediately.

The operational model shifts significantly from self‑managed AD DS. The following table summarizes the shared responsibility.

AreaCustomer ResponsibilityMicrosoft Responsibility
Domain availabilityChoose the SKU, region, and networkDeploy and maintain domain controllers (monitoring, patching, disaster recovery of the domain infrastructure)
OS and domain controller patchingNoneAutomatic, transparent
Backup and restoreUnderstand the service’s backup model; plan for application data backupAutomated periodic backups of domain state
Scaling (read replicas)None (single managed domain)Platform provides one writable replica; read replicas are not exposed
Security policies (password, lockout)Configure via Entra ID policiesEnforce on domain controllers
Secure LDAPProvision and manage certificatesMaintain the LDAPS endpoint

Entra ID vs Active Directory Domain Services vs Entra Domain Services​

Understanding the differences between these three identity solutions is fundamental to designing an Azure identity architecture.

CapabilityMicrosoft Entra IDActive Directory Domain Services (AD DS)Microsoft Entra Domain Services
Primary purposeCloud identity provider for users, applications, and devices. Supports modern authentication and SSO for SaaS, Azure, and Microsoft 365.On‑premises directory service for Windows domains. Manages computers, users, policies, and authentication.Managed domain service for Azure that provides a subset of AD DS capabilities, using identities synchronized from Entra ID.
Authentication protocolsOAuth 2.0, OpenID Connect, SAML, WS‑FederationKerberos, NTLM, LDAPKerberos, NTLM, LDAP, and secure LDAP (LDAPS)
LDAP supportNot natively supported; apps must be modernized or use a bridgeFull LDAP supportLDAP read/write support within the managed domain (schema is read‑only, no schema extensions)
Kerberos / NTLMNot supportedFull supportFull support within the managed domain
Domain joinNot supported (Entra ID join is different)Full domain join for Windows devicesDomain join for Azure VMs within the managed domain’s virtual network
Domain controllersNone (directory‑as‑a‑service)Customer‑managed (physical or virtual machines)Microsoft‑managed; two domain controllers are automatically deployed and maintained
Group PolicyNot available (Intune for device management)Full Group Policy managementA limited set of built‑in GPOs; custom GPOs can be created within the managed domain
Schema extensionsNot applicableFull schema adminNot supported; schema is read‑only
Typical use casesCloud‑native applications, SaaS access, Azure resource authentication, Microsoft 365On‑premises enterprise infrastructure, legacy applications, file serversLift‑and‑shift migration, legacy application compatibility in Azure, Azure Virtual Desktop, applications requiring LDAP/Kerberos without self‑managed DCs
Management modelSoftware‑as‑a‑service; Microsoft manages the infrastructureCustomer manages everything (hardware, OS, DCs, replication, backup)Microsoft manages the domain controllers; customer manages applications, VMs, and network

Entra ID is the modern, cloud‑native directory. AD DS is the traditional, self‑managed Windows directory. Entra Domain Services is a compatibility layer: it gives you the protocols of AD DS while Microsoft manages the underlying infrastructure.

Architecture Overview​

Entra Domain Services creates a managed domain in a virtual network of your choice. Two domain controllers are automatically deployed and maintained by Azure. These domain controllers synchronize identity information from your Entra ID tenant—but only for the users and groups you explicitly synchronize. Password hashes must also be enabled in Entra ID (via Password Hash Sync if you use a hybrid setup, or by enabling the feature for cloud‑only users) because Entra Domain Services needs them to perform Kerberos and NTLM authentication.

The synchronization is one‑way: from Entra ID into the managed domain. Objects created directly in the managed domain are not synchronized back to Entra ID. This has important implications:

  • You must create users and groups in Entra ID.
  • Password changes in Entra ID propagate to the managed domain (with some latency).
  • The managed domain’s schema is a subset of AD DS and cannot be extended.

How Entra Domain Services Authentication Works​

When a domain‑joined VM or an LDAP‑aware application needs to authenticate, it communicates with the managed domain controllers inside the virtual network.

  • Kerberos: Used by Windows integrated authentication. The managed domain issues Kerberos ticket‑granting tickets (TGTs) and service tickets just like a traditional AD DS domain.
  • NTLM: Supported for legacy applications that cannot use Kerberos. NTLM authentication is performed against the managed domain controllers.
  • LDAP: Applications can perform LDAP binds and directory searches against the managed domain. This is useful for applications that need to look up user attributes or group memberships.
  • Secure LDAP (LDAPS): You can enable LDAPS by uploading a certificate to the managed domain. LDAPS encrypts LDAP traffic with TLS, which is essential if clients or applications connect from outside the virtual network (e.g., over VPN or ExpressRoute) or if you need to meet compliance requirements.

Because the managed domain controllers are on a dedicated subnet in your virtual network, you must configure Network Security Groups (NSGs) correctly to allow traffic to the necessary ports (e.g., 389 for LDAP, 636 for LDAPS, 88 for Kerberos).

Common Use Cases​

Migrating Legacy Applications to Azure​

A common scenario involves a lift‑and‑shift migration of an internal application that relies on LDAP for authentication and Kerberos for service‑to‑service communication. Instead of deploying and managing a pair of VM domain controllers in Azure, you can enable Entra Domain Services, synchronize the required user accounts, and point the migrated application servers to the managed domain. The application continues to function as before, while the operational burden of domain controller maintenance is eliminated.

Azure Virtual Desktop​

Azure Virtual Desktop (AVD) session hosts often require domain join for user profile management, GPO‑based settings, and Windows authentication. Entra Domain Services can provide this domain without requiring you to deploy dedicated domain controllers or extend your on‑premises AD DS directly into Azure. This is especially useful in cloud‑only or greenfield deployments where you want to avoid maintaining any domain controller infrastructure.

Lift‑and‑Shift Enterprise Applications​

Many enterprise applications—custom Java or .NET Framework apps, legacy SQL Server instances, file servers—were built on the assumption of a Windows domain. Refactoring them to use OAuth or managed identities can take months or years. Entra Domain Services allows you to move these applications to Azure quickly, then modernize them at your own pace.

Hybrid Cloud Migration​

In a hybrid scenario, you already have on‑premises AD DS synchronized with Entra ID via Entra Connect. You can extend this into Entra Domain Services so that the same user accounts are available in the managed domain. This simplifies application migration because the same identities work both on‑premises and in Azure, without building a site‑to‑site VPN extension of your on‑premises domain.

When NOT to Use Entra Domain Services​

Entra Domain Services adds complexity, cost, and a dependency on legacy protocols. You should not use it when:

  • You are building a new cloud‑native application. Use Entra ID directly with OAuth 2.0, OpenID Connect, and managed identities.
  • Your application already supports modern authentication. There is no benefit to introducing LDAP or Kerberos.
  • You need full schema control. Entra Domain Services does not allow schema extensions.
  • You require Enterprise Admin or Domain Admin privileges. The managed domain does not grant these roles.
  • Your workload is entirely container‑based or serverless. Functions, Container Apps, and AKS workloads should use workload identity or managed identities.

A common anti‑pattern is to default to Entra Domain Services for every Azure Virtual Desktop deployment without evaluating whether Entra ID join (with Intune for policy management) meets the requirements. Entra ID join is simpler and does not require domain controllers. Only use Entra Domain Services when you have a hard dependency on legacy protocols or domain join.

Entra Domain Services Architecture Patterns​

Pattern 1: Cloud Migration Pattern​

In this pattern, existing on‑premises identities are replicated to Entra ID, and from there into the managed domain. Migrated applications in Azure use the managed domain for authentication, often communicating over a VPN or ExpressRoute connection for initial data synchronization. Over time, you can modernize or retire the legacy applications.

Pattern 2: Legacy Application Modernization Coexistence​

Modern applications use Entra ID directly, while legacy applications that cannot yet be refactored use Entra Domain Services. Both share the same identity source (Entra ID), so a single user can authenticate to both types of applications with the same credentials. This is a transitional architecture that reduces risk during modernization programs.

Pattern 3: Hybrid Enterprise Identity​

Here, Entra Domain Services acts as a resource domain in Azure, separate from the on‑premises AD DS forest. A trust relationship is not used; instead, identity is synchronized through Entra ID. This pattern avoids the complexity of extending the on‑premises forest to Azure.

Security Considerations​

Introducing LDAP, Kerberos, and NTLM into your Azure environment requires careful attention to security:

  • Least privilege: Only grant the managed domain access to the specific users and groups that need it. Do not synchronize your entire directory unless required.
  • Secure LDAP: Always enable LDAPS if external clients or applications need to perform LDAP operations over the network. Use a valid certificate and rotate it before expiration.
  • Network isolation: Place the managed domain controllers on a dedicated subnet. Use NSGs to restrict access to only the necessary ports and IP ranges. Do not expose domain controller ports to the internet.
  • Monitoring: Enable diagnostic logs for Entra Domain Services and stream them to a SIEM like Microsoft Sentinel. Look for anomalous authentication patterns, brute‑force attempts, or unusual LDAP queries.
  • Administrative accounts: The managed domain includes built‑in groups like “AAD DC Administrators.” Members of this group have administrative privileges on domain‑joined VMs. Manage this group carefully.
  • Password hash synchronization: For cloud‑only users, password hashes are not automatically synchronized to a format that Entra Domain Services can use for NTLM/Kerberos. You must explicitly enable this feature (or use Password Hash Sync in a hybrid setup). Without it, users cannot authenticate.

Networking Requirements​

Entra Domain Services must be deployed into a dedicated subnet within an Azure virtual network. The subnet must be within a specific address range (10.0.0.0/24 or similar) and cannot be used for other resources. DNS settings on the virtual network must point to the managed domain controllers’ IP addresses so that domain‑joined VMs can locate them.

If you need to extend the managed domain to on‑premises environments, you will need a VPN Gateway or ExpressRoute connection. Applications outside Azure that use LDAP will require network connectivity to the managed domain’s virtual network and appropriate NSG rules.

High Availability and Operations​

Entra Domain Services provides built‑in high availability by deploying two domain controllers in an availability set. Microsoft monitors the health of these domain controllers and automatically recovers from failures. The service includes automated backups of the domain state, but these backups are managed by Microsoft and cannot be initiated or restored by the customer directly. For application data, you remain responsible for regular backups.

Because the service is managed, you cannot RDP into the domain controllers, install additional software, or modify the domain schema. This reduces operational toil but also limits your flexibility.

Entra Domain Services vs Running Your Own Domain Controllers​

OptionAdvantagesDisadvantages
Entra Domain ServicesNo domain controller maintenance, automatic patching, integrated identity synchronization, built‑in high availabilityNo schema extensions, no domain admin access, limited GPO customization, cannot extend forest, dependency on Azure network
Azure VM Domain ControllersFull control, schema extensions, trust relationships with on‑premises domains, standard AD DS feature setYou are responsible for OS patching, replication, backup, monitoring, and disaster recovery. Higher operational cost.

Decision criteria:

  • If your application requires only domain join, LDAP, Kerberos, or basic GPOs, Entra Domain Services is usually the better choice because it reduces operational overhead.
  • If you need schema changes, full Group Policy management, or forest trusts, you must deploy your own domain controllers.

Best Practices​

  • Default to Entra ID. Only introduce Entra Domain Services when you have a proven legacy protocol dependency. Do not design new solutions around it.
  • Limit synchronization scope. Synchronize only the organizational units, groups, and users that the legacy applications require. Avoid synchronizing highly privileged accounts unnecessarily.
  • Enable secure LDAP. If any LDAP traffic traverses a network you do not fully control, encrypt it with LDAPS.
  • Isolate legacy workloads. Place applications that depend on Entra Domain Services in a separate virtual network or subnet, and use network controls to segment them from modern services.
  • Document dependencies. Know exactly which applications rely on LDAP, Kerberos, or domain join. This inventory is essential for future modernization efforts.
  • Monitor authentication activity. Anomalies in NTLM or LDAP traffic can indicate misconfiguration or security incidents.
  • Plan for modernization. Entra Domain Services should be a transitional tool. Set timelines and budgets to eventually refactor or replace legacy applications.

Common Mistakes​

  • Using Entra Domain Services as the default identity for all Azure workloads. It is not a replacement for Entra ID. Cloud‑native applications should authenticate with Entra ID directly.
  • Deploying it for applications that only need modern authentication. This adds unnecessary complexity and cost.
  • Ignoring LDAPS requirements. Unencrypted LDAP traffic over the network exposes credentials and directory data.
  • Not validating authentication dependencies before migration. An application that relies on a specific schema attribute or domain trust may fail silently in the managed domain.
  • Misconfiguring DNS. If the virtual network’s DNS settings do not point to the managed domain, domain join and authentication will fail.
  • Assuming that Entra Domain Services provides the same GPO set as on‑premises AD DS. It provides a smaller set of built‑in GPOs; critical policies may need to be replicated manually.

Learning Path​

  1. Understand the fundamentals of Microsoft Entra ID and its tenant model.
  2. Learn the core concepts of Active Directory Domain Services: domains, forests, LDAP, Kerberos, and Group Policy.
  3. Study how Entra Connect synchronizes identities between on‑premises AD DS and Entra ID.
  4. Deploy a test Entra Domain Services instance in a sandbox subscription.
  5. Join an Azure VM to the managed domain and test LDAP and Kerberos authentication.
  6. Configure secure LDAP and verify connectivity from an external client.
  7. Design a migration architecture for a representative legacy application, including network topology, identity synchronization, and a modernization roadmap.

Key Takeaways​

  • Microsoft Entra Domain Services provides a managed Active Directory‑compatible domain in Azure, eliminating the need to run your own domain controllers.
  • It supports LDAP, Kerberos, NTLM, and domain join—protocols that many legacy applications still require.
  • It is not a replacement for Microsoft Entra ID; rather, it is a compatibility bridge for workloads that cannot yet be modernized.
  • Use Entra Domain Services only when you have a proven legacy dependency. For all new applications, prefer Entra ID with OAuth 2.0, OpenID Connect, and managed identities.
  • Plan for modernization: Entra Domain Services reduces operational burden in the short term, but the long‑term goal should be to eliminate the dependency on legacy protocols.

Further Reading​

Official Documentation​