Most organisations that say they want to "get rid of Active Directory" discover that the directory is the easy part, and the hard part is the decade of Kerberos apps, LDAP binds, Group Policy, file shares and service accounts that quietly depend on it. Retiring Active Directory Domain Services (AD DS) is a planned programme, not a vendor deadline: Microsoft has not announced an end date for AD DS, and its own Road to the cloud guidance describes the goal as either full retirement or a smaller, more secure on-premises footprint. This guide covers how to find every dependency, the order Microsoft recommends for users, devices and applications, the trade-offs of Entra Domain Services as a landing zone for legacy apps, and what the cloud-only end state looks like. It is for identity architects, infrastructure leads and the executives funding the programme. If AD is staying for now, the Active Directory and Entra ID Hardening Guide covers how to secure it; this page assumes the goal is to shrink and then remove it.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- There is no retirement deadline, only a support horizon. AD DS ships in Windows Server 2025, which Microsoft supports until November 2034; the pressure to move comes from risk, cost and cloud-native devices, not from a lifecycle date.
- Microsoft's model has five stages and three streams. Cloud Attached, Hybrid, Cloud-First, On-premises AD minimized and Cloud Only, advanced separately for users and groups, applications and devices.
- Applications decide the timeline. Modern-protocol apps move first; Kerberos, LDAP, NTLM and RADIUS apps need modernising, replacing or parking in Entra Domain Services or a small AD DS footprint in IaaS.
- Cloud-first stops the bleeding. Making Entra ID the default authority for every new user, group, app and device prevents the AD estate growing while you migrate what exists.
- Hybrid is the most dangerous stage to linger in. Sync servers, federation and dual-homed admins bridge on-premises compromise into the cloud, so treat the transition as temporary and tier 0 throughout.
What is changing and why
AD DS was designed for a network perimeter: domain-joined machines on a LAN, line of sight to domain controllers, and authentication by Kerberos and NTLM. Work now happens on devices that are rarely on that LAN, against SaaS applications that speak SAML and OpenID Connect. Microsoft's Road to the cloud guidance sets the goal as moving identity, access and device management from Active Directory to Microsoft Entra ID and other cloud-native services, for productivity, cost and security reasons.
The security case is direct. Domain controllers, AD CS, sync servers and the accounts that administer them are tier 0: compromise of any one is compromise of the whole estate. Kerberoasting (T1558.003), DCSync (T1003.006), NTLM relay and Group Policy abuse all disappear when the protocols and the directory disappear. Meanwhile, the hybrid bridge remains: sync servers and their credentials connect on-premises domain controllers to Entra ID, so protect them as tier 0. Every dependency removed shrinks that attack surface; the programme is how you get there safely.
Official timeline and current status
Facts below were checked on Microsoft Learn on 8 November 2026.
| Item | Official position | What it means for planning |
|---|---|---|
| AD DS retirement | No end date announced. Road to the cloud says the goal may be "complete Active Directory retirement or a smaller, more secure on-premises footprint". | Retirement is your decision and your schedule. |
| Windows Server 2025 (includes AD DS) | Fixed Lifecycle Policy: start 1 November 2024, mainstream support to November 2029, extended support to November 2034 | Supported domain controllers remain available for years; do not wait for a forced date. |
| Road to the cloud stages | 1 Cloud Attached, 2 Hybrid, 3 Cloud-First, 4 On-premises AD minimized, 5 Cloud Only | Use the stages as programme milestones and board reporting units. |
| Migration phases per workload | Discover, Pilot, Scale out, Cut over | Each app or device population runs through these on its own clock. |
Older dependencies have their own dates, which often force the work: Windows Server 2016 domain controllers end support on 12 January 2027 (see the Windows Server 2016 End of Support guide), and Microsoft's deprecation of NTLM and RC4 changes what legacy apps can keep doing (see the NTLM Deprecation and Elimination Guide and Kerberos RC4 Deprecation). A domain controller refresh is the natural decision point: replace it with cloud services where you can, and with fewer, newer DCs where you cannot.
Who and what is affected
| Dependency | Why it ties you to AD | Cloud-native destination |
|---|---|---|
| Users and passwords | AD is the source of authority; sync copies identities to Entra ID | Cloud HR provisioning, cloud-only accounts, SSPR and Entra Password Protection |
| Security groups and distribution lists | Group membership drives file, app and policy access | Group Source of Authority (SOA) conversion to cloud groups, dynamic membership groups, Microsoft 365 groups |
| Windows devices | Domain join, computer objects, Group Policy | Microsoft Entra join with Intune management |
| macOS and Linux | AD binding, SSSD or Kerberos realms | MDM enrolment, Enterprise SSO plug-in and Platform SSO for macOS; Entra sign-in for Linux VMs |
| Kerberos and NTLM apps | Integrated Windows authentication, SPNs, service accounts | Modernise to SAML or OIDC, or publish via application proxy; park in Entra Domain Services if needed |
| LDAP apps | Bind and search against DCs for authentication and lookups | SAML or OIDC plus SCIM provisioning, or Entra Domain Services secure LDAP as an interim |
| File servers | NTFS ACLs with AD SIDs, Kerberos to SMB | SharePoint and OneDrive, or Azure Files with Microsoft Entra Kerberos |
| VPN, Wi-Fi and RADIUS | NPS against AD | VPN providers with Entra authentication and Conditional Access; certificate-based Wi-Fi from MDM |
| Server management | GPO, Configuration Manager, WSUS | Defender for Cloud, Azure Update Manager, Azure Machine Configuration, Azure Arc for non-Azure servers |
| VDI | Domain-joined session hosts | Windows 365 or Azure Virtual Desktop with Entra-joined hosts |
| Service accounts | Kerberos SPNs, gMSAs, embedded passwords | Managed identities and workload identities, or retire with the app |
Finding affected systems and identities
Discovery is Microsoft's first phase in every stream, and the one most often skipped. Build one dependency register, keyed by application, with an owner for each row.
- Classify every application by protocol. Microsoft's triage puts apps into modern authentication (OIDC, OAuth 2.0, SAML, WS-Federation, AD FS), web access management (header or cookie SSO), and legacy (Kerberos, LDAP, RADIUS, RDP, NTLM). Each class has a different path.
- Find LDAP consumers. Microsoft lists Event1644Reader, which parses domain controller event 1644 data on LDAP queries; Microsoft Defender for Identity, which reports LDAP binds (not secure LDAP); and the PSLDAPQueryLogging project. Run collection for a full business cycle, including month and quarter end.
- Find Kerberos and NTLM consumers. Inventory SPNs on user and computer accounts, read Kerberos service ticket events (4769) and NTLM audit logs on DCs, and map each SPN to an application owner. The Active Directory Security Monitoring and Event IDs Guide covers the audit policy needed.
- Find federation dependencies. The AD FS application activity report in Entra ID shows which relying parties still authenticate through AD FS. See AD FS to Entra ID Migration.
- Export Group Policy. List every GPO linked to a populated OU, which settings it applies, and whether it targets users, workstations or servers. Settings fall into four buckets: have an Intune equivalent, needed only by servers, obsolete, or blocking.
- Map file shares and ACLs. Record which AD groups grant access to which shares; group SOA conversion and file migration must be sequenced together.
- Inventory service and machine identities. Service accounts, gMSAs, computer accounts used by apps and scheduled tasks, and anything that authenticates as a machine. The How to find and retire Active Directory service accounts walkthrough helps here.
- Find hidden infrastructure dependencies. DNS zones hosted on DCs, DHCP authorisation, AD CS templates and enrolment, NPS, print servers and time sync all tend to surface late.
Migration options
Order of work
- Cloud attached: sync identities, register devices, discover apps. AD stays authoritative.
- Hybrid: use Entra ID for SSO, MFA, Conditional Access, SSPR and Entra Password Protection (audit mode on a subset of DCs first, then enforced).
- Cloud-first: new users, groups, apps and devices are created in the cloud by default. Use cloud HR provisioning to create cloud-only accounts for staff who only use Entra-integrated apps, and lifecycle workflows for joiner, mover and leaver processes.
- Minimise: convert groups with Group SOA, move Windows devices to Entra join and Intune, migrate modern apps and decommission AD FS only after application authentication, MFA Server, federation and remote access have all moved.
- Cloud only: park or replace the last legacy apps, remove sync, decommission DCs.
Devices
Entra-joined Windows devices can still reach on-premises resources during the transition: Microsoft documents that the device receives the user's on-premises domain details with the Primary Refresh Token and can obtain Kerberos tickets or NTLM tokens. That needs line of sight to a domain controller (VPN off-site) and Entra Connect or Cloud Sync to supply the attributes. Two limits catch projects out: apps that rely on AD machine authentication do not work because Entra-joined devices have no computer object, and apps must accept UPN or FQDN-style names because NetBIOS-style domain\user fails. Group Policy does not apply to Entra-joined devices, so policy must exist in Intune before devices move; see Group Policy to Intune Migration and the Entra Device Identity guide. Hybrid join is a waypoint, not a destination.
Files
Azure Files supports Microsoft Entra Kerberos for both hybrid identities and, in Azure Public, cloud-only identities, with clients that are Entra joined or hybrid joined. Microsoft's documentation lists limits to plan for: MFA is not supported for share access, so the storage account's app must be excluded from MFA policies; File Explorer cannot set permissions for cloud-only identities; a storage account has one identity source; and tickets carry at most 1,010 group SIDs. See the Azure Files Security guide. For collaborative documents, SharePoint and OneDrive remove the SMB dependency entirely.
Legacy applications: where to park them
Microsoft's guidance gives three approaches for apps that cannot modernise, in order of preference:
| Factor | Microsoft Entra Domain Services (preferred) | Extend AD DS into Azure IaaS | New AD DS instance in Azure IaaS (last resort) |
|---|---|---|---|
| Decoupled from on-premises AD DS | Yes | No | Yes |
| Schema extensions | No | Yes | Yes |
| Full administrative control | No (managed service) | Yes | Yes |
| App reconfiguration (ACLs, authorisation) | May be needed | Not needed | May be needed |
| Configuration Manager | Not supported | Supported | Supported |
| Security posture | No domain admin; you still run domain-joined VMs and secure LDAP | Keeps the full on-premises attack surface, now in Azure | A new forest to harden and monitor |
Choosing: use Entra Domain Services when the app's needs match its supported scenarios and you can accept no schema extensions and no domain admin rights; Microsoft advises validating SQL Server domain migration first. Extend AD DS into IaaS only for apps that need full AD semantics, and treat it as the minimised footprint rather than the end state. Microsoft recommends a policy that requires an approved exception before anyone lifts and shifts AD DS to IaaS for an app with unsupported protocols. The Entra Domain Services Security Guide covers hardening the managed domain.
Small versus large organisations
A small organisation with mostly SaaS apps can often go straight to cloud-only: Entra join, Intune, SharePoint for files, and retire the one or two legacy apps. Large enterprises with mainframes, OT and acquired forests should expect a long stage 4, with a deliberately small AD footprint for named exceptions, and should report progress as dependencies removed per quarter rather than a single cut-over date.
Testing and rollback
- Pilot each stream separately. Microsoft's phases (Discover, Pilot, Scale out, Cut over) apply per workload; a device pilot does not depend on finishing groups.
- Use audit modes first. Run Entra Password Protection in Audit on a subset of DCs before Enforced; run LDAP and NTLM auditing before blocking.
- Keep reversibility on groups. Microsoft states that Group SOA conversion can be reversed, and a converted group can be provisioned back to AD DS if on-premises access still needs it. Convert in small batches mapped to app owners.
- Device ring rollout. IT, then a business pilot, then waves by site. Rollback for an individual device is re-imaging with the previous build, so keep the domain-join build available until the final wave.
- Brown-out before decommissioning. Before removing a DC or an AD FS farm, stop the service for a few hours in a controlled window and watch for failures, then restore. Only demote after a clean full business cycle.
- Keep recovery capability until the end. Maintain tested AD backups and a forest recovery plan until the last DC is gone. See the Identity Recovery Guide.
Risks of doing nothing
- Permanent hybrid: sync servers, federation and dual-homed administrators remain a bridge from on-premises into the cloud. Keep cloud admin accounts cloud-only throughout; see the Microsoft Entra Connect and Cloud Sync Hardening guide.
- Legacy protocol exposure: Kerberoasting, NTLM relay, LDAP credential capture and DCSync remain live techniques while the protocols remain in use.
- Growth by default: without a cloud-first rule, every new app and server adds another AD dependency.
- Orphaned service accounts: legacy apps carry service accounts with old passwords and broad rights that nobody owns.
- Forced migrations: NTLM and RC4 changes and server end of support dates arrive whether or not the programme is ready.
| Risk | ATT&CK technique | Control in the programme | NIST SP 800-53 / CSF 2.0 |
|---|---|---|---|
| Service ticket cracking | T1558.003 Kerberoasting | Retire SPN service accounts, move to managed identities | IA-5; PR.AA-01 |
| Directory replication abuse | T1003.006 DCSync | Fewer DCs and fewer replication rights, then none | AC-2, CM-7 |
| On-premises to cloud pivot | T1078.004 Cloud Accounts | Cloud-only admins, tier 0 sync servers, remove sync at the end | AC-2, IA-2; PR.AA-03 |
| Unknown dependencies | Not a technique | Dependency register | CM-8; ID.AM-01 |
| Inconsistent configuration | Not a technique | GPO replaced by Intune and Azure Machine Configuration | PR.PS-01 |
Metrics: percentage of users that are cloud-only; percentage of Windows devices Entra joined; number of apps still using Kerberos, NTLM or LDAP; number of GPOs still linked to populated OUs; number of domain controllers; number of AD service accounts. Report them by Road to the cloud stage.
Practitioner checklist
- Agree the target with executives: full retirement, or a named minimal footprint, and the stage at which each business unit stops.
- Adopt a cloud-first rule: every new user, group, app and device is created in Entra ID unless an exception is approved.
- Build the dependency register: apps by protocol, LDAP and Kerberos consumers, GPOs, shares, service accounts, DNS, DHCP, AD CS and NPS, each with an owner.
- Deploy SSPR, combined registration and Entra Password Protection (audit, then enforced).
- Move Windows devices to Entra join and Intune, with policy recreated in Intune before each wave.
- Convert groups with Group SOA in batches matched to app and share migrations.
- Migrate modern apps off AD FS and decommission it only after authentication, MFA Server, federation and remote access have moved.
- Park unmodernisable apps in Entra Domain Services where possible, with an exception and retirement date for each.
- Keep sync servers and remaining DCs as tier 0 and admin accounts cloud-only until the last DC is demoted.
- Brown-out each service before final decommissioning and keep forest recovery tested until the end.
Standards and references
- Microsoft Learn: Road to the cloud, introduction
- Microsoft Learn: Transition to the cloud (Road to the cloud)
- Microsoft Learn: How SSO to on-premises resources works on Microsoft Entra joined devices
- Microsoft Learn: Microsoft Entra Kerberos authentication for Azure Files
- Microsoft Learn: Group Source of Authority overview
- Microsoft Learn: Group provisioning to Active Directory with Cloud Sync
- Microsoft Lifecycle: Windows Server 2025
Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide, Entra ID Security Guide, Entra Domain Services Security Guide, Microsoft Intune Guide.