AD DS, Entra ID, Entra Domain Services, and AD FS: Separating the products and their boundaries

1. Core mechanism

When reading a hybrid environment, ask which authority makes which decision over which protocol; the user's location alone doesn't describe the trust boundary. AD DS offers LDAP, Kerberos, NTLM, and Group Policy at the forest/domain boundary. Entra ID issues tokens at a tenant boundary using protocols such as OAuth 2.0, OpenID Connect, and SAML. Entra Domain Services provides domain join, LDAP, Group Policy, and Kerberos/NTLM to legacy applications through domain controllers deployed in the Azure region and managed by Microsoft; Entra ID is the source for identities synchronized into that domain. AD FS is a separate on-premises authentication system to which Entra ID delegates sign-in validation.

Interfaces and specifications

• AD DS: a directory service operated by the organization. Objects are kept in forest and domain naming contexts; clients use LDAP, Kerberos, and NTLM and receive configuration through Group Policy. Schema, replication, and DC operations belong to the organization.
• Microsoft Entra ID: cloud identity provider operating at the tenant border. It gives tokens to applications, and cloud controls such as Conditional Access are evaluated here. It is not a cloud copy of AD DS's LDAP/Kerberos/Group Policy surface.
• Microsoft Entra Domain Services: a managed domain created with a unique namespace. Microsoft deploys and manages two Windows Server domain controllers as a replica set in the selected Azure region; customers don't deploy, configure, patch, or monitor those DCs. Entra ID is the source for identities synchronized into this managed domain.
• The managed domain receives one-way synchronization from Entra ID. LDAP write is supported for objects created in custom OUs within the managed domain, but not for objects synchronized from Entra ID.
• AD FS: an on-premises federation service configurable with Entra Connect. For federated sign-in, Entra ID delegates validation to a trusted authentication system such as AD FS; the organization operates the AD FS farm, WAP servers, and certificates.

Four products, four different authorities

It is easy to draw an “AD” box in an environment diagram, but leaving its decision authority undefined can undermine the risk analysis. AD DS is a directory and authentication service: account objects live there, domain controllers issue Kerberos tickets, and Group Policy distributes machine configuration. Entra ID is also a directory service, but it manages application access with tokens; it doesn't emulate AD DS's LDAP/Kerberos/Group Policy surface.

Entra Domain Services is a separate managed domain that provides familiar AD DS capabilities in Azure. Microsoft deploys and operates its domain controllers, so the customer doesn't deploy or manage those DCs. Entra ID is the source for synchronized users and groups, and synchronization is one-way: changes to synchronized objects in the managed domain don't flow back to Entra ID or on-premises AD DS.

AD FS is the fourth and often-confused component. Federation is a trust relationship that delegates sign-in validation, not a directory. When a domain is federated, Entra ID delegates validation to a trusted authentication system, typically on-premises AD FS. AD FS participates in issuing a federation assertion; Entra ID validates the assertion before issuing its own token.

Keep synchronization paths separate. Entra ID → Domain Services has no return path. Supported SSPR password changes can travel Entra ID → on-premises AD DS only when the separate writeback feature is configured; this does not make managed-domain objects or arbitrary cloud changes flow back.

The protocol surface determines the product

To understand which product an application needs, examine the protocol it uses rather than starting from a product name. A legacy application that requires LDAP bind, a Kerberos SPN, or domain join can't meet those requirements by using Entra ID's OIDC/OAuth token surface alone. Microsoft Learn describes Domain Services as a lift-and-shift option for Azure workloads that depend on LDAP, Kerberos, NTLM, Group Policy, or domain join and can't be modernized.

The reverse is also true: when Entra ID is sufficient for a modern SaaS application, adding Domain Services can expose an unnecessary AD DS protocol surface. Microsoft positions this service for Azure workloads that require legacy authentication, not as a general replacement for on-premises AD.

In a design review, the question “which product are we using?” is insufficient on its own. Record each workload's protocol requirements, decision authority, and source of identity objects separately.

The management boundary is a security boundary

Microsoft manages the managed domain's domain controllers; customers don't configure, patch, or monitor those DCs. This reduces operational work but also means customers don't have the same administrative access they have in self-managed AD DS. LDAP write is supported for objects created in custom OUs within the managed domain, not for objects synchronized from Entra ID.

With AD FS, the organization operates the farm servers, token-signing certificates, claim rules, and WAP layer. Microsoft Learn documents certificate renewal and trust recovery as separate operational procedures. AD FS is therefore a critical on-premises dependency and a distinct attack surface for user authentication.

For each product, record three things: who hosts the object, who makes the decision, and who manages the infrastructure. These boundaries can belong to different parties and should be tracked separately.

State and data flow

1. A legacy application requires LDAP bind or domain join. This request goes to AD DS or the Entra Domain Services managed domain; Entra ID's OIDC/OAuth surface does not meet this request.
2. A modern application requests an Entra token. In the illustrative federated path, AD FS authenticates the user and signs a SAML assertion; Entra ID validates it before issuing its own token.
3. User, group and identity information in the managed domain comes from Entra ID with one-way synchronization. In the hybrid environment, on-premises AD DS data is first synchronized to Entra ID and from there reaches the managed domain.
4. An object created in a custom OU within the managed domain can be written through LDAP; the same write path isn't supported for an object synchronized from Entra ID. Check both the object's source and its OU.

2. Exploitation

Broken trust assumption

Treating Entra ID, AD DS, Entra Domain Services and AD FS as one interchangeable product, with the same protocols, administrative rights and synchronization paths.

Technical prerequisites

• Inventory and architecture diagrams bring all identity components into a single “AD” box; authority, protocol and administrative ownership are not written as separate fields.
• It is not documented which protocol legacy applications talk to; LDAP/Kerberos dependency and modern token flow are discussed under the same heading.
• It does not appear in risk records that user authentication of a federated domain depends on on-premises AD FS and managed domain synchronization is one-way.

Exploitation mechanism

A change in an Entra Domain Services managed domain does not flow back to Entra ID or on-premises AD DS. For synchronized objects, attempting the same LDAP write used for a locally created custom-OU object is unsupported. Editing the managed domain therefore cannot repair its source. A separately configured Entra password-writeback feature can send supported SSPR password changes to on-premises AD DS through Connect Sync or Cloud Sync; that is a different path, not general two-way synchronization and not a Domain Services feature. Administrative ownership is another boundary: Microsoft operates managed-domain DCs, while the organization operates its AD FS farm. In the illustrative federated path, AD FS validates the user and signs a SAML assertion; Entra ID validates that assertion before issuing its own token. The farm’s availability and signing configuration matter even though it is not a directory.

Delegated verification, transferred risk

In the AD FS example, the farm authenticates the user and produces a signed SAML assertion. Entra ID validates the assertion and issues its own token; those are separate decisions. The farm servers, token-signing certificates and claim rules belong in the trust review because they determine what the federation service asserts, not because AD FS issues the Entra application token.

This course does not teach a method of executing an attack. On the defense side, the correct framework is this: in a federated tenant, the AD FS farm should be considered tier 0, and certificate and trust repair procedures should be defined as authorized and monitored processes. The same review is done for the migration plan to cloud authentication options.

Wrong product selection opens new protocol surface

While Entra ID is sufficient for a modern application, adding a managed domain to the environment is not only a cost but also an attack surface decision: LDAP, Kerberos/NTLM and Group Policy surfaces are also opened in Azure. Microsoft describes this service as migration capability for legacy-dependent workloads; It is recommended that cloud-native applications use Entra ID directly.

Conversely, forcing an application that expects LDAP bind to run with Entra ID alone often results in the application being wrapped in a weak middleware. The common root of both errors is the same: the lack of documentation of the protocol and authority differences between the products.

3. Defense & Detection

Telemetry scope

• Keep separate lines for each identity component: AD DS forest/domain, Entra tenant, Entra Domain Services managed domain namespace if any, and AD FS farm if any. Each line must have separate fields for authority, protocol surface and management owner.
• Record whether the sign-in method for each domain is managed or federated; If it is federated, which on-premises system the verification is transferred to and the certificate renewal schedule of that system should be monitored separately.
• For a managed domain, record both the source and OU of objects: objects created in custom OUs and objects synchronized from Entra ID don't have the same write behavior.
• Write the protocol (LDAP, Kerberos, NTLM, domain join, OIDC/OAuth/SAML) that each application speaks in the Legacy application inventory; Derive your product selection from this field.
• Record configured password writeback separately from managed-domain synchronization, including its source, target and supported change scope.

Events and relevant fields

• Just because an account appears in Entra ID does not indicate that that account has the same privileges in on-premises AD DS; The authority model of the two parties is evaluated separately.
• A Group Policy or LDAP behavior observed in a managed domain is not evidence of on-premises AD DS configuration. A managed domain is a separate namespace and a separate replica set.
• In a federated domain, cloud sign-in error may be related to the accessibility or certificate status of the transferred on-premises component rather than a failure on the cloud side.
• Since the flow from Entra ID to the managed domain is one-way, missing an object from the managed domain may mean “out of scope at the source” rather than “deleted”.

Write inventory with skill, not product name

The most common problem that operations teams encounter is the uncertainty on which side an incident will be resolved. If there is only the product name in the inventory, an LDAP error and a token error will fall on the same team with the same priority. Capability-based inventory solves this: for each component, supported protocols, source of objects, and writability behavior are written.

This approach also works in a privilege review. The management group model that is valid in on-premises AD DS is not the same in the managed domain; DCs are managed by Microsoft. Therefore, the sentence "We performed a Domain Admin audit" is meaningless without specifying which domain is being mentioned.

Separate the chain of evidence in cases that cross borders

When a user can't log into the cloud application, the issue could be in four different places: on-premises account status, sync scope, delegated authentication component, or cloud policy evaluation. These layers have separate sources of evidence and do not replace each other.

Therefore, in the case study, first the sign-in method of the domain, then the source of the object, and then the health status of the relevant component are read. When the chain of evidence is established in this order, it becomes clear that a significant portion of the events closed with the “cloud failure” tag are actually a delegated on-premises dependency.

Detection logic · KQL

SigninLogs
| where TimeGenerated > ago(7d)
| summarize attempts = count() by UserPrincipalName, ResultType, AppDisplayName
| order by attempts desc

Query assumptions

• Illustrative query, not executed in a tenant. The linked Microsoft SigninLogs schema documents these columns; validate the actual collected table before use. ResultType is a string, and this aggregation alone does not identify the sign-in method.
• The query does not prove whether a domain is managed or federated; The sign-in method authoritative must be read from the Entra configuration surface.
• Events on the on-premises AD DS, managed domain and AD FS side may not be included in this table; Correlation crossing the product boundary requires separate resources.

False positives

• A high number of failed results may be due to a misconfigured client or an expired certificate rather than an attack.
• Just because the same UPN appears in different apps does not mean separate identities; single user appears in multiple application streams.
• Negative example: Since password verification in a federated domain is done on the delegated system, the record on the cloud side alone does not explain the on-premises verification behavior.

Hardening

• Combining four products in a single “AD” box in the architecture document; Authority, protocol and management ownership should be kept as separate areas.
• Position the managed domain as a backup or copy of on-premises AD DS; Due to one-way synchronization, the recovery scenario must be designed separately.
• If Federation is used, the owner, schedule and approval flow of token signing certificates and trust repair procedures should be written.
• Plan the managed domain as a temporary bridge for legacy applications; Narrow the AD DS protocol surface by moving modernized applications directly to Entra ID.
• With each new workload, the question “which protocol is required?” Answer the question before choosing the product; unnecessary LDAP/Kerberos surface opening.

Read the examples

O:SYG:SYD:(A;;RPLCLORC;;;AU)(D;;WPSDDTWDWO;;;DA)

Two reality checks

Assumption: Microsoft Entra ID is the cloud version of Active Directory; Entra Domain Services is also a cloud copy of on-premises AD.

In fact: No. Entra ID is a cloud identity provider that issues tokens to applications and does not offer the LDAP/Kerberos/Group Policy surface of AD DS. Entra Domain Services, on the other hand, is a managed domain with a separate namespace consisting of domain controllers managed by Microsoft and is fed with one-way synchronization from Entra ID; on-premises is not a replica or backup of AD DS.

Assumption: AD FS is also a directory; In a federated environment, users are actually kept in AD FS.

In fact: No. AD FS is a federation service, not an identity store. In federated sign-in, Entra ID delegates password verification to this separate authentication system that it trusts; The user object is still located in on-premises AD DS and the directory data is moved to Entra ID via synchronization.

Sources

• Microsoft · Overview of Microsoft Entra Domain Services
  Definition of managed domain services; two managed domain controllers in the replica set; Entra ID being the source of authority; one-way synchronization; LDAP write only for objects created in the managed domain.
• Microsoft · Authentication for Microsoft Entra hybrid identity solutions
  Definitions of cloud authentication and federated authentication; in federated sign-in, handing validation off to a separate trusted authentication system.
• Microsoft · Microsoft Entra Connect and federation
  Procedures for AD FS farm setup, trust repair, federation certificate renewal, and adding a WAP server.
• Microsoft · Domain Services synchronization
  One-way managed-domain sync and custom OU boundary
• Microsoft · SSPR password writeback
  Separately configured Entra-to-AD DS password writeback
• Microsoft · Hybrid authentication resilience
  AD FS SAML assertion; Entra validation and token issuance
• Microsoft · SigninLogs schema
  TimeGenerated datetime; UserPrincipalName,ResultType,AppDisplayName string