Active Directory — Part 13 — Active Directory & the Cloud (Azure AD / Entra ID)
Every year someone declares Active Directory dead, and every year most enterprises keep running it. This part closes the series by looking upward: how traditional AD relates to Microsoft Entra ID (formerly Azure AD), what hybrid environments actually look like, what changed, what stayed the same, and where identity is heading.
On-premises directory: Kerberos, LDAP, Group Policy, Domain Controllers.
Cloud identity platform: web protocols, MFA, Conditional Access. Formerly Azure AD.
The sync engine bridging the two — one identity, both worlds.
Introduction
Twelve parts of this series have described a system designed in the late 1990s: Domain Controllers on your network, Kerberos tickets on your LAN, Group Policy for machines you own, in offices you control.
Then the world moved. Applications became websites. Laptops stopped coming back to the office. People sign in to company data from phones on hotel Wi-Fi. None of that is what Kerberos, covered in Part 5, was built for.
So did Active Directory become obsolete? Not quite — something more interesting happened. A second identity system grew up alongside it, built for the web-shaped world, and most organisations now run both. Understanding how the two relate is the final piece of understanding modern AD.
First, the Name
In July 2023, Microsoft renamed Azure Active Directory to Microsoft Entra ID. Nothing technical changed — no migration, no feature loss, purely branding. Part of Microsoft’s motivation was the very confusion this post addresses: the old name made Azure AD sound like Active Directory hosted in Azure, which it never was.
You will see both names in documentation, job titles, and conversation for years. In this post: AD means the on-premises directory from this series; Entra ID means the cloud identity platform.
The Landline and the Smartphone
Think of AD and Entra ID like a landline network and a mobile network.
The landline was engineered for one building: wired handsets, an internal switchboard, excellent within its walls, useless outside them. The mobile network was designed from scratch for people who move — different towers, different protocols, coverage anywhere.
You cannot upgrade a landline exchange into a mobile network; they are different designs solving different problems. But you can absolutely keep one number that rings on both — and that, in essence, is what hybrid identity does with your user accounts.
What Actually Differs
| Aspect | Active Directory | Entra ID |
|---|---|---|
| Authentication | Kerberos and NTLM (Part 5). | OAuth 2.0, OpenID Connect, SAML — web protocols. |
| Structure | Forests, domains, OUs in a hierarchy (Parts 2 and 4). | A flat tenant. No OUs, no forests. |
| Machine management | Group Policy (Part 6) on domain-joined machines. | Intune / MDM policies on enrolled devices. |
| Finding services | DNS SRV records and the DC locator (Part 8). | Well-known internet URLs. No SRV records. |
| Infrastructure you run | Domain Controllers, replication, backups (Parts 7 and 12). | None — Microsoft runs the platform. |
| Trust between organisations | Trust relationships (Part 9). | B2B guest accounts and federation. |
| Reaches | Your network, your VPN. | Anywhere with internet. |
The deepest difference is the security model. AD assumes the network perimeter means something: being on the LAN is step one of trust. Entra ID assumes there is no perimeter — every sign-in arrives from the open internet, so identity itself becomes the perimeter, defended with multi-factor authentication and Conditional Access policies that weigh who is signing in, from where, on what device, and how risky it looks.
Hybrid: Running Both
Almost no established organisation chose one or the other. They run both, joined by Microsoft Entra Connect (long known as Azure AD Connect) — a sync engine installed on-premises that projects users, groups, and devices from AD into the Entra ID tenant.
The result is one identity in both worlds: skaranth@corp.example.com logs on to the office file server with Kerberos and into Microsoft 365 with OAuth, with the same password. On-premises AD remains the source of authority — accounts are created, disabled, and managed there, and sync pushes the changes upward, typically every 30 minutes.
How passwords are checked in the cloud is a choice. With password hash synchronisation, a hash of the password hash is synced and Entra ID validates sign-ins itself — simple, and sign-in survives your site being offline. With pass-through authentication, cloud sign-ins are validated live against your Domain Controllers via lightweight agents — passwords never leave the building, but your DCs are now in the critical path for cloud logins. Federation with AD FS, the heavyweight third option, is fading in favour of the first two.
What Stayed the Same
Beneath the new protocols, everything this series taught still applies. Identity is still the control plane — the thing attackers want and defenders guard. Least privilege from Part 11 maps directly onto Entra roles and Conditional Access. Lockouts and credential hygiene from Part 10 have exact cloud counterparts in smart lockout and banned-password lists. Even the tier model survives intact, with the tenant and the sync server joining the Domain Controllers in Tier 0.
And the operational habits transfer whole: know your privileged accounts, monitor the quiet machinery, back up the things whose loss is unthinkable, and check health before users report it — Part 12, with different command names.
Where Things Are Heading
The direction of travel is unambiguous: new capability lands in Entra ID first, and greenfield companies increasingly never build AD at all — cloud-native identity, Intune-managed laptops, no Domain Controllers anywhere.
For everyone else, the honest picture is long coexistence. Enterprises carry decades of applications that speak Kerberos, LDAP, and Group Policy, and those do not rewrite themselves. On-premises AD will run in such organisations for many years — which is precisely why the fundamentals in this series remain career-relevant even as the industry’s centre of gravity moves cloudward.
What changes for the administrator is emphasis. The AD skills stay necessary; the growth is in the joins — sync health, Conditional Access design, protecting a Tier 0 that now spans building and cloud. The interesting work lives at the seam.
Scripts / Commands
Hybrid brings a small operational surface of its own. These run on the Entra Connect server and on clients; all are read-only except the sync trigger.
# On the Entra Connect server: is the sync scheduler healthy?
Get-ADSyncScheduler
# Trigger an immediate delta sync (instead of waiting for the cycle)
Start-ADSyncSyncCycle -PolicyType Delta
# On any Windows client: what is this device's identity state?
# Look for YES under AzureAdJoined and/or DomainJoined
dsregcmd /status
# On-prem side of hybrid health: the usual suspects still apply
repadmin /replsummary
dcdiag /q
Get-ADSyncScheduler should show the sync cycle enabled with a recent successful run, and dsregcmd /status on a hybrid-joined laptop should show both DomainJoined and AzureAdJoined as YES. Sync problems surface as “I changed it in AD but the cloud disagrees” — always check the scheduler before anything deeper.
Quick Reference Summary
| Term | Meaning |
|---|---|
| Entra ID | Microsoft’s cloud identity platform; renamed from Azure AD in 2023. |
| Tenant | An organisation’s instance of Entra ID. Flat — no OUs or forests. |
| Entra Connect | On-premises sync engine projecting AD identities into the tenant. |
| Password hash sync | Cloud validates sign-ins using a synced hash of the password hash. |
| Pass-through authentication | Cloud sign-ins validated live against your Domain Controllers. |
| Conditional Access | Per-sign-in policy engine: who, where, what device, how risky. |
| Hybrid join | A device registered in both AD and Entra ID at once. |
| Source of authority | Where an identity is mastered — on-premises AD, in most hybrids. |
| Entra Domain Services | Managed domain in Azure offering Kerberos/LDAP for legacy workloads. |
Final Thoughts
This series began with a question about what happens when you press Ctrl+Alt+Del, and ends thirteen parts later at the seam between a directory born in 1999 and an identity platform built for a perimeterless internet. The striking thing is how little the fundamentals moved: authentication and authorisation, replication and convergence, least privilege and blast radius — the vocabulary changed clothes, not meaning.
Active Directory is not dead, and it is not the future either. It is infrastructure in middle age: load-bearing, unfashionable, and quietly present under systems that will outlast every prediction of its demise. Understanding it deeply — which is what these thirteen parts have tried to build — remains one of the most durable investments an infrastructure engineer can make.
Next, we can return to a promise made back in Part 6: Group Policy troubleshooting in depth — gpupdate, gpresult, RSOP, event logs, replication delays, and how to prove which GPO actually applied.