Microsoft Entra Domain Services

Microsoft Entra Domain Services (Entra DS) is a cloud-based managed domain service that provides domain join, Group Policy, LDAP, and Kerberos/NTLM authentication for Azure resources. It is designed for workloads that cannot use modern authentication protocols (like OAuth 2.0 or SAML) and require legacy Active Directory compatibility. Entra DS eliminates the need to deploy, patch, and monitor domain controllers (DCs) while still offering a familiar AD DS environment.

Entra DS is not a replacement for Azure AD or on-premises AD DS. It is a complementary service that bridges the gap between cloud-native identity (Azure AD) and legacy applications that require domain-joined infrastructure. The service runs on Microsoft-managed domain controllers in a customer-selected Azure region, with two domain controllers per instance for high availability. These DCs are fully patched, monitored, and backed up by Microsoft; customers have no direct administrative access to them.

Entra DS synchronizes identity information from Azure AD (or from on-premises AD DS via Azure AD Connect) into a managed domain. The synchronization is one-way only: from Azure AD to Entra DS. Changes made in Entra DS (e.g., password resets) are not written back to Azure AD or on-premises. The managed domain uses a separate, isolated Active Directory forest that is automatically created when you enable the service.

Key internal components: - Managed Domain Controllers: Two DCs per instance, automatically deployed across availability zones in supported regions. They run Windows Server 2019 and are configured with a default domain name (e.g., aaddscontoso.com) or a custom domain name you specify. - Delegated Subnet: When enabling Entra DS, you must create a dedicated subnet within an Azure virtual network. This subnet must be delegated to Microsoft.AAD/DomainServices and cannot contain any other resources. The DCs are placed in this subnet. - Synchronization: User and group objects are synced from Azure AD. Password hashes for NTLM and Kerberos authentication must be enabled in Azure AD (for cloud-only users) or synced from on-premises (for hybrid users). Without these hashes, users cannot authenticate to the managed domain. - Group Policy: A default Group Policy Object (GPO) is created for the AAD DC Computers and AAD DC Users containers. You can create custom GPOs using the Group Policy Management Console (GPMC) on a domain-joined management VM. - LDAP: Both LDAP v3 (port 389) and secure LDAP (port 636) are supported. Secure LDAP requires a certificate and must be explicitly enabled. LDAP can be used for authentication and directory lookups. - Kerberos and NTLM: The managed domain supports these legacy protocols for authentication. Service Principal Names (SPNs) are automatically managed for domain-joined services.

Entra DS is configured entirely through the Azure portal, Azure CLI, or PowerShell. There is no direct access to the DCs.

Azure CLI example to enable Entra DS:

echo "This is a conceptual example; actual commands require specific parameters."
az ad ds create --resource-group myRG --name mydomain.com --domain-configuration-type FullySynced --replica-sets "[{\"location\":\"eastus\",\"subnet-id\":\"/subscriptions/.../subnets/aadds-subnet\"}]"

PowerShell example to check sync status:

Get-AzADDomainService -ResourceGroupName myRG -Name mydomain.com | Select-Object SyncStatus

Verification on a domain-joined VM:

# Check domain membership
Get-ComputerInfo | Select-Object CsDomain

# Verify authentication with Kerberos
klist

# Test LDAP connectivity
Test-NetConnection -ComputerName mydomain.com -Port 389

A financial services company has an on-premises .NET application that uses Windows-integrated authentication (Kerberos) and reads user data via LDAP. They want to migrate this application to Azure IaaS to reduce datacenter costs. The application cannot be rewritten to use OAuth or SAML. By enabling Entra DS in the same VNet as the application VMs, they domain-join the VMs and configure the app to use LDAP (port 389) for authentication. The existing on-premises users are synced to Azure AD via Azure AD Connect, and password hashes are synced. The application works without code changes. Key consideration: The application must support LDAP v3. If it requires schema extensions, Entra DS cannot accommodate that—they would need to deploy traditional domain controllers.

A healthcare organization uses Azure Virtual Desktop (AVD) to provide remote access to legacy Windows-based EHR software. The EHR requires domain-joined session hosts and uses Kerberos authentication. The organization has no on-premises AD DS; they use Azure AD for identity. They enable Entra DS and join the AVD session hosts to the managed domain. Users authenticate to AVD using Azure AD credentials (via Azure AD Join for the AVD host pool), but the EHR uses Kerberos to authenticate against Entra DS. The managed domain provides the necessary legacy authentication. They must ensure that the AVD VMs are in a VNet that can reach the Entra DS delegated subnet. Performance is generally good with two DCs, but they monitor for latency if the VMs are in a different region.

A software company wants to use SQL Server Managed Instance (MI) with Windows authentication. SQL MI can be domain-joined to Entra DS to allow users to connect using their Azure AD credentials (via Kerberos). The company enables Entra DS, creates a SQL MI in the same VNet (or a peered VNet), and configures the MI to use the managed domain. Users in the 'AAD DC Administrators' group can be granted SQL permissions. This eliminates the need to manage SQL logins. A common pitfall: forgetting to configure DNS correctly—the SQL MI must resolve the Entra DS domain name to the DC IPs. Also, the managed domain must be in the same region as SQL MI for best performance.