Microsoft Entra Domain Services - Simply Explained

Microsoft Entra ID is built for modern cloud identity—but what happens when an older application moves to Azure and still expects a traditional Windows domain?In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Microsoft Entra Domain Services and the specific problem it solves. We look at why moving a legacy application into Azure doesn't automatically remove its dependency on LDAP, Kerberos, NTLM, domain join, DNS, and Group Policy—and how Microsoft provides these capabilities without requiring you to operate your own domain controllers.THE CLOUD APP THAT STILL THINKS IT LIVES IN THE SERVER ROOMMoving an application to an Azure virtual machine doesn't necessarily make it cloud-native. Many established Windows applications were designed around Active Directory and still expect to find a traditional domain.They may require LDAP directory lookups, Kerberos authentication, Group Policy, service accounts, or domain-joined Windows servers. Entra ID handles modern cloud authentication extremely well, but it doesn't simply replace every capability of traditional Active Directory.WHY ENTRA ID ALONE ISN'T ALWAYS ENOUGHEntra ID is designed around modern cloud identity. It provides authentication for Microsoft 365, Teams, SharePoint, and modern applications while supporting capabilities such as single sign-on, multi-factor authentication, device-aware access, and access policies.Legacy applications often operate differently. Instead of consuming modern cloud authentication, they expect to communicate directly with a Windows domain using technologies such as LDAP and Kerberos.Organizations can keep their existing Active Directory environment connected to Azure or deploy their own domain controller VMs in Azure—but both approaches introduce infrastructure and operational responsibilities.WHAT MICROSOFT ENTRA DOMAIN SERVICES ACTUALLY ISMicrosoft Entra Domain Services provides a managed Windows domain inside an Azure virtual network.Microsoft operates the underlying domain controllers while Azure workloads can consume traditional Active Directory capabilities. Windows VMs can join the domain, legacy applications can perform LDAP queries, and workloads can use Kerberos and NTLM authentication. DNS and supported Group Policy capabilities are also available.The key distinction is that organizations consume the domain services without managing the domain controller infrastructure themselves.ENTRA ID, ACTIVE DIRECTORY, AND DOMAIN SERVICESThese technologies solve different identity problems.Microsoft Entra ID provides modern cloud identity and authentication.Active Directory Domain Services provides the traditional Windows domain organizations operate themselves.Microsoft Entra Domain Services provides managed traditional domain capabilities for workloads—particularly legacy workloads—running in Azure.Understanding those different roles is critical when designing an Azure identity architecture.THE ONE-WAY IDENTITY MODELOne of the most important architectural concepts is synchronization direction.Users and groups from Entra ID are made available inside Entra Domain Services so legacy applications can consume them. In hybrid environments, those identities may originally come from an on-premises Active Directory environment before reaching Entra ID.But identity changes don't flow back from Entra Domain Services into Entra ID.Users should therefore continue to be managed in their authoritative identity source rather than treating the managed domain as a second primary directory.THE PASSWORD DETAIL THAT CAN SURPRISE YOULegacy authentication protocols require password information in forms that differ from modern cloud authentication.For Kerberos and NTLM authentication to work, Entra Domain Services needs the appropriate protected password information. For cloud-only users, this can mean changing their password after Domain Services has been enabled before they can authenticate successfully against the managed domain.A user can therefore successfully access Microsoft 365 while initially being unable to authenticate against a legacy application using the managed domain.WHEN ENTRA DOMAIN SERVICES MAKES SENSEDomain Services can be particularly useful when migrating applications to Azure that still depend on traditional Windows domain capabilities.Typical examples include applications requiring:LDAPKerberosNTLMWindows domain joinGroup PolicyService accountsDomain authentication for Azure VMsRemote Desktop Services environmentsThe objective isn't to make new applications depend on legacy authentication. It's to provide compatibility for workloads that can't yet move away from it.WHEN YOU SHOULD NOT USE ITEntra Domain Services isn't a replacement for every Active Directory deployment.It isn't appropriate when an application requires LDAP write access, Active Directory schema modifications, direct access to domain controllers, Domain Admin privileges, or a highly customized directory architecture.Those requirements can point toward operating Active Directory yourself rather than using the managed service.THE MANAGED-SERVICE TRADE-OFFThe advantage of Entra Domain Services is reduced infrastructure management.Microsoft operates, patches, synchronizes, and maintains the underlying domain controllers. Organizations don't need to determine where those controllers run or manage their recovery.The trade-off is reduced administrative control.Administrators can't RDP directly into the domain controllers and don't receive Domain Admin or Enterprise Admin privileges. Instead, delegated administration is performed through the Entra Domain Services Administrators group and management systems joined to the domain.You can still perform tasks such as managing supported Group Policy settings, DNS records, organizational units, and domain-joined computers.A PRACTICAL AZURE MIGRATION EXAMPLEImagine a finance application running on-premises that uses LDAP to find employees, Kerberos for authentication, and a Windows service account to communicate with its database.The organization wants to move the application and database into Azure.Keeping the application connected to the on-premises domain introduces dependency on the VPN and local domain controllers. Deploying new domain controllers in Azure creates additional servers that must be patched, monitored, backed up, and recovered.With Entra Domain Services, the organization can instead provide the Azure application with the traditional domain capabilities it requires while Microsoft operates the underlying domain controllers.The legacy application continues working without turning domain controller management into another Azure infrastructure responsibility.PUT ENTRA DOMAIN SERVICES ON YOUR IDENTITY MAPThe simplest way to decide whether Entra Domain Services belongs in your architecture is to examine the applications themselves.Identify workloads requiring LDAP, Kerberos, NTLM, domain join, or Group Policy.Then determine whether each workload should:Modernize and authenticate directly through Entra ID.Remain connected to an existing Active Directory domain.Use Microsoft Entra Domain Services as a managed compatibility layer.If an application requires LDAP write access or Active Directory schema modifications, Entra Domain Services isn't the right solution.Microsoft Entra Domain Services isn't about bringing traditional Active Directory architecture to every cloud workload. It's about giving legacy Azure workloads the Windows domain services they still require—without forcing your team to operate the domain controllers themselves.Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.