Cloud Directory vs Domain Controller: What Breaks When You Retire AD

Retiring on-premises domain controllers in favour of a cloud directory removes a large attack surface, but only if every Kerberos, LDAP, Group Policy and service account dependency is found and replaced first. Many estates already run new users, laptops and SaaS in Microsoft Entra ID or another cloud directory while file servers, legacy apps and scheduled tasks still expect a domain controller. This guide is for identity architects and infrastructure leads deciding whether to keep, shrink or remove Active Directory Domain Services (AD DS). It compares threat exposure, what breaks on removal, replacements, and cutover with rollback. It assumes you already know how to harden what you keep: see the AD Domain Controller Hardening Guide and the Active Directory and Entra ID Hardening Guide.

Examples use Microsoft Entra ID because it is the cloud directory most AD estates move to; the dependency analysis applies equally to other cloud directories that offer LDAP, RADIUS or Kerberos bridging services.

Key takeaways

• The short answer is "shrink first, retire last". Microsoft's own Road to the cloud guidance describes five stages, and full decommissioning only happens in the final Cloud Only stage; a small, well-defended AD footprint is a legitimate end state.
• Hybrid is the riskiest place to stay indefinitely. Sync servers, federation trusts and synced privileged accounts create paths from an on-premises compromise into the cloud tenant, as the Storm-0501 intrusions showed.
• Kerberos and NTLM do not disappear when devices are cloud joined. Entra joined devices still request tickets from domain controllers for on-premises resources, and anything relying on a computer object in AD fails.
• LDAP apps and legacy service accounts decide your timeline. Discover LDAP binds and service logons early; each app needs replacement, a managed domain, or a documented exception.
• Measure dependency burn-down, not project milestones. Count domain-joined devices, LDAP binds, interactive service logons and synced privileged objects every month, and retire DCs only when the counts reach zero for a full business cycle.

Domain controller and cloud directory compared

A domain controller and a cloud directory solve overlapping problems with different trust models. A domain controller is a server you own that holds every password hash in the domain, issues Kerberos tickets, answers LDAP queries and pushes Group Policy over SMB. A cloud directory is a service you configure: it issues OAuth 2.0, OpenID Connect and SAML tokens over HTTPS, evaluates access policy per sign-in, and relies on device management (MDM) rather than Group Policy. The table summarises the security-relevant differences.

Threat model for each option

Keeping domain controllers

• What an attacker wants: Domain Admin or equivalent, because it yields every credential in the forest. Once the krbtgt key is stolen, forged tickets remain valid until the key is rotated twice; see the krbtgt account guide.
• Typical path: a foothold on a member server, credential harvesting, Kerberoasting of service accounts with weak passwords, then lateral movement to a DC or to a system with replication rights.

Cloud directory only

• What an attacker wants: a privileged cloud role, a refresh token or session cookie, or an app registration with broad application permissions.
• Typical path: phishing or adversary-in-the-middle capture of a session (T1557, T1539), MFA fatigue (T1621), or illicit consent to a malicious app.

Hybrid (both, synchronised)

• What changes: you inherit both threat models and add the bridge between them. Microsoft's guidance on protecting Microsoft 365 from on-premises attacks names two main vectors: a compromised SAML token-signing certificate on a federation server lets an attacker impersonate any user, and attackers who control privileged on-premises accounts or groups can use synchronisation to reach cloud admin roles.
• The sync server is Tier 0: the AD DS Connector account used by Entra Connect for password hash sync holds Replicate Directory Changes and Replicate Directory Changes All, which are the same rights DCSync abuses. In the Storm-0501 hybrid cloud attacks, operators took domain controllers, extracted Entra Connect sync credentials, reset synced users' cloud passwords and added a rogue federated domain to forge SAML tokens.

Hybrid with synced privileged objects, active federation or an ordinary-member sync server carries the widest attack surface of the three models.

What breaks when domain controllers go

Map every dependency below before you set a retirement date.

Kerberos does not vanish on day one

Microsoft documents that an Entra joined device, which has no computer object in AD, can still get Kerberos and NTLM SSO to on-premises resources: Entra ID returns the user's on-premises domain details with the Primary Refresh Token, and the device then requests a ticket from a domain controller it can reach. So devices need line of sight to a DC (on the network or over VPN) while on-premises resources exist: "cloud joined" is not "DC free". Applications must accept the UPN or the fully qualified NT4 format; the NetBIOS form (contoso\user) can fail with STATUS_BAD_VALIDATION_CLASS (0xc00000a7). Windows Hello for Business cloud Kerberos trust removes the need for certificates, but it still requires enough read-write DCs in each site and creates an AzureADKerberos object that behaves like a read-only DC; members of privileged built-in groups cannot use it, and Microsoft advises against relaxing its password replication policy. See the Windows Hello for Business Guide and the Kerberos Security Guide.

LDAP is usually the long tail

Microsoft's migration guidance lists Event1644Reader (expensive and inefficient LDAP query logging, event ID 1644 in the Directory Service log), Microsoft Defender for Identity, which captures LDAP binds but not LDAPS, and PSLDAPQueryLogging as discovery options. Turn on DC diagnostics for LDAP interface events, collect for at least a month that includes month-end and quarter-end jobs, and build an app list from source IPs and bind accounts. The LDAP Security Deep Dive Guide covers signing and channel binding for what remains.

Group Policy needs an audit, not a lift

Intune Group Policy analytics imports GPO reports saved from GPMC as XML (each file under 4 MB) and reports an MDM Support percentage, with each setting classified as Ready for migration, Not supported or Deprecated. Redesign rather than copy: many "Not supported" settings are obsolete and only a few are real blockers. See Group Policy to Intune Migration.

Service accounts: the dependency that bites

Legacy service accounts are where retirements stall and where attackers find their easiest wins. A typical estate has user objects with service principal names and passwords set years ago, accounts that log on interactively to run scheduled tasks, and accounts embedded in application configuration files.

1. Inventory: list every account with an SPN, every account with "password never expires", every account used as a service or scheduled task logon on member servers, and every LDAP bind account found during discovery.
2. Classify by destination: code moving to cloud hosting should use a workload identity, which Microsoft describes as needing no stored credentials (managed identities obtain tokens from the environment); external pipelines can use federation instead of secrets. See the Azure Managed Identities Security Guide and the Workload Identity Federation Guide.
3. Harden what stays: services that must keep Kerberos in a residual domain should move to group managed service accounts, which rotate passwords automatically. See the Group Managed Service Accounts (gMSA) Guide.
4. Do not sync them: service accounts have no reason to appear in the cloud directory. Exclude them from sync scope so a compromised on-premises service account cannot become a cloud sign-in.
5. Retire with evidence: disable before delete, watch for event ID 4625 (failed logon) and 4771 (Kerberos pre-authentication failed) against the disabled account for a full business cycle, then delete.

The sync accounts themselves deserve their own review: express installation creates an MSOL_ prefixed AD DS Connector account with a non-expiring password and replication rights. See How to audit the Entra Connect sync account and the Microsoft Entra Connect and Cloud Sync Hardening Guide.

Bridging options for workloads that cannot move yet

Microsoft's migration guidance ranks three approaches for apps that still need AD, and the order is a useful decision rule.

For remote access, an app proxy or a zero trust network access service such as Microsoft Entra Private Access replaces VPN reachability with per-app access governed by Conditional Access. The apps behind it still depend on AD until modernised. See Microsoft Entra Private Access and Microsoft Entra Domain Services Security.

Decision criteria: keep, shrink or retire

• Retire AD DS when: all users and devices are cloud joined and managed by MDM, no app performs LDAP binds or Kerberos authentication against the domain, file data has moved, and network authentication uses certificates or modern authentication.
• Shrink to a residual domain when: a defined set of servers, OT systems or vendor appliances must keep Kerberos or LDAP. Run it as a resource enclave with gMSAs for services and named dependencies with owners and end dates.
• Use a managed domain when: the remaining dependencies are cloud-hosted VMs that need domain join or LDAP but no schema extensions or Configuration Manager.
• Stay hybrid deliberately when: large estates with manufacturing, healthcare or regulated systems cannot move for years. Then close the bridge: cloud-only admin accounts, no synced objects in privileged roles, federation removed for cloud sign-in (see AD FS to Entra ID Migration), and the sync server administered as Tier 0.

Small versus large organisations: a 200-person firm with laptops, SaaS and one file server can often retire its two DCs inside a quarter. A multi-forest enterprise should expect a residual domain for years and break the on-premises-to-cloud privilege path before cutting DC numbers. For multi-forest consolidation first, see the Active Directory Domain and Forest Migration Security Guide.

Worked scenario: a 1,500-person firm

A professional services firm runs one forest with four DCs, Entra Connect with password hash sync, 1,400 hybrid joined laptops, three file servers, an on-premises document management system using Windows authentication, a finance app using LDAP bind, and NPS for Wi-Fi.

1. Months 1 to 2, close the bridge: create cloud-only admin accounts with phishing-resistant MFA, remove synced accounts from every privileged role, exclude service accounts from sync, and move the Entra Connect server into the Tier 0 management boundary.
2. Months 2 to 4, discover: enable LDAP diagnostics, collect 4769 (Kerberos service ticket) and 4624 logon type 5 (service) events, run Group Policy analytics. Result: 61 GPOs, 22 service accounts with SPNs, 9 LDAP bind sources.
3. Months 4 to 9, move devices: reimaged laptops are Entra joined and Intune managed, keeping Kerberos SSO to file servers over the office network and VPN; Wi-Fi moves to MDM-issued certificates.
4. Months 6 to 12, move data and apps: file shares move to cloud storage, the document system is upgraded to its SaaS edition, and the finance vendor's OIDC module replaces LDAP bind.
5. Month 12, residual review: two building management servers still need LDAP. The firm moves them to a managed domain rather than keeping four DCs.
6. Month 14, retire: after 60 days with zero LDAP binds and zero Kerberos ticket requests from production systems, DCs are demoted one at a time with a final system state backup held offline for the retention period.

Implementation and rollback

1. Freeze growth: new users, groups, devices and apps are cloud native by default; adding to AD requires an exception.
2. Pilot rings: move one department's devices and apps first; keep DCs untouched until the ring runs a full month without help desk tickets tied to authentication.
3. Disable before delete: stop sync for an OU before removing it, disable service accounts before deleting them, and stop the Netlogon service on a DC (or isolate it) before demotion to surface hidden dependencies.
4. Rollback: keep at least one healthy DC and tested system state backups until the burn-down metrics hold for a full business cycle; re-enable sync scope or service accounts if a hidden dependency appears. After the last demotion, rollback means rebuilding.

Detection and measurement

• On DCs while they remain: 4769 and 4768 for ticket requests (look for RC4 encryption type 0x17), 4662 with replication GUIDs for DCSync attempts from anything other than DCs and the sync account, 1644 for LDAP queries, 4625 and 4771 against disabled accounts.
• On hybrid infrastructure: archive OS security logs from sync servers, writeback agents, private network connectors and NPS servers, as Microsoft recommends.
• In the cloud directory: role assignment changes, new federated domains or changed domain authentication settings, and password resets on synced accounts performed by the sync identity.

Metrics:

• Domain-joined (including hybrid joined) devices as a percentage of all managed devices.
• Distinct LDAP bind sources per week.
• Service accounts with SPNs, and the percentage converted to workload identities or gMSAs.
• Synced objects holding any privileged cloud role (target: zero).
• GPOs still linked and applying, against the Group Policy analytics baseline.
• Days since the last authentication event from a production system to each DC scheduled for retirement.

Framework mapping

Common failure patterns

• Declaring victory at "all devices cloud joined": devices still request Kerberos tickets from DCs for on-premises shares, so turning DCs off breaks access the day after.
• Leaving synced admins in cloud roles during a long hybrid phase: an on-premises Domain Admin compromise becomes a tenant compromise, the pattern in the Storm-0501 hybrid cloud attacks.
• Keeping federation "just in case": a federation server's token-signing key is a skeleton key to every federated app, as the SolarWinds supply chain compromise showed with forged SAML tokens. See the Golden SAML and Federation Trust Abuse Defence Guide.
• Short LDAP discovery windows: a two-week capture misses quarterly jobs that bind to LDAP.
• Forgetting DC backups: demoted DCs are gone, but old system state backups still hold every password hash; destroy or protect them under your retention policy.

Practitioner checklist

• Set the target end state in writing: retire, residual domain, managed domain, or deliberate hybrid.
• Move all privileged cloud roles to cloud-only accounts with phishing-resistant MFA and remove synced objects from those roles.
• Administer the sync server, federation servers and connectors as Tier 0, and plan to remove federation for cloud sign-in.
• Run LDAP, Kerberos and service logon discovery for at least one full business cycle.
• Build a dependency register with owner, replacement and date for every app, GPO and service account.
• Move cloud-hosted code to workload identities and remaining on-premises services to gMSAs; exclude service accounts from sync.
• Pilot by ring, disable before delete, and keep a healthy DC and tested backups until burn-down metrics hold.

Standards and references

• Microsoft Learn: Road to the cloud, introduction
• Microsoft Learn: Transition to the cloud
• Microsoft Learn: Protect Microsoft 365 from on-premises attacks
• Microsoft Learn: How SSO to on-premises resources works on Microsoft Entra joined devices
• Microsoft Learn: Windows Hello for Business cloud Kerberos trust deployment
• Microsoft Learn: Microsoft Entra Connect accounts and permissions
• Microsoft Learn: Microsoft Entra Domain Services overview
• Microsoft Learn: Group Policy analytics in Microsoft Intune

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Microsoft Entra Connect and Cloud Sync Hardening Guide · Group Managed Service Accounts (gMSA) Guide · Directory Services and Cloud Directory Buyer's Guide · NTLM Deprecation and Elimination Guide