Active Directory, Entra ID and Azure: Hybrid Identity Explained

Overview: two identity systems, one name in common

Many organisations run Active Directory Domain Services (AD DS) in their own data centre and also use Microsoft Entra ID (the cloud identity service behind Microsoft 365 and Azure). The names sound related and the two are often joined together, so it is easy to assume that Entra ID is simply "Active Directory in the cloud". It is not. They were built for different eras, speak different protocols, are organised differently and are managed differently.

This article explains how they differ, how organisations connect them (hybrid identity), and what to choose when a workload in Azure needs a domain: Microsoft Entra Domain Services or your own domain controllers in Azure virtual machines. It is written for engineers who know one side well and want to understand the other.

The rest of the article follows that order: the differences (sections 2 to 6), the connection between them (7 to 9), and the two ways to run a domain in Azure (10 to 12).

On-premises AD, Entra ID and Azure are three different places; synchronisation and network links connect them.

Side-by-side comparison

Microsoft describes Microsoft Entra ID as "the next evolution of identity and access management solutions for the cloud". The table below follows Microsoft's own comparison of the two.

Two points are worth holding on to before reading further. First, the differences are not features that one product forgot to build: they reflect a different design (tickets inside a network versus tokens over the web). Second, because of that design, the two are usually combined rather than swapped.

Protocols: Kerberos versus OAuth 2.0 and OpenID Connect

The AD DS side: Kerberos, NTLM and LDAP

AD DS authenticates users and computers on the corporate network.

• Kerberos is the default. The Key Distribution Center (KDC) runs on every domain controller. A client first obtains a ticket-granting ticket (TGT) from the authentication service, then presents the TGT to the ticket-granting service to obtain a service ticket for each service it uses. The domain's krbtgt account holds the key that protects TGTs. Kerberos uses timestamps to stop replay attacks, so the clocks of client and DC must agree to within a tolerance that defaults to 5 minutes.

• NTLM is the older challenge-response protocol, used where Kerberos cannot be.

• LDAP is the protocol applications use to read and query the directory. Port 389 is the LDAP port, 636 is LDAP over SSL, and 3268 and 3269 are the global catalog ports.

All three assume the client can reach a domain controller on the network, and that DNS can tell it where one is.

Every step is a conversation with a domain controller or with a server that trusts it.

The Entra ID side: OAuth 2.0, OpenID Connect, SAML

The Microsoft identity platform offers authentication and authorisation using standards-compliant implementations of OAuth 2.0 and OpenID Connect (OIDC) 1.0. An authorisation server issues security tokens after the user has signed in, and apps and APIs use those tokens to grant, deny or revoke access.

Bearer tokens in the Microsoft identity platform are formatted as JSON Web Tokens (JWT) and are valid for a limited time. Common flows listed by Microsoft include the authorisation code flow (single-page, mobile and desktop apps), the client credentials flow (server-side processes, scripts and daemons), the on-behalf-of flow (a web API calling another API for a user), and OpenID Connect for sign-in and single sign-on. Many enterprise applications use SAML to authenticate users, and WS-* is also supported.

No domain controller appears anywhere in this flow: the browser, the app and the cloud service are enough.

The key difference

This is why old applications that expect Kerberos, NTLM or LDAP cannot simply be pointed at Entra ID, and why SaaS applications cannot natively use AD.

Where the two meet

Two features let a cloud sign-in benefit on-premises resources:

• Seamless single sign-on. Enabling it creates a computer account called AZUREADSSOACC in each synchronised AD forest and shares its Kerberos decryption key with Entra ID. A browser on a domain-joined corporate device inside the corporate network is challenged for a Kerberos ticket, gets one from AD, and forwards it to Entra ID, which decrypts it with the shared key. Microsoft recommends rolling the key over at least every 30 days and protecting the account strongly. The feature is opportunistic: if it fails, the user is simply asked for a password.

• Cloud Kerberos trust (Windows Hello for Business). When Microsoft Entra Kerberos is set up, the user receives a partial TGT at sign-in. An AzureADKerberos computer object appears in the domain as a read-only domain controller object, but is not tied to any physical server.

This is the bridge: a Kerberos ticket from the on-premises domain proves identity to the cloud service.

Conditional Access policies are enforced after first-factor authentication is completed.

Structure: forests, domains and OUs versus tenants and administrative units

How AD DS is organised

An AD DS forest is a collection of domains that share a schema, a configuration and a global catalog. A domain is a partition of the directory; organisational units (OUs) group objects inside a domain for administrative purposes, such as applying Group Policy or delegating authority. Control over an OU and its objects is set by access control lists. Sites, subnets and site links describe the physical network, and replication keeps the domain controllers consistent.

How Entra ID is organised

Entra ID is a service Microsoft runs for you, so there are no domain controllers, sites or replication links for you to design. Objects such as users, groups and devices live directly in your tenant. Delegation uses roles:

• Microsoft Entra provides built-in roles through its role-based access control system, with limited support for custom roles.

• A role assigned to a user who is not a member of an administrative unit applies to the whole tenant.

Administrative units are not OUs

An administrative unit (AU) is a container for other Entra resources, and it is the closest thing to an OU. The similarity is shallow:

Licensing: using AUs requires a Microsoft Entra ID P1 license for each AU administrator who is assigned directory roles over the AU, and an Entra ID Free license for each AU member. Dynamic membership rules for AUs can add or remove users or devices, but not groups.

Restricted management administrative units go further: they protect specific objects from modification by anyone other than the people you designate. Global Administrators and Privileged Role Administrators cannot modify objects in them (although they can manage the AUs themselves). The restricted setting must be chosen when the AU is created and cannot be changed afterwards, a tenant can have at most 100 of them, and they hold users, devices and security groups.

In short: an OU is a place in a hierarchy where policy and permissions apply; an administrative unit is a flat scope that limits where an admin role works.

The overlap is intentional: one user can sit in several administrative units, each scoping a different admin role.

Management: Group Policy versus Intune and Conditional Access

Group Policy in AD DS

Group Policy applies settings to domain-joined users and computers. A GPO is stored half in the directory (the Group Policy Container) and half in the SYSVOL folder (the Group Policy Template), is linked to a site, domain or OU, and is applied in the order local, site, domain, OU. Clients refresh it roughly every 90 minutes (with a random offset of up to 30 minutes), and domain controllers every 5 minutes. The model relies on the device being a domain member that can reach a domain controller.

Intune and Conditional Access in Entra ID

Entra ID does not use Group Policy. Two services take over its roles:

• Microsoft Intune is Microsoft's mobile device management solution and is integrated with Entra ID. It manages devices and provides device state information to the identity system so that it can be evaluated during authentication.

• Conditional Access brings signals together, makes decisions and enforces organisational policy. Microsoft calls it its Zero Trust policy engine. A policy is an if-then statement: if a user wants to access a resource, then they must complete an action.

Conditional Access requires Microsoft Entra ID P1 licenses. Risk-based policies (sign-in risk and user risk) require Microsoft Entra ID Protection, which is a P2 feature.

The top lane changes settings on a machine; the bottom lane also decides whether a sign-in is allowed.

Device identity: three ways to join

Microsoft describes hybrid join as an interim step on the road to Entra join, and says all three can coexist in one organisation. A hybrid joined device needs network line of sight to your domain controllers periodically; Microsoft states that without this connection, devices become unusable. If that is a concern, Microsoft's guidance is to consider Entra joining the devices instead.

The device state decides which policy engine can manage it and what it needs to reach.

Side by side

The last row is the real shift: Group Policy configures a machine, while Conditional Access also decides whether a sign-in is allowed based on who, where, on which device and with what risk.

Why Entra ID is not "Active Directory in the cloud"

The phrase is common and misleading. Here is what each part of it gets wrong.

What they share

Both store identities (users, groups, devices) and both authenticate people. That overlap is why they are synchronised, so a user has one identity that works in both worlds. That is the subject of the next three sections.

Hybrid identity: Microsoft Entra Connect Sync versus Cloud Sync

Hybrid identity means a user has one identity that exists in on-premises AD DS and in Entra ID. A synchronisation tool copies identity data from AD to Entra ID. Microsoft offers two.

Microsoft Entra Connect Sync

Microsoft Entra Connect Sync "synchronizes identity data between your on-premises directories and Microsoft Entra ID. It includes an on-premises sync engine and a service component in Microsoft Entra ID." You install it on a server that you manage.

• A sync cycle runs every 30 minutes by default. A cycle is either a delta cycle (delta import, delta sync, export on all connectors) or a full cycle (full import, full sync, export).

• A delta sync must happen within 7 days of the last one, or a full synchronisation is needed to fix the resulting problems. This also applies to servers in staging mode.

• Staging mode suppresses exports but still runs import and synchronisation, which makes it a standby server that can take over.

• Useful cmdlets: Get-ADSyncScheduler shows the scheduler, Start-ADSyncSyncCycle -PolicyType Delta runs a delta cycle, and Start-ADSyncSyncCycle -PolicyType Initial runs a full cycle. Disable the scheduler with Set-ADSyncScheduler -SyncCycleEnabled $false while making configuration changes, and re-enable it afterwards.

• It is a single point of failure: if the Connect server becomes unavailable, synchronisation stops until the server is restored.

Microsoft Entra Cloud Sync

Cloud Sync uses a lightweight provisioning agent instead of a full sync server. The agent has a small footprint and can run on an existing domain controller or on a standalone server. You can install several active agents on different servers, which gives automatic failover and load distribution. Cloud Sync natively supports synchronisation from multiple disconnected AD forests. Microsoft states that Cloud Sync is replacing Connect Sync, which will be retired after Cloud Sync has full functional parity.

Feature comparison

From Microsoft's decision guide (limits can change, so check the current page before designing):

Which one

Hybrid identity is a design you will operate for years, so make the sync layer redundant: more than one Cloud Sync agent, or a Connect server in staging mode.

Connect Sync centres on one server; Cloud Sync moves the engine to the cloud and leaves only agents on-premises.

Sign-in methods: password hash sync, pass-through authentication and federation

Synchronising identities does not decide who checks the password. That is a separate choice with three options.

Password hash synchronisation (PHS)

The user signs in with the same username and password as on-premises, and Entra ID validates the password in the cloud. No extra infrastructure is needed beyond the sync server.

• Passwords are never stored in clear text or encrypted with a reversible algorithm in Entra ID.

• It runs as part of Entra Connect Sync every two minutes.

• It is highly available because it is a cloud service, and cloud sign-in does not depend on on-premises components.

• Limitation: changes to on-premises account state are not enforced immediately. Disabled accounts are supported with a delay of up to 30 minutes.

Pass-through authentication (PTA)

A software agent on one or more on-premises servers validates the user directly against AD, so password validation never happens in the cloud.

• Agents need access to your domain controllers and outbound internet access. They are not supported in a perimeter network.

• Microsoft recommends three agents, so one can fail while another is down for maintenance.

• It enforces the on-premises account policy at sign-in: disabled, locked out, expired password, or outside allowed sign-in hours.

• Fail over to PHS does not happen automatically; you must switch the sign-on method manually in Entra Connect.

Federation (for example AD FS)

Entra ID hands the sign-in to a separate trusted system, such as AD FS, to validate the password.

• It needs two or more AD FS servers, two or more Web Application Proxy servers in the perimeter network, load balancing, a TLS/SSL certificate and inbound internet access to the proxies. Federated systems typically need a load-balanced farm.

• It is required when you need something Entra ID does not support natively, such as third-party MFA, third-party authentication solutions, or sign-in with DOMAIN\username (sAMAccountName) instead of a UPN.

• It has a high number of on-premises dependencies, and all on-premises components and connections are susceptible to failure.

Comparison

Microsoft's recommendation

Microsoft says to use or enable PHS with whichever method you choose: it gives high availability, survives on-premises outages, and Microsoft Entra ID Protection needs it for the "Users with leaked credentials" report. If your organisation relies on AD passwords with PTA or federation, Microsoft recommends implementing PHS where possible, and if you cannot use PHS, using PTA. A fail over to PHS only works if it was configured before the failure.

The further right the password check sits, the more on-premises systems a sign-in depends on.

Failure modes: when on-premises AD or a link in the chain goes down

A hybrid design has several links: domain controllers, the sync server or agents, the sign-in method, and the network between them. Each failure hits a different group of users in a different way.

Only hash sync keeps cloud sign-in alive without a domain controller.

What to take from this

1. Enable PHS even if you use PTA or federation. It is the only option with no on-premises dependency at sign-in, and Microsoft recommends it as the backup.

2. Remove single points of failure in the sync layer, not just in the DC layer.

3. Know which of your devices depend on a DC. Hybrid joined devices do; Entra joined devices work over the internet.

4. Test the failover before you need it: the switch from PTA or federation to PHS is a manual action.

Microsoft Entra Domain Services versus domain controllers in Azure VMs

Sometimes a workload in Azure still needs a domain: a lifted-and-shifted application that uses Kerberos, NTLM or LDAP, servers that need Group Policy, or machines that must be domain joined. Entra ID cannot do that on its own (section 6). There are two ways to give the workload a domain.

Microsoft Entra Domain Services (managed)

Microsoft describes it as providing "managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication" without you deploying, managing or patching domain controllers in the cloud.

• When you create a managed domain you choose a unique namespace. Two Windows Server domain controllers are deployed into your Azure region as part of a replica set. They are fully managed by Microsoft: you do not configure, patch or monitor them. In regions with availability zones the DCs are spread across zones, and you can add replica sets in other regions for disaster recovery.

• A managed domain is a stand-alone domain and is not an extension of an on-premises domain. There are no AD forests, domains, sites or replication links for you to design and maintain. You can still create forest trusts to on-premises environments.

• Synchronisation is one-way, from Entra ID to the managed domain. Nothing is synchronised back. Hybrid identities reach it through Entra Connect: objects and credentials from on-premises AD are synchronised to Entra ID first, then flow on to the managed domain.

• A managed domain is largely read-only apart from custom OUs that you can create. You cannot change user attributes, passwords or group memberships inside it. Objects created in custom OUs stay in the managed domain and are not visible in Microsoft Graph or the Entra admin center.

• Not synchronised from on-premises: Group Policy, the contents of SYSVOL, and on-premises OUs.

• Password hashes. Entra ID does not store clear-text passwords, so the legacy hashes that NTLM and Kerberos need cannot be generated for existing accounts. Cloud-only users must change their password before they appear in the managed domain. For hybrid users, Entra Connect must be configured to synchronise password hashes in NTLM and Kerberos compatible formats.

• If on-premises AD and Entra ID use federated authentication with AD FS and no valid hash is available, the managed domain cannot validate the user's credentials.

• The initial synchronisation can take from a few hours to a couple of days, depending on the number of objects.

Your own domain controllers in Azure VMs (self-managed)

You deploy Windows Server VMs, promote them to domain controllers and run them like any other DC. You keep full control of the directory (and full responsibility for it): patching, backup, monitoring, DNS, sites, FSMO placement, and schema.

Feature comparison

From Microsoft's comparison of a managed domain with self-managed AD DS:

What you give up with the managed domain

• Schema extensions. Applications that need to extend the schema cannot be installed.

• Domain and Enterprise Admin rights. You work with a managed domain without those privileges.

• Control of the topology. Because Microsoft runs the forest, domain, sites and replication for you, you do not place or move FSMO roles, add sites or tune replication.

• Account-based Kerberos constrained delegation. Only resource-based delegation is supported.

• Being an extension of your existing domain. It is a separate domain; trusts can connect it to on-premises.

• Direct changes to synchronised objects. The managed domain is largely read-only for them.

The domain controllers are run by Microsoft, which is exactly why schema and administrator rights are limited.

Microsoft also says to use Domain Services as a transitional capability for Azure-hosted workloads that need legacy authentication, rather than as a general replacement for on-premises AD or a substitute for cloud-native identity services.

What you give up with your own DCs

In exchange for control you take on the operations: sizing, patching, backups, DNS, time, monitoring, security hardening and the recovery steps in section 11. Choose it when the control is worth that work.

Domain-joined versus Entra joined

Domain controllers in Azure

If you choose self-managed AD DS in Azure, the domain controllers are ordinary DCs on virtual machines. The rules of AD DS still apply (sites, replication, DNS, time, FSMO roles). The cloud adds some specifics. The guidance below follows Microsoft's reference architecture for extending AD DS to Azure.

Topology and availability

• Deploy at least two VMs as domain controllers, in different availability zones. If the region has no zones, use an availability set.

• Consider giving at least one server the standby operations master role (a standby FSMO holder).

• Give at least two of the Azure domain controllers the global catalog role.

• Size the VMs for the expected volume of authentication requests: start from the specifications of the machines hosting AD DS on-premises, then monitor and adjust.

Sites and subnets

Create an AD DS site that includes the subnets you define for your Azure workloads, then configure a site link to your on-premises sites. Clients then find a nearby DC through the subnet-to-site mapping, and the KCC builds the replication topology between sites. AD DS automatically performs the most efficient database replication possible. In AD terms, Azure is just another site.

Clients in Azure should find a local domain controller first, which is what the Azure site and its subnets achieve.

IP addressing and networking

• Configure each DC's network interface with a static private IP address instead of DHCP, so clients can reach it even if DHCP is unavailable.

• Do not give a DC's NIC a public IP address. For administration, use Azure Bastion instead of a jump box exposed to the internet.

• Put the DCs in a separate subnet protected by a network security group (NSG) that acts as a firewall. Close all ports except those needed for authentication, authorisation and server synchronisation, and allow traffic to and from on-premises.

• The ports a DC needs include: LDAP 389 (TCP and UDP), LDAPS 636, global catalog 3268 and 3269, Kerberos 88 and 464, RPC endpoint mapper 135 with dynamic RPC ports 49152 to 65535, SMB 445, DNS 53, and NTP 123 (UDP).

DNS

• If the DCs are also DNS servers, configure them as custom DNS servers at the virtual network level, for the VNet that hosts them and for peered networks where other VMs must resolve AD names.

• For the first configuration you may need to point a new Azure DC at an on-premises DC as its primary DNS source.

• Avoid a start-up delay: if a DNS server is also a DC and points only to itself, or to itself first, it can start slowly. Use the loopback address only as a secondary or tertiary DNS server on a DC.

• AD relies on SRV records to let clients locate DCs, so a broken DNS design breaks logons.

If DNS is wrong, clients cannot locate a domain controller and every logon suffers.

Disks

• Put NTDS.dit, the logs and SYSVOL on a separate persistent data disk, not on the OS disk.

• Set Host Cache Preference to None on that data disk. The ESE database engine manages its own write ordering, and caching can interfere with database consistency.

• Use persistent managed disks for the OS disk. Do not use ephemeral OS disks for domain controllers.

• Enable encryption at host on supported VM sizes, and use in-guest BitLocker where compliance demands it.

Time synchronisation

Kerberos fails when clocks drift beyond its tolerance (5 minutes by default), so time matters more on a DC than anywhere else.

• Azure Windows VM images are configured by default so that w32time syncs from two sources: the NtpClient provider (time.windows.com) and the VMICTimeSync service, which passes the host time to the VM and corrects it after the VM is paused for maintenance.

• w32time prefers a provider by stratum, root delay, root dispersion and offset. In most cases it prefers host time on an Azure VM.

• VMICTimeSync works in sample or sync mode and only moves the clock forward.

• On a domain-joined machine, the domain sets the time hierarchy, but the forest root still needs to take its time from somewhere. In an AD forest, that is the PDC Emulator of the forest root domain (members sync to DCs, DCs to the PDC Emulator of their domain).

• Check the current source with w32tm /query /source. "VM IC Time Synchronization Provider" means the VM is taking host time; "Your domain server" means the domain hierarchy defines time.

Microsoft's VM time page does not give domain-controller-specific settings. For the root PDC Emulator, decide deliberately between host time and an external NTP source, document the choice, and verify it with w32tm.

Time is a chain: a break anywhere in it eventually shows up as Kerberos failures.

Safe shutdown, backup and the USN rollback risk

Every DC keeps its own update sequence number (USN), a counter that increases with each change, and other DCs use it (with the DC's invocation ID) to decide what they still need. If a DC is rolled back in time without its knowledge, it can reuse a USN for a different change. Microsoft describes the result: replication will not converge, because other DCs believe they have already received the update tied to the reused USN, so modifications are not replicated inbound by destination DCs that have seen that USN. This is a USN rollback.

A snapshot restore is the easiest way to cause one: restoring a DC from a snapshot rolls back its USNs without its awareness.

The danger is that nothing looks broken until the data on the domain controllers no longer agrees.

• Safeguard. Hypervisor platforms that expose VM-GenerationID let a virtual DC detect a rollback. At DC installation, AD DS stores the identifier in the msDS-GenerationID attribute of the DC's computer object. After a restore, if the current value differs from the stored one, AD DS resets the invocation ID and discards the RID pool, which prevents USN reuse. It also does this on each reboot if the values differ, and it non-authoritatively synchronises SYSVOL.

• Not a backup method. Microsoft states that restoring a DC by applying a VM snapshot is not recommended as an alternative to backing it up. Keep using Windows Server Backup or another VSS-writer based backup solution.

• If a production DC is reverted by accident, check whether a valid system state backup exists, and restore from the most recent one if it holds more recent changes.

• Do not copy VHD files as a backup. The AD DS database on a copied VHD may be inconsistent and may not restart.

• Do not shut a DC down from the Azure portal. Shut down and restart the guest operating system instead. If all DCs in a domain are shut down and deallocated at the same time, each fails to find an authoritative replica when restarted.

Whether a given virtualisation platform exposes VM-GenerationID is something to confirm in that platform's documentation; this article does not assume it.

Decision guide

Start from what the workload needs, not from the product names.

And for the identity layer:

Use the flow as a first filter, then confirm the choice against the requirements of each application.

Security best practices

Items marked (Microsoft) come from Microsoft's documentation used for this article. The others are widely accepted practice.

Identity and sign-in

• Enable password hash synchronisation alongside any other sign-in method. It is the backup for outages and Entra ID Protection's leaked-credentials report needs it (Microsoft).

• Use Conditional Access to require multifactor authentication and device compliance. Remember that policies are enforced after first-factor authentication and are not a frontline defence against denial-of-service (Microsoft).

• Protect the AZUREADSSOACC account if you use seamless SSO: only Domain Admins should manage it, Kerberos delegation must be disabled on it, no other account should have delegation permissions on it, and its Kerberos decryption key should be rolled over at least every 30 days. Prefer AES-based encryption types over RC4 (Microsoft).

• Do not relax the Password Replication Policy of the AzureADKerberos object to let high-privilege accounts use cloud Kerberos trust (Microsoft). By default privileged built-in group members cannot.

• Scope admin roles with administrative units, and use restricted management administrative units for objects that need extra protection (Microsoft).

• Keep break-glass admin accounts that do not depend on on-premises systems, and monitor their use.

• Treat the sync server or agents as part of the identity core. Whoever controls them can influence what reaches Entra ID, so patch them, restrict logon to them, and do not place PTA agents in a perimeter network (PTA agents: Microsoft).

Domain controllers in Azure

• No public IP on DC NICs; admin access through Azure Bastion; DCs in a separate subnet with an NSG that closes all but the required ports (Microsoft).

• Use encryption at host and, where required, BitLocker (Microsoft).

• Back up with VSS-based tools; never rely on copied VHDs or snapshots (Microsoft).

• Shut DCs down from within the guest OS, not the portal (Microsoft).

• Apply the usual DC hardening: least privilege, patching, limited logon, and auditing of privileged groups.

Entra Domain Services

• The encryption keys for the NTLM and Kerberos hashes are unique to each tenant and only Domain Services can decrypt the hashes (Microsoft).

• Remember it is largely read-only; manage identities in Entra ID or on-premises, not in the managed domain (Microsoft).

Limitations and gotchas

• Sync is not instant. Connect Sync runs every 30 minutes by default, PHS roughly every two minutes, and PHS enforces disabled on-premises accounts with a delay of up to 30 minutes.

• Seven-day rule. A delta sync must happen within 7 days of the last one or a full sync is required.

• PTA fail over is manual. It does not switch to PHS on its own.

• PTA agents cannot be placed in a perimeter network.

• Federation is heavy. It needs an AD FS farm, proxies, certificates and load balancing, and carries many on-premises dependencies.

• Cloud Sync has limits at the time of writing: 150,000 objects per domain, 50,000 members per group, limited attribute filtering, and no device writeback.

• Administrative units cannot be nested and apply to management permissions only; they do not stop users browsing objects outside the unit. Restricted management AUs cannot be changed after creation, and a tenant can have at most 100.

• Licensing: Conditional Access requires Entra ID P1; risk-based policies require P2 (Entra ID Protection). AU administrators need P1.

• Hybrid joined devices need periodic line of sight to a DC, and without it they become unusable.

• Entra Domain Services: no schema extensions, no Domain or Enterprise Admin rights, resource-based constrained delegation only, forest trusts need the Enterprise SKU, and accounts in linked external directories are not available. Cloud-only users must change their password before they appear. The managed domain is not an extension of your on-premises domain.

• Do not install Entra Connect in a managed domain to sync objects back to Entra ID; it is not supported.

• Azure DCs: do not use ephemeral OS disks, do not shut down from the portal, do not rely on VHD copies, and avoid a DNS configuration that points a DC only at itself.

• USN rollback from a snapshot restore can silently stop replication from converging; safeguards depend on the platform exposing VM-GenerationID.

Quick reference

Defaults and numbers

Ports a domain controller needs

Commands

Glossary

References

• Compare Active Directory to Microsoft Entra ID

• Compare self-managed AD DS, Microsoft Entra ID and Microsoft Entra Domain Services

• What is Microsoft Entra Domain Services?

• How objects and credentials are synchronized in Microsoft Entra Domain Services

• Microsoft identity platform protocols

• Security tokens

• Administrative units

• Restricted management administrative units

• What is Conditional Access?

• What is a device identity?

• Microsoft Entra hybrid join

• Connect Sync or Cloud Sync decision guide

• Microsoft Entra Connect Sync overview

• Microsoft Entra Connect Sync: Scheduler

• Choose the authentication method for your hybrid identity solution

• Build resilience in your hybrid architecture

• Seamless single sign-on: technical deep dive

• Cloud Kerberos trust deployment guide

• Extend AD DS to Azure (reference architecture)

• Time sync for Windows VMs in Azure

• Introduction to AD DS virtualization (VM-GenerationID, USN rollback)

• Service overview and network port requirements for Windows