On-premises Active Directory to cloud-first Microsoft Entra ID
Cohash moves organizations from Active Directory as the master directory to cloud-first Microsoft Entra ID. It starts with an inventory of every application and how it authenticates. Security groups go to cloud source of authority first, users after. Kerberos and LDAP apps are bridged with Application Proxy, Cloud Kerberos trust, Cloud Sync or Entra Domain Services. We don't shrink the domain until each app has proven it can live without it.
- 01Inventory apps by authentication type
- 02Move security groups first
- 03Bridge Kerberos and LDAP apps
- 04Devices and passwordless
- 05Convert users with no AD dependency
- 06Shrink the domain
The story
Told without the client's name or anything that could identify them.
A regional manufacturer's infrastructure group had domain controllers on Windows Server 2016 and a replacement budget nobody wanted to approve. Cloud-only apps still got their groups in AD because the old provisioning tool wrote there, and nobody could say which intranet apps still bound over LDAP or used Kerberos. We started with domain controller logs and Global Secure Access discovery to sort every app by how it authenticated. Security groups moved to cloud source of authority first, Kerberos apps went behind Application Proxy, and users converted in batches as their apps stopped needing AD. What remained was a small domain where every leftover app has a written reason and a retirement date.
why it was urgentMicrosoft's cloud-first identity guidance, updated in August 2026, now describes moving the source of authority for users and groups from AD to Entra ID in phases. There is no single cut-over. Windows Server 2016 leaves extended support in January 2027 as well, which means domain controllers on that release get replaced or retired whichever way you go.
- openDomain controllers are still on Windows Server 2016 while the replacement budget gets debated.
- recurringGroups still get created in AD just because the old provisioning tool writes there, even when the app is cloud-only.
- blockedNobody can say which applications still bind to AD over LDAP or rely on Kerberos.
- openMicrosoft 365 is behind Conditional Access. The intranet apps people use every day aren't.
The estate, before and after
Before: Active Directory mastered every user and group
Users and groups were created in AD and synced up to Entra ID, even for cloud-only apps. Intranet apps used Kerberos and LDAP directly against domain controllers on Windows Server 2016, outside Conditional Access.
Read the diagram as text
- Legacy provisioning tool → Active Directory: create groups
- Active Directory → Entra Connect Sync: sync
- Entra Connect Sync → Microsoft 365: users · groups
- Active Directory → Intranet web apps: kerberos tickets
- Active Directory → LDAP-bound apps: LDAP bind
- Active Directory → Domain-joined devices: domain sign-in
After: Entra ID is the source of authority
Groups and users are mastered in Entra ID now, and Cloud Sync provisions back only what remaining apps still read. Intranet apps sit behind Application Proxy. Entra-joined devices use Cloud Kerberos trust to reach what's still on-premises.
Read the diagram as text
- Microsoft Entra ID → Cloud Sync: group changes
- Cloud Sync → Reduced AD domain: provision back
- Microsoft Entra ID → Application Proxy: conditional access
- Application Proxy → Intranet web apps: KCD
- Microsoft Entra ID → Cloud Kerberos trust: partial TGT
- Cloud Kerberos trust → File shares: kerberos ticket
- Entra-joined devices → Microsoft Entra ID: sign-in
- Microsoft Entra ID → Microsoft 365: OIDC · SAML
How we run it, phase by phase.
6 phases take you from On-premises Active Directory to Cloud-first Microsoft Entra ID. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory apps by authentication type
Start with domain controller logs and Global Secure Access application discovery. Between them they show which apps use Kerberos or NTLM, LDAP binds, federation or RADIUS, and we map each app to the AD groups and users that gate access to it.
- phase 02
Move security groups first
Security groups move to cloud source of authority first. Where an app still reads AD, Cloud Sync provisions the group back. Distribution lists and mail-enabled groups wait until Exchange is fully online.
- phase 03
Bridge Kerberos and LDAP apps
We put web apps on Windows authentication behind Application Proxy or Private Access, using Kerberos constrained delegation. LDAP-bound apps get one of two fixes. Either cloud-managed users are provisioned back to AD, or the app is repointed at Entra Domain Services.
- phase 04
Devices and passwordless
We move devices to Entra join. Windows Hello for Business and Cloud Kerberos trust are in place, so users still reach file shares and other on-premises resources without an AD password prompt.
- phase 05
Convert users with no AD dependency
When a user's apps no longer need AD, that user converts to cloud source of authority. We do it in batches. Before the next batch starts, somebody reads the group and user audit logs from the last one.
- phase 06
Shrink the domain
Whatever writes to AD or has to work offline stays on the remaining domain. We delete unused groups, OUs and domain controllers. Anything we leave behind gets a written reason.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Groups and users are mastered in Entra ID
Security groups and converted users have Entra ID as their source of authority. Cloud Sync writes groups back to AD only where an app still reads them there.
- result 02
Intranet apps sit behind Conditional Access
We published Windows-authentication web apps through Application Proxy or Private Access with Kerberos constrained delegation. They now sit under the same Conditional Access policies that cover Microsoft 365.
- result 03
Users reach file shares without an AD password prompt
Entra-joined devices with Windows Hello for Business and Cloud Kerberos trust get tickets for on-premises resources, so file shares keep working after users convert.
- result 04
Every app left on AD has an owner and a date
We listed every app that writes to AD or needs an AD password, with an owner and a retirement date. Unused groups, OUs and domain controllers were removed, with rollback planned per batch.
Risks we plan for
-
No password writeback for cloud-provisioned users
Microsoft states password writeback isn't available for users provisioned from Entra ID back to AD. Apps that need an AD password keep those users on AD until the app changes.
-
Apps that write to AD
Some older apps expect a user in a specific OU or write attributes back. They are out of scope for this move and need a retirement date, not a workaround.
-
Domain-joined-only devices
Cloud-managed users on devices that are only domain joined lose single sign-on to Kerberos resources. Device migration has to keep pace with user conversion.
-
Exchange-dependent groups
Mail-enabled security groups and distribution lists can't be managed in Entra ID or Graph directly. Converting them before Exchange moves breaks mail routing.
Where AI helps, and where it needs guardrails
Microsoft Entra Agent ID gives AI agents their own identities, sponsors and access packages, and Microsoft 365 Copilot works within each user's existing permissions, many of which come from AD groups. Cleaning group membership during the move narrows what Copilot can surface. We also build read-only inventory tools, sometimes exposed through an MCP server with a scoped Graph app registration, so assistants can answer which app uses which group without write access to the directory.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Application inventory with authentication type, groups, users and bridge decision per app
yours to keep - plan02
Group and user source-of-authority conversion plan in batches
yours to keep - document03
Cloud Sync, Application Proxy and Cloud Kerberos trust configuration notes
yours to keep - inventory04
List of apps that stay on AD, each with an owner and retirement date
yours to keep - plan05
Domain controller reduction plan with rollback for each batch
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Can we turn off Active Directory completely?
Some organizations can. Most keep a smaller domain for apps that write to AD, work offline or can't be proxied. The goal is a domain that only holds what still needs it, with a date for each remaining app.
02Do we move users or groups first?
Groups. Microsoft recommends converting security groups first so memberships stay intact and app access can be tested before any user changes. Users follow in batches once their apps are bridged.
03What licenses do we need?
It depends on the features. Application Proxy and Conditional Access need Entra ID P1 or higher, and governance features such as lifecycle workflows and access reviews need Entra ID Governance. We map features to licenses during the inventory so there are no surprises.
04Is this the same as moving off AD FS?
Related, but separate. AD FS handles federated sign-in, and moving that to Entra authentication is often step one. This scenario goes further. It changes where users and groups are mastered.
Often on the same roadmap
AD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case studyNasdaq Calypso upgrade to V19
Upgrading Nasdaq Calypso to V19, with server consolidation, properties moved to the database, the WebUI and deployment changes tested on your own trades.
read the case study8038d1aa - 01Microsoft Learn: Microsoft Entra cloud-first identity guidance (updated Aug 2026)learn.microsoft.com ↗
- 02Microsoft Learn: Embrace cloud-first posture and convert Group Source of Authoritylearn.microsoft.com ↗
- 03Microsoft Lifecycle: Windows Server 2016learn.microsoft.com ↗
- 04Microsoft Learn: What's new in Microsoft Entra Agent IDlearn.microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it