Retiring on-prem Active Directory: what still requires it

"We are cloud-first" and "we still have four domain controllers" describe the same organisation more often than not. Retiring AD DS is possible, and organisations do it, but the ones that succeed treat it as an inventory problem rather than a directory problem: every dependency is found, replaced or accepted, and the domain controllers are the last thing to go, not the first. This guide is the inventory, with the replacement for each item and an honest note about which replacements are real.

The wider strategy is in hybrid identity strategy; the sync engine choice is in Entra Connect vs Cloud Sync.

The rule: find every consumer of Kerberos, NTLM and LDAP

AD DS provides three things applications consume: Kerberos and NTLM authentication, LDAP for directory lookups, and Group Policy. Anything that uses none of these does not need AD. Anything that uses one of them does, until you replace that use. The inventory is therefore a search for those three protocols across everything you run.

Practical ways to find them: the Domain controller security logs for Kerberos ticket requests (event 4768) and NTLM authentications (4776), grouped by source; LDAP bind logging (event 2889 for unsigned binds, or full LDAP auditing) to see which hosts query the directory; and Get-GPO with link and WMI-filter reports for what Group Policy still does. Run these for a month. What shows up is your list.

Item by item

Windows devices joined to the domain. The replacement is Entra join with Intune, which is the largest single workstream and the one most organisations have already started. Hybrid-joined devices are a transition state, not a destination; a device that is hybrid joined still authenticates to a domain controller at logon and still needs line of sight or a VPN to process Group Policy. The Autopilot guide covers the cloud-native path. Group Policy is replaced by Intune configuration profiles and settings catalog, and the honest note is that a small fraction of GPO settings has no Intune equivalent — find those early with Group Policy Analytics in Intune.

File servers. SMB shares authenticate with Kerberos against AD. Options: move the content to SharePoint and OneDrive (best for collaboration data, and the migration guide is written for it); Azure Files with Entra Kerberos for hybrid identities, which lets Entra-joined devices mount shares without a domain controller — with the caveat that, at the time of writing, it still requires the identities to have been synced from AD, so it is a step toward retirement rather than the end state; or Entra Domain Services (below) for the shares that must stay SMB.

Line-of-business applications using Windows authentication. SQL Server with Windows logins, IIS apps with integrated auth, anything using a service account. Each is either modernised to use Entra authentication (SQL supports it, IIS apps can front with Entra via Application Proxy or a rewrite), or it stays and becomes the reason for the next item.

Entra Domain Services. A managed AD DS domain in Azure, synchronised one way from Entra ID, offering Kerberos, NTLM, LDAP and Group Policy to VMs and apps that need them. It is the sanctioned answer to "some things need AD and we do not want to run it". Understand its limits before betting on it: it is a separate domain, not your existing one, so machines and apps are re-joined; there is no schema extension, no domain trust in the way you may expect, and password hashes only flow for users who change their password after it is enabled. For a handful of legacy servers it is excellent. For a large estate it is a migration in its own right.

RADIUS and 802.1X. NPS runs on a domain member and authenticates against AD. Replacements: certificate-based EAP-TLS where the certificate comes from Intune and the RADIUS server validates the certificate chain without an AD lookup — several cloud RADIUS services do exactly this, and NPS itself can work in a reduced mode — or move the network to a model where device compliance from Intune, not network authentication, is the gate.

Printing. Print servers with AD-published queues are replaced by Universal Print or a vendor cloud print service. This is one of the easier items.

Certificate services (AD CS). If your PKI is an enterprise CA integrated with AD, the CA depends on AD for templates and enrolment. Intune's cloud PKI, or a third-party cloud CA, replaces the issuance function for devices; anything else that consumes certificates from the enterprise CA needs its own answer. Do not underestimate this one.

Service accounts and scheduled tasks. Every script running as a domain account on a server needs to become a managed identity (if the server is in Azure or Arc-enabled), an app registration with a certificate, or an account in Entra Domain Services. The inventory for this is the 4768 events above.

Exchange hybrid attributes. If mail attributes are still mastered on-prem, the last Exchange server and the hybrid writeback are AD dependencies. Retiring Exchange and moving attribute management to the cloud is a prerequisite for retiring AD, not a consequence of it.

Windows Hello for Business and on-prem resources. Devices using cloud Kerberos trust reach on-prem resources via a Kerberos server object in AD. Once no on-prem resources remain, this dependency simply disappears.

Third-party identity integrations. Some HR, badge, and MDM systems write to or read from AD via LDAP. Each needs re-pointing to Entra ID via Graph, SCIM, or the vendor's Entra connector. The SCIM guide covers the provisioning direction.

The sequence

1. Move users' source of authority to the cloud. Convert synced users to cloud-managed — Microsoft has been shipping this capability progressively, and the mechanism at the time of writing is to switch the user's source of authority so Entra becomes the master and AD becomes a downstream copy or is disconnected. Check the current documentation; the feature has moved quickly.
2. Retire Group Policy by moving devices to Entra join and Intune, ring by ring.
3. Replace file, print and RADIUS with cloud services.
4. Stand up Entra Domain Services for the irreducible legacy set, and re-join those servers to it.
5. Retire AD CS or migrate its consumers.
6. Turn off directory sync once nothing on-prem masters any attribute. The tenant-level switch takes time to complete and is not instantly reversible; do it only when you are sure.
7. Demote the domain controllers, last, after a month of nothing authenticating against them.

Honest expectations

Nothing here is a weekend. Most organisations land at a reduced state — cloud-native devices, cloud file storage, a small Entra Domain Services footprint for two or three legacy systems — and stay there for years, which is a perfectly good outcome. The domain controllers that remain are then a legacy-application problem with a known list, not an identity platform. Microsoft support is not required for any step, but the source-of-authority conversion is the one to read the current documentation for the week you do it, because it is the newest piece and the one with the least room for a mistake.