3.6 Integrating Microsoft Entra ID, AD DS & Entra Domain Services: Choosing an Architecture
Key Takeaways
- AD DS speaks Kerberos, NTLM and LDAP to domain-joined machines; Microsoft Entra ID speaks OAuth 2.0, OpenID Connect and SAML to applications and has no LDAP or Kerberos surface of its own.
- Directory synchronisation flows one way, from AD DS to Microsoft Entra ID; only password writeback, device writeback and group writeback move data back on-premises.
- Microsoft Entra Domain Services synchronises from Microsoft Entra ID, not from AD DS directly, so an on-premises change reaches the managed domain only after it has first reached the tenant.
- A verified custom domain in the tenant is required before on-premises UPN suffixes can synchronise; unverified suffixes are rewritten to onmicrosoft.com.
- Choose Entra Domain Services when a legacy application needs Kerberos or LDAP but nobody wants to run domain controllers; choose IaaS domain controllers when schema extensions, forest trusts under your control, or Domain Admin rights are required.
Integrating Microsoft Entra ID, AD DS & Entra Domain Services
The previous five sections each covered one integration technology in isolation. The exam, and real design work, asks a harder question: given a workload, which identity plane should it use, and what does that choice imply about synchronisation, administration and cost. Getting this wrong is expensive — you either run domain controllers you did not need, or you discover mid-migration that the application requires an LDAP bind that Microsoft Entra ID cannot serve.
1. Three Identity Planes, Three Protocol Surfaces
| AD DS (on-premises or IaaS) | Microsoft Entra Domain Services | Microsoft Entra ID | |
|---|---|---|---|
| Protocols | Kerberos, NTLM, LDAP/LDAPS, Group Policy | Kerberos, NTLM, LDAP/LDAPS, Group Policy | OAuth 2.0, OpenID Connect, SAML, WS-Fed, SCIM, Graph |
| Object model | Forest, domains, OUs, extensible schema | Managed domain, custom OUs, fixed schema | Flat tenant — users, groups, service principals, devices |
| Highest privilege you hold | Enterprise Admin / Domain Admin | AAD DC Administrators (no Domain Admin) | Global Administrator |
| Who patches the DCs | You | Microsoft | Not applicable |
| Typical consumer | Domain-joined servers, file shares, legacy line-of-business apps | Lift-and-shift apps needing Kerberos or LDAP with no DC to run | SaaS, modern web APIs, mobile apps, conditional access |
The single most important line in that table is the protocol row. Microsoft Entra ID is not a domain controller. It exposes no LDAP endpoint and issues no Kerberos ticket-granting tickets for arbitrary services, so an application that performs an LDAP simple bind, or a file share that expects Kerberos, cannot be pointed at a tenant no matter how completely its users have been synchronised.
2. The Direction of Flow
Synchronisation is not symmetrical, and the exam tests the asymmetry directly.
Three consequences follow:
- AD DS is the source of authority for synchronised objects. A synchronised user cannot be meaningfully edited in the tenant; the attribute is overwritten on the next sync cycle. Editing must happen on-premises.
- Only three things flow back. Password writeback (self-service password reset), device writeback (Hybrid Entra join scenarios) and group writeback are the exceptions; everything else is one-way.
- Entra Domain Services synchronises from the tenant, never from AD DS. An on-premises password change therefore reaches the managed domain only after it has first synchronised to Microsoft Entra ID — which is exactly why password hash synchronisation must be enabled for a hybrid Entra Domain Services deployment, even if the organisation authenticates with pass-through authentication or federation for everything else.
3. Tenant and Forest Boundaries
| Rule | Consequence |
|---|---|
| One AD DS forest can synchronise to one Microsoft Entra tenant | You cannot split a forest across two tenants during a divestiture without filtering or a second forest |
| One tenant can receive objects from multiple forests | Merger and acquisition topologies are supported without consolidating forests first |
| One active Microsoft Entra Connect Sync server per tenant, plus staging servers | Two active sync servers writing to the same tenant is unsupported and produces attribute thrash |
| Microsoft Entra Cloud Sync agents can run alongside Connect Sync | Provided the two are scoped to disjoint sets of objects |
| A managed domain's DNS name is chosen at creation and is immutable | Choose a routable name you own, distinct from the on-premises domain name |
Custom domains matter more than they first appear. Before an on-premises UPN suffix such as @corp.contoso.com can survive synchronisation, the corresponding domain must be added and verified in the tenant. If it is not, every synchronised user is issued a UPN in the tenant's default <tenant>.onmicrosoft.com namespace, which breaks single sign-on because the user signs in with one name on-premises and a different one in the cloud. The non-routable .local suffix is the classic version of this failure: contoso.local can never be verified, so the forest must be given an alternative routable UPN suffix before synchronisation.
4. The Decision Framework
Work down this list and stop at the first row that matches:
| If the workload needs… | Choose | Because |
|---|---|---|
| Schema extensions, Domain Admin rights, your own forest trusts, or full Group Policy control | Domain controllers in Azure IaaS | Only a forest you own exposes the schema and the top-level administrative groups |
| Kerberos, NTLM, LDAP or Group Policy, but no appetite to run or patch domain controllers | Microsoft Entra Domain Services | Microsoft operates the domain; you administer through AAD DC Administrators and custom OUs |
| Only modern authentication — OAuth, OIDC, SAML — plus conditional access and MFA | Microsoft Entra ID alone | No domain services are needed at all; adding them is pure cost |
| LDAP reads from a cloud-only application, with no on-premises directory at all | Microsoft Entra Domain Services with secure LDAP | Provides an LDAPS endpoint that the tenant itself does not expose |
| Existing on-premises identities extended to cloud applications | AD DS + Entra Connect Sync or Cloud Sync | Keeps AD DS authoritative while projecting identities into the tenant |
[!IMPORTANT] The exam's favourite scenario is a lift-and-shift line-of-business application that performs an LDAP bind and is being moved to Azure, where the customer explicitly states they do not want to manage domain controllers. Microsoft Entra ID cannot serve it; Azure IaaS domain controllers contradict the stated constraint. Microsoft Entra Domain Services is the answer that satisfies both halves of the requirement.
5. Reading the Requirement Correctly
Two phrases in a scenario change the answer entirely:
- "Must not manage domain controllers" / "no patching or backup overhead" points at Entra Domain Services, which is a managed service Microsoft patches and backs up.
- "Must extend the schema" / "requires Domain Admin" / "must establish a trust with a partner forest we control" points at IaaS domain controllers, because Entra Domain Services offers a fixed schema and no Domain Admin or Enterprise Admin membership.
And one phrase is a decoy: "users must sign in with their corporate credentials" is satisfied by every option in the table, because all three planes ultimately draw their identities from the same synchronised set. It never discriminates between architectures on its own.
Contoso is migrating a line-of-business application to Azure. The application performs LDAP simple binds against a directory to validate users. Contoso has Microsoft Entra Connect Sync in place and has stated that it will not deploy or manage any additional domain controllers. Which identity architecture meets both requirements?
An organisation authenticates hybrid users with pass-through authentication and is deploying Microsoft Entra Domain Services so that a legacy application can use Kerberos. Which additional configuration is required for on-premises users to sign in to the managed domain?
After enabling directory synchronisation, all users appear in the tenant with UPNs in the form user@contoso.onmicrosoft.com instead of user@contoso.local. What is the correct remediation?