Designing Identity and Access Management on Azure: Microsoft Entra ID vs Active Directory

First in a series of notes on Microsoft Entra ID, Microsoft's cloud-based identity and access management (IAM) service. This post covers the design principles behind a good IAM solution, how cloud-only and hybrid identity differ, and how Entra ID compares structurally to on-premises Active Directory Domain Services (AD DS).

Designing identity and access management on Azure

Before choosing a specific service, it's worth stepping back to what a good IAM solution needs to do for an organisation. When Azure architects design authentication and authorisation for an organisation, the solution has to work across users, applications, and devices, and it generally needs to deliver on four things at once:

Unified identity management means managing all identities and access to all applications from a central location, whether those applications sit in the cloud or on-premises, so you get one place to look for visibility and control.

Seamless user experience means keeping sign-in fast and simple, so users stay productive instead of losing time to password resets and repeated logins.

Secure adaptive access means protecting resources with strong authentication and risk-based, adaptive access policies, without making the sign-in experience painful enough that users start working around it.

Simplified identity governance means controlling access for all users and admins through automated governance, so only people who are actually authorised end up with access — rather than relying on someone remembering to clean up permissions later.

Alongside these four, it's also worth considering your business-to-business (B2B) and business-to-customer (B2C) requirements up front, since they shape which Entra features and licensing tier you actually need.

Cloud-only vs hybrid identity

Microsoft Entra ID is the current name for what used to be Azure Active Directory. You can run it as a cloud-only identity solution, which gives you identity management and protection — role-based access control (RBAC), conditional access, access reviews — without any on-premises footprint. Or you can run it as a hybrid identity solution, where Microsoft Entra ID extends on-premises Active Directory into the cloud.

For hybrid environments, a few design considerations come up repeatedly:

Centralised identity management helps users be more productive by giving them one identity for both cloud and on-premises resources, instead of maintaining separate credentials in each world. Using a single Microsoft Entra instance as the one authoritative source increases clarity and reduces the security risk that comes from human error and configuration complexity — the more instances you have, the more places a mistake can hide.

Limiting account synchronisation matters more than the phrase suggests. The general guidance is not to synchronise accounts into Microsoft Entra ID that already hold high privileges in your on-premises Active Directory. I'd originally read this as "Microsoft Entra Connect filters these out by default," which turns out to overstate it: the default Microsoft Entra Connect configuration only excludes the built-in Administrator account (RID 500) — it does not filter out Domain Admins or Enterprise Admins by default. Protecting those groups requires deliberately setting up OU-based or attribute-based filtering. The risk being mitigated is real either way: an adversary who compromises a synced high-privilege account can pivot from cloud back into on-premises assets, which is exactly the kind of blast radius you don't want a single sync misconfiguration to create. (The mechanics of Entra Connect filtering itself are covered in more depth in the dedicated hybrid identity post later in this series.)

Password hash synchronisation is worth enabling even alongside federation. Password hash synchronisation syncs user password hashes from on-premises AD to Microsoft Entra ID, and it doubles as a backup authentication path if your on-premises federation servers go down. It also lets Identity Protection compare synced hashes against known-compromised credentials, catching password reuse across services Microsoft Entra ID otherwise can't see into.

Single sign-on (SSO) reduces the number of passwords users juggle, which matters because more passwords tends to mean weaker or reused passwords. With SSO, users authenticate once with their primary work or school account, and application access is then provisioned or de-provisioned automatically based on group membership and employment status — rather than someone manually granting or revoking app access as people join, move, or leave.

The alternative — managing separate identities per system — carries a real cost: it's extra account administration, and every extra manual step is another chance for a mistake that turns into a security gap.

Microsoft Entra ID vs Active Directory Domain Services

AD DS and Microsoft Entra ID solve related problems in different environments, and the differences run deeper than "one's on-prem and one's cloud."

The practical upshot: AD DS is a full directory service built for managing on-premises resources, while Microsoft Entra ID is primarily an identity solution built for internet-based applications. If you're planning a migration or a hybrid setup, that's the axis most of your design decisions will sit on.

Microsoft Entra tenants

A tenant represents an organisation that subscribes to Microsoft cloud services — technically, it's a single Microsoft Entra instance. Microsoft Entra ID is designed to be multi-tenant, and an organisation is free to create multiple tenants, commonly for testing or isolation purposes. Each Azure subscription must be associated with exactly one Microsoft Entra tenant, though a single tenant can have multiple subscriptions associated with it. Every tenant gets a default domain name ending in onmicrosoft.com, and you can add custom domain names on top of that (covered in practical detail in the tenant-setup post later in this series).

Schema

The Microsoft Entra schema is deliberately simpler than the AD DS schema. There's no computer class — Microsoft Entra ID uses a device class instead to represent device objects, which is the mechanism behind Microsoft Entra-joined and Microsoft Entra-registered devices. There are also no organisational units; group membership does the organisational work OUs would otherwise do. The schema is easily extensible, and extensions are reversible.

Gotchas and caveats

The "Entra Connect filters out privileged accounts by default" claim is the one I'd flag most strongly from this material — it's the kind of assumption that feels safe until you check the actual scope of the default filter and find it only covers the single built-in Administrator account, not the groups you'd actually worry about. Anyone designing a hybrid sync topology should treat OU- or attribute-based filtering of Domain Admins/Enterprise Admins as something to configure deliberately, not something Connect does for you.

Sources

• Azure identity management and access control best practices — Microsoft Learn
• What is a Microsoft Entra joined device? — Microsoft Learn
• What is hybrid identity with Microsoft Entra ID? — Microsoft Learn
• What is password hash synchronization with Microsoft Entra Connect Sync? — Microsoft Learn