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 ROOM
Moving 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 ENOUGH
Entra 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 IS
Microsoft 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 SERVICES
These 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 MODEL
One 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 YOU
Legacy 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 SENSE
Domain Services can be particularly useful when migrating applications to Azure that still depend on traditional Windows domain capabilities.Typical examples include applications requiring:
• LDAP
• Kerberos
• NTLM
• Windows domain join
• Group Policy
• Service accounts
• Domain authentication for Azure VMs
• Remote 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 IT
Entra 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 privilege...
