Microsoft Entra ID versus Active Directory: protocols and migration boundaries
Compare AD DS, Microsoft Entra ID and managed domain services by application protocols, device identity and operating responsibility. Work through a mixed application migration.
TL;DR: Choose an identity service by the protocols and administration model your applications need. Microsoft Entra ID supports cloud identity and modern application access; moving an AD DS account into cloud identity does not rewrite an application's LDAP or domain-join dependency.
Begin with the application, not the product name
An application may use a browser redirect for OpenID Connect sign-in, query a directory through LDAP, or access a Windows service using Kerberos. These operations have different contracts. A matching username in two directories does not make the protocols interchangeable.
AD DS includes domain controllers, directory data and domain-oriented administration. Entra ID is a cloud identity service with application registrations and access policies. Microsoft also offers Entra Domain Services for managed domain capabilities. That third service matters: the similar branding can lead an architecture answer to promise domain-controller behavior from the wrong product.
Microsoft's comparison of AD and Entra ID maps their capabilities. Treat it as a compatibility reference. Current integrations can bridge particular legacy scenarios, so saying Entra can never participate in any Kerberos scenario is also too broad.
| Requirement | Starting point to evaluate | Question that changes the design |
|---|---|---|
| Modern web application sign-in | Entra application integration | Which token claims and authorization rules are required? |
| Existing LDAP-bound application | AD DS or supported domain-service option | Can the application's directory integration change? |
| Traditional domain join and Group Policy | Domain services | Who owns controllers and privileged administration? |
| Cloud-managed Windows endpoint | Entra device identity and Intune | Which enrollment and management capabilities apply? |
| Automation accessing a cloud API | Workload federation or managed identity | Which issuer and workload claims may obtain access? |
Draw identity synchronization separately from authentication
This is an illustrative coexistence design. Synchronization copies selected identity data under configured rules. Authentication can use different methods, each with its own availability dependencies. Identify the source of authority for an attribute before deciding where an administrator should edit it.
A common migration mistake is to conflate an account appearing in Entra with the removal of every on-premises dependency. The legacy service in this diagram still needs its domain path. A successful SaaS sign-in tells you little about that path's health.
Worked migration: payroll, source control and file access
Suppose an organization has a browser-based source-control service, an old payroll application using LDAP, and a Windows file service using domain authentication. The goal is to reduce the infrastructure operated by the identity team.
Move source-control sign-in through a tested modern identity integration. Verify user assignment, token claims, privileged roles and recovery access. That is one migration result, with a measurable scope.
For payroll, ask the vendor whether its deployed version supports a modern authentication option and whether LDAP is also used for group lookups. Changing only sign-in may leave a directory-query dependency behind. If the application cannot change, evaluate supported domain services or retain AD DS with explicit operational ownership. Do not budget controller retirement before this compatibility work finishes.
For file access, test the exact device join state, user identity and service configuration. Newer integrations may support specific access patterns; their prerequisites must be verified against the target environment. A slide saying “everything is in the cloud” cannot replace an authentication trace from an actual client.
Keep separate cutover and rollback plans per application. An organization-wide identity switch combines unrelated failure modes and makes attribution harder. A small application cohort gives support staff a known set of affected users and a bounded recovery path.
Device identity does not prove management
A registered or joined device object is an identity record. Management enrollment gives an MDM service the channel and authority to apply supported policies. Compliance is a further evaluation. These states can differ, as explained in Intune enrollment.
For an interview, state one concrete consequence: a device appearing in Entra is insufficient evidence that Intune successfully applied a required configuration. Inspect enrollment and policy results. For server automation, workload identity federation often addresses credentials more directly than creating another employee-style account.
Microsoft's Entra Domain Services overview documents its managed-domain role and limitations. Validate the required feature against that service before treating it as a replacement for every custom AD deployment.
Explain the remaining dependency
Can synchronized usernames justify deleting domain controllers? No. Inventory LDAP queries, domain joins, service accounts and authentication paths. Retirement requires evidence that the remaining applications and recovery procedures work without those controllers.
What is a convincing migration outcome? Name the application and dependency removed, show the tested access path and identify the systems that still need the old directory. A narrower verified result is more useful than an unsupported claim of complete modernization.
Azure governance follows the resource side of this distinction through management groups, inherited RBAC and policy remediation.