AD DS vs Microsoft Entra ID

Link to Introduction: Why the AD DS vs Entra ID Question MattersIntroduction: Why the AD DS vs Entra ID Question Matters

For developers and identity engineers, clearly understanding the distinction between Active Directory Domain Services (AD DS), Microsoft Entra ID, and Entra Domain Services is a prerequisite to making durable architectural decisions. Directory services underpin authentication, access management, and application integration across nearly every enterprise environment. Relying on imprecise assumptions can derail LDAP integrations, introduce authentication gaps, and limit cloud transformation initiatives.

The common misconception—treating Microsoft Entra ID as simply “Active Directory in the cloud”—can send even experienced practitioners down costly technical dead-ends. Developers building authentication for Node.js or TypeScript apps, or integrating legacy Windows applications, face different realities depending on which directory technology they target. This article confronts these distinctions head-on, mapping the protocols, administrative models, and hybrid architectures that separate these identity platforms. The result: a concrete, defensible guide for choosing and integrating AD DS, Entra ID, or hybrid approaches.

Link to Foundational Comparison: What Are AD DS, Entra ID, and Entra Domain Services?Foundational Comparison: What Are AD DS, Entra ID, and Entra Domain Services?

Link to Active Directory Domain Services (AD DS)Active Directory Domain Services (AD DS)

AD DS is Microsoft’s on-premises directory service, typically deployed on Windows Server as domain controllers. It uses classic protocols—LDAP for directory queries and management, Kerberos for authentication, and NTLM for legacy support. AD DS manages users, groups, devices, Group Policies, and uses Organizational Units (OUs) for delegation and structured administration. It is tightly coupled to Windows networking and traditional corporate environments.

Link to Microsoft Entra IDMicrosoft Entra ID

Microsoft Entra ID, formerly known as Azure Active Directory, is a multitenant cloud identity provider (IDaaS). Built as a cloud-native service, it is architected for distributed, internet-reachable authentication and identity management. Entra ID supports modern authentication and authorization protocols including OpenID Connect (OIDC), OAuth 2.0, and SAML—all HTTP-based and built for federation, SaaS, and cloud application scenarios. Entra ID does not run on Windows Server, does not provide domain controllers or LDAP endpoints for direct classic application compatibility, and cannot process legacy protocols natively.

Link to Microsoft Entra Domain Services (Entra DS)Microsoft Entra Domain Services (Entra DS)

Entra Domain Services is a managed domain service that bridges some legacy gaps in Azure. It exposes LDAP, Kerberos, and NTLM protocols as a managed offering, sourcing identities from Entra ID via one-way synchronization. Entra DS enables certain legacy applications and workloads designed for AD DS to function in a cloud context. However, it restricts administrative capabilities (no schema extension, limited trust relationships, restricted policy management) and is not a full AD DS replacement.

Link to Architectural ViewArchitectural View

AD DS and Entra ID sit at opposite ends of the identity spectrum: AD DS embeds deeply in on-prem systems, while Entra ID is cloud-optimized, protocol-flexible, and SaaS-native. Entra Domain Services acts as a compatibility glue, not as a true “cloud port” of AD DS.

Link to Authentication and Protocol Support: How Do They Differ?Authentication and Protocol Support: How Do They Differ?

Link to AD DS AuthenticationAD DS Authentication

• Kerberos and NTLM: Primary methods for Windows integrated authentication and legacy application support.
• LDAP Bind: Essential for many enterprise and cross-platform integrations. Applications requiring directory queries or simple username/password authentication typically target LDAP.
• Integration Pattern: Applications connect using domain credentials (service accounts), or leverage SPNEGO/SSPI APIs for SSO on Windows devices.

Link to Entra ID AuthenticationEntra ID Authentication

• OAuth 2.0, OIDC, SAML: Core protocols for web applications, APIs, federated SSO, and modern device login flows.
• MFA and Phishing-Resistant Auth: Entra ID natively supports advanced methods like Passkeys and Windows Hello for Business, which are not available in AD DS.
• No Native LDAP/Kerberos/NTLM: You cannot bind over LDAP directly to Entra ID, nor join Windows clients to it as you would to a traditional domain. Integration and authentication patterns depend on HTTP-based protocols and token exchanges.

Link to Microsoft Entra Domain ServicesMicrosoft Entra Domain Services

• LDAP, Kerberos, NTLM: Provides these via Azure-managed domain controllers, with user and group data flowing one-way from Entra ID.
• Application Support: Allows legacy applications in Azure to authenticate using classic protocols, but with administrative limitations.

Link to Protocol Support TableProtocol Support Table

Crucially for developers: If your target system requires LDAP binds or Kerberos/NTLM authentication, neither Entra ID nor Entra DS is a drop-in replacement for AD DS in all scenarios. Only Entra DS offers legacy protocol support in the cloud, and even then with restrictions.

Link to Administrative Models: OUs and GPOs versus RBAC and Admin UnitsAdministrative Models: OUs and GPOs versus RBAC and Admin Units

Link to AD DSAD DS

• Organizational Units (OUs): Provide granular scoping for delegation and policy application.
• Group Policy Objects (GPOs): Enforce configuration and security policies across domain-joined devices, users, and groups.
• Delegation: Admin rights can be scoped at OU or group level, allowing complex delegation hierarchies.

Link to Microsoft Entra IDMicrosoft Entra ID

• Role-Based Access Control (RBAC): Management and resource permissions are delegated via Azure roles and scopes.
• Administrative Units (AUs): Provide containment for scoping management of users, groups, and devices, with delegated admin rights—but do not match OUs in flexibility or device policy reach.
• Conditional Access: Policy engine for authentication and access control, replacing many client-side GPO use cases in the cloud.
• No GPO/OUs/Classic Device Management: Devices cannot be managed via domain OUs or classic GPO from Entra ID alone.

Link to Entra Domain ServicesEntra Domain Services

• Subset of AD DS Admin Model: OUs and GPOs are present, but schema extension, Forest/Domain trust setup, and certain advanced roles are not supported.

Developer consequence: Moving from AD DS to Entra ID shifts management from a device- and location-oriented model to an identity- and role-centric model. Application configuration and policy enforcement for classic Windows is not preserved natively.

Link to Hybrid Identity: Synchronization, SSO, and Realistic LimitationsHybrid Identity: Synchronization, SSO, and Realistic Limitations

Link to Synchronization MechanismsSynchronization Mechanisms

• Microsoft Entra Connect: Used to synchronize users, groups, and (optionally) devices from AD DS to Entra ID.
• Password Hash/Pass-Through Authentication: Determine how user authentication flows are handled between on-prem AD DS and cloud services.

Link to Limitations and BoundariesLimitations and Boundaries

• One-Way Sync: Entra DS synchronizes from Entra ID only; changes within Entra DS do not propagate back to Entra ID.
• Not All Data Is Synced: Certain attributes and structures, like detailed OU hierarchies or some device objects, are not fully represented in the cloud.
• Hybrid SSO: Enables seamless user experience, but integration requires careful consideration—especially with password write-back, device state, and legacy authentication methods.

Gotchas for Developers:

• Password changes outside the prescribed flow may not sync as expected.
• Applications needing LDAP authentication may require Entra DS even when Entra ID is present.
• Device-joined states (domain join vs. Azure/Entra Join) affect token issuance and available SSO mechanisms.

Link to When to Use Which: Common Scenarios and Migration CaveatsWhen to Use Which: Common Scenarios and Migration Caveats

Link to AD DS is required when:AD DS is required when:

• Applications or services require direct LDAP, Kerberos, or NTLM integration.
• You must manage classic Group Policies, OUs, or domain trust relationships.
• Legacy on-premises workloads are the norm.

Link to Entra ID is sufficient when:Entra ID is sufficient when:

• All application integrations can be done via OAuth2, OIDC, or SAML.
• Device management, authentication, and access policies can be managed with Conditional Access, Intune, and cloud-native controls.
• No need exists for domain join, GPOs, or classic protocol application support.

Link to Entra Domain Services is necessary when:Entra Domain Services is necessary when:

• Applications require LDAP/Kerberos/NTLM authentication but must run in Azure without on-prem AD DS.
• Partial AD DS compatibility is needed but with acceptance of administrative and schema limitations.

Link to Checklist for DecisionChecklist for Decision

• Legacy LDAP or Windows Integrated Auth? => AD DS or Entra DS
• Modern SaaS/Web integrations only? => Entra ID
• Hybrid cloud/on-prem auth required? => AD DS + Entra ID with Entra Connect
• Require GPOs and advanced delegation? => AD DS

Link to Persistent Misconceptions (and Their Corrections)Persistent Misconceptions (and Their Corrections)

• Myth: Microsoft Entra ID is “Active Directory in the cloud.”

  • Fact: Entra ID is architecturally distinct from AD DS—built for HTTP-based protocols, cloud-native identities, and lacks classic device and policy management features.

• Myth: Entra ID can natively manage OUs, GPOs, or classic LDAP applications.

  • Fact: These functionalities are not present in Entra ID. Only AD DS or Entra Domain Services (with restrictions) offer such capabilities.

• Myth: Entra DS synchronizes bi-directionally with Entra ID.

  • Fact: Synchronization is strictly one-way—from Entra ID into Entra DS. Changes in Entra DS do not sync back.

• Myth: Synchronizing AD DS to Entra ID makes all AD DS capabilities available in the cloud.

  • Fact: Synchronization enables hybrid identity and SSO, but cloud-native limitations persist: no device join, GPOs, or classic protocol support unless using Entra DS.

Link to Summary Table: Decisive Technical ComparisonSummary Table: Decisive Technical Comparison

Link to Further Reading and Authoritative ResourcesFurther Reading and Authoritative Resources

For detailed, implementation-level insights and scenario guidance, consult the following Microsoft documentation:

• Compare Active Directory to Microsoft Entra ID
• Directory synchronization with Microsoft Entra ID
• Microsoft Entra authentication overview
• How synchronization works in Microsoft Entra Domain Services
• Microsoft Entra ID - Domain Services: Compare identity solutions
• Authentication vs. authorization - Microsoft identity platform
• Difference between Microsoft Entra ID and Entra Domain Services

These sources are canonical references for technical planning, architecture, and limitations. Always consult them directly to verify integration capabilities and constraints for your specific scenarios.

Link to SourcesSources

• learn.microsoft.com — compare
• learn.microsoft.com — sync-directory
• learn.microsoft.com — overview-authentication
• learn.microsoft.com — synchronization
• learn.microsoft.com — compare-identity-solutions
• learn.microsoft.com — authentication-vs-authorization
• learn.microsoft.com — difference-between-microsoft-entra-id-and-entra-do