3.5 Microsoft Entra Domain Services
Key Takeaways
- Microsoft Entra Domain Services provides managed Active Directory domain controllers as a cloud PaaS service, supporting Kerberos, NTLM, LDAPS, DNS, and Group Policy without managing IaaS VMs.
- Directory synchronization operates strictly one-way from Microsoft Entra ID to Entra Domain Services; objects created in the managed domain never replicate back to Entra ID or on-premises AD DS.
- Secure LDAP (LDAPS) requires a valid .PFX certificate containing the domain DNS name or wildcard, external DNS records, and an NSG rule permitting inbound TCP port 636 from authorized management IP ranges.
- To support multi-region disaster recovery and low-latency cloud authentication, up to five replica sets can be deployed across distinct Azure regions in peered Virtual Networks.
- Administrative access is restricted to the AAD DC Administrators group with delegated control over AADDC Users and Computers OUs; Domain Admins, Enterprise Admins, and Schema Admins roles do not exist.
Microsoft Entra Domain Services
Many enterprise workloads and legacy line-of-business applications migrating to Microsoft Azure rely on traditional Active Directory protocols—such as Kerberos authentication, NTLM, Lightweight Directory Access Protocol (LDAP/LDAPS), DNS name resolution, and Group Policy Objects (GPOs). However, deploying, patching, backing up, and securing dedicated Windows Server domain controller virtual machines in Azure IaaS introduces significant administrative overhead.
Microsoft Entra Domain Services provides fully managed domain services in Azure as a Platform-as-a-Service (PaaS) solution, delivering full protocol compatibility with legacy Active Directory without requiring administrators to manage domain controller infrastructure.
1. Managed Domain Architecture & Synchronization Flow
When Microsoft Entra Domain Services is provisioned, Azure deploys two redundant managed domain controllers into a dedicated subnet within an Azure Virtual Network (VNet).
+-----------------------------------------------------------------------------------+
| MICROSOFT ENTRA DOMAIN SERVICES ARCHITECTURE & FLOW |
| |
| [On-Premises AD DS] -----> (Entra Connect) -----> [Microsoft Entra ID] |
| | |
| (One-Way Sync) |
| v |
| +------------------------------------------------------------------------------+ |
| | AZURE VIRTUAL NETWORK | |
| | +------------------------------------------------------------------------+ | |
| | | Dedicated Subnet: aadds-subnet (No other VMs or NICs allowed) | | |
| | | [Managed DC 01] [Managed DC 02] | | |
| | | - Kerberos / NTLM - Kerberos / NTLM | | |
| | | - LDAP / Secure LDAPS (TCP 636) - LDAP / Secure LDAPS (TCP 636) | | |
| | | - DNS Server - DNS Server | | |
| | +------------------------------------------------------------------------+ | |
| | | (VNet Peering) | |
| | +------------------------------------------------------------------------+ | |
| | | Application Subnet: Workload VMs (Joined to aadds.contoso.com) | | |
| | | [Legacy App VM 01] [Legacy App VM 02] | | |
| | +------------------------------------------------------------------------+ | |
| +------------------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------------+
Core Architectural Principles:
- Dedicated Subnet Requirement: The managed domain controllers must be deployed in a dedicated subnet inside an Azure VNet. This subnet cannot contain standard workload VMs, storage endpoints, or other network interfaces.
- One-Way Unidirectional Synchronization: Identity data synchronizes strictly from Microsoft Entra ID into Microsoft Entra Domain Services.
- Objects (users, groups, credentials) created in Entra ID (or synced from on-premises AD DS) appear in Entra Domain Services.
- Critical Rule: You cannot create users or groups directly in Entra Domain Services and have them sync back to Entra ID or on-premises AD DS. The cloud directory is the authoritative master.
- Supported Protocols: Windows and Linux IaaS VMs joined to the managed domain can authenticate via Kerberos or NTLM, perform directory searches via LDAP/LDAPS, query domain DNS, and apply Group Policy Objects (GPOs).
Comparison: Entra Domain Services vs. IaaS Domain Controllers vs. Entra ID
| Dimension | Microsoft Entra ID | Entra Domain Services | Windows Server IaaS DCs |
|---|---|---|---|
| Service Model | Identity-as-a-Service (Cloud) | Platform-as-a-Service (Managed) | Infrastructure-as-a-Service (VMs) |
| Primary Protocols | OAuth 2.0, OIDC, SAML, WS-Fed | Kerberos, NTLM, LDAP/LDAPS, DNS | Kerberos, NTLM, LDAP/LDAPS, DNS |
| Device Joining | Entra Joined / Registered | Domain Joined (Traditional AD) | Domain Joined (Traditional AD) |
| Group Policy Support | None (Intune MDM policies) | Yes (Built-in & Custom GPOs) | Yes (Full GPO control) |
| Schema Extensions | Directory Extension Attributes | No (Schema is locked) | Yes (Full Schema Admin) |
| Administrative Scope | Global / Identity Administrator | AAD DC Administrators Group | Domain / Enterprise Admins |
| Forest Trust Support | None | One-Way Outbound (Resource Forest) | Two-Way / Transitive Trusts |
2. Password Hash Synchronization Prerequisites for Entra Domain Services
Kerberos and NTLM authentication require password hashes in legacy cryptographic formats (NTLM hashes and Kerberos keys). Microsoft Entra ID does not generate or store NTLM/Kerberos credential hashes by default for standard cloud authentication.
+-----------------------------------------------------------------------------------+
| PASSWORD HASH GENERATION REQUIREMENTS |
| |
| [1. HYBRID SYNCHRONIZED ACCOUNTS] |
| - Must have Password Hash Synchronization (PHS) enabled in Entra Connect. |
| - Entra Connect extracts and syncs NTLM hashes to Entra ID. |
| - Hashes are then automatically populated into Entra Domain Services. |
| |
| [2. CLOUD-ONLY USER ACCOUNTS] |
| - Entra ID does NOT have legacy NTLM hashes for cloud-created users. |
| - Cloud users MUST change or reset their password once via Azure Portal |
| or SSPR to generate and store the required NTLM/Kerberos hashes. |
+-----------------------------------------------------------------------------------+
[!IMPORTANT] Cloud User Password Change Requirement: After enabling Microsoft Entra Domain Services, cloud-only user accounts cannot authenticate to the managed domain until they perform a password change or reset. Changing the password triggers the cloud authentication service to compute and store the legacy NTLM hash required by the managed domain controllers.
3. Secure LDAP (LDAPS) Configuration & Hardening
To allow applications hosted in external VNets, on-premises networks, or over the Internet to query the managed domain, Secure LDAP (LDAPS / TCP port 636) must be configured.
+-----------------------------------------------------------------------------------+
| SECURE LDAPS DEPLOYMENT STEPS |
| |
| [1. OBTAIN CERTIFICATE] ---> .PFX containing private key, Key Length >= 2048-bit|
| Subject / SAN: *.aadds.contoso.com or exact FQDN |
| | |
| v |
| [2. ENABLE IN PORTAL] ---> Upload .PFX to Entra Domain Services blade |
| Toggle: "Secure LDAP" = Enabled |
| Toggle: "Allow Secure LDAP access over Internet" |
| | |
| v |
| [3. EXTERNAL DNS] ---> Create public DNS A record (ldaps.contoso.com) |
| pointing to the external IP displayed in portal |
| | |
| v |
| [4. NSG LOCKDOWN] ---> Inbound Rule: Allow TCP 636 from specific |
| management IP addresses only (Deny 0.0.0.0/0) |
+-----------------------------------------------------------------------------------+
Certificate Prerequisites:
- Format: PKCS#12 (
.pfx) file containing the private key and full certificate chain. - Subject Name / SAN: Must match the managed domain's DNS name (e.g.,
aadds.contoso.com) or use a wildcard matching the domain (e.g.,*.aadds.contoso.com). - Trust: Must be issued by a trusted public Certificate Authority (CA) or an enterprise internal CA whose root certificate is installed on all querying client machines.
Network Security Group (NSG) Rule Configuration:
When external LDAPS is enabled, Azure assigns an external public IP address to the managed domain controllers. You must configure an NSG rule on the dedicated subnet:
- Protocol: TCP
- Destination Port: 636
- Source: Restrict strictly to authorized corporate public IP CIDR ranges. Never leave source set to
Any(0.0.0.0/0) to prevent LDAP brute-force and amplification attacks.
4. Multi-Region Resilience: Replica Sets
For enterprise workloads distributed across multiple Azure regions, Microsoft Entra Domain Services supports Replica Sets.
+-----------------------------------------------------------------------------------+
| MULTI-REGION REPLICA SET ARCHITECTURE |
| |
| +-----------------------------+ +-----------------------------+ |
| | PRIMARY REGION: EAST US | | REPLICA REGION: WEST US | |
| | Subnet: 10.10.0.0/24 | | Subnet: 10.20.0.0/24 | |
| | [Managed DC 01] [Managed DC 02] | [Replica DC 01] [Replica DC 02] |
| +-----------------------------+ +-----------------------------+ |
| ^ ^ |
| |========== (Azure VNet Peering) =============| |
| (AD DS Intra-Domain Replication) |
+-----------------------------------------------------------------------------------+
Key Capabilities of Replica Sets:
- Multi-Region Redundancy: Deploy up to 5 replica sets (1 primary + 4 replicas) across distinct Azure regions sharing the same managed domain namespace.
- Low Latency: Workload VMs in secondary regions authenticate locally against replica domain controllers rather than traversing cross-region VNets.
- VNet Peering Requirement: All VNets hosting replica sets must be connected using full-mesh Azure Virtual Network Peering to allow intra-domain Active Directory replication between managed domain controllers.
5. Administrative Model & Hard Limitations
Microsoft Entra Domain Services enforces strict administrative boundaries to maintain PaaS platform integrity.
The AAD DC Administrators Group:
Members of this built-in group receive delegated administrative rights:
- Join virtual machines to the managed domain.
- Access and manage the
AADDC ComputersandAADDC UsersOrganizational Units (OUs). - Create and manage custom child OUs, custom Group Policy Objects (GPOs), and DNS records using standard Remote Server Administration Tools (RSAT).
Hard Platform Boundaries (Critical Exam Traps):
- No Domain Admins or Enterprise Admins: You are never granted
Domain AdminsorEnterprise Adminsgroup membership. - No Schema Extensions: The Active Directory schema is locked; third-party applications requiring schema modifications cannot be installed.
- No Direct RDP/SSH to Domain Controllers: Administrators cannot establish Remote Desktop or PowerShell remoting sessions directly to the underlying managed domain controller VMs.
- Trust Creation (SKU Dependent): Standard managed domains do not support creating domain trusts. However, the Enterprise / Resource Forest SKU supports creating a one-way outbound forest trust from Entra Domain Services to an on-premises Active Directory forest, allowing on-premises users to access cloud resources using Kerberos without syncing user passwords to the cloud.
An enterprise is planning to deploy Microsoft Entra Domain Services to support legacy applications hosted on Azure IaaS virtual machines. The security team requires that all administrators have the ability to manage DNS records, join VMs to the domain, and create custom Group Policy Objects, while ensuring compliance with platform administrative boundaries. Which group should the administrators be added to?
After deploying Microsoft Entra Domain Services for an organization with cloud-only user accounts, developers report that they cannot sign into domain-joined Azure virtual machines using their cloud credentials. Synced users from on-premises AD DS can sign in successfully. What action is required to enable cloud-only users to authenticate?
A network security team needs to enable Secure LDAP (LDAPS) over the Internet for a Microsoft Entra Domain Services managed domain 'aadds.contoso.com'. Which set of configuration steps is required to satisfy security and certificate requirements?
An architect is designing a high-availability deployment of Microsoft Entra Domain Services across two Azure regions: East US (primary) and West US (secondary). Workload VMs in West US must authenticate locally against domain controllers with minimal latency. What architecture must be implemented?