Microsoft Entra ID

Microsoft Entra ID is the identity provider for the Microsoft cloud: a multi-tenant directory of users, groups, devices, and applications, and a token service that issues OAuth 2.0 and OpenID Connect tokens proving who — or what — is calling. Nearly every authorisation decision in Azure begins with a token that Entra ID signed.

Names: this service was Azure Active Directory (Azure AD) until 2023, and before that "Windows Azure Active Directory". The rename was cosmetic — the API, the tokens, and the object model are unchanged — but it renamed a lot of surface area you will still meet under the old name: Azure AD B2C is now Microsoft Entra External ID, Azure AD Domain Services is Microsoft Entra Domain Services, Azure AD Connect is Microsoft Entra Connect, and the AzureAD / AzureADPreview PowerShell modules are retired in favour of Microsoft Graph PowerShell. The Terraform provider is still called azuread, the Graph resource is still graph.microsoft.com, and old blog posts still say "Azure AD". None of that is wrong; it's just old.

It is also not Active Directory. Windows Server Active Directory Domain Services (AD DS) is an on-premises LDAP and Kerberos directory organised into forests, domains, and organisational units. Entra ID is an internet-facing, HTTPS-only identity provider organised into a single flat tenant, speaking OAuth 2.0, OIDC, and SAML. They are frequently synchronised together, and the shared word "Active Directory" has probably caused more architectural confusion than any other name in Azure.

What it is and where it fits

Every Azure request is authorised in two steps that people routinely collapse into one. Authentication asks who are you, and Entra ID answers it by issuing a signed JWT. Authorisation asks are you allowed, and that is answered separately — by Azure RBAC for Azure resources, by directory roles for the directory itself, and by application-specific logic for everything else. Entra ID owns the first step everywhere and the second step only within its own boundary. Holding those apart is the single most useful thing on this page.

The problem it solves is one that predates the cloud: an organisation with 5,000 employees and 200 SaaS applications either has 200 separate user databases, 200 offboarding checklists, and 200 ways to be breached — or it has one directory that all 200 trust. Entra ID is that directory, plus the federation protocols that let applications trust it without ever seeing a password.

Entra ID is not an Azure resource. This is the structural fact that makes it different from every other topic in this article. There is no Microsoft.AzureActiveDirectory/tenants resource you can terraform apply into a resource group. A tenant sits above subscriptions — a subscription trusts exactly one tenant for authentication, while a tenant can own many subscriptions — and its objects are managed through Microsoft Graph, not Azure Resource Manager. So azurerm cannot create a user, ARM templates and Bicep cannot (in general) create an app registration, and being Owner on every subscription in the tenant gives you no directory permissions at all. See the scope hierarchy for where the tenant sits, and Identity and RBAC for the principal types and role-assignment mechanics this topic builds on.

The neighbours it gets confused with, separated in a line each:

• Azure RBAC — the authorisation system for Azure resources. It consumes Entra identities but is a different system with different roles stored in ARM, not the directory. "Global Administrator" and "Owner" are not the same job.
• Microsoft Entra External ID (formerly Azure AD B2C) — the same platform aimed at customers rather than employees: self-service sign-up, social identity providers, custom-branded journeys, and per-monthly-active-user billing. Use it when the users are your product's customers.
• Active Directory Domain Services (AD DS) — the on-premises Kerberos/LDAP directory. Entra ID does not speak LDAP or Kerberos. If an application needs those, you need AD DS, or Entra Domain Services (a managed AD DS domain, which is an actual Azure resource).
• Entra Privileged Identity Management (PIM) — not a separate directory but a P2 feature over it: make a role assignment eligible rather than permanent, requiring activation, approval, and justification.
• Managed identities — an Entra service principal whose credentials Azure manages for you. They live in the directory, but you create them through ARM, which is why they feel like they belong to a different service.

If you're coming from AWS: the closest analogue to Entra ID is the identity half of IAM, plus IAM Identity Center (SSO) and Cognito user pools. What transfers: principals, federation, trust policies, short-lived tokens. What breaks, and breaks hard — AWS IAM is scoped to an account and policies and identities live in the same system, whereas in Azure identity is scoped to a tenant that sits above every subscription, and authorisation lives in an entirely separate system (Azure RBAC). An AWS IAM policy is attached to a principal; an Azure role assignment is attached to a scope and references the principal. And AWS has no equivalent of Conditional Access — the policy engine that evaluates device, location, risk, and application at every token issuance — which is arguably the most important thing Entra ID does.

Key facts at a glance

Category	Security & identity — identity provider and directory (PaaS/SaaS, not IaaS)
Resource provider	None in the usual sense. Objects live in Microsoft Graph (https://graph.microsoft.com/v1.0/…). Related ARM providers exist for adjacent things: Microsoft.ManagedIdentity/userAssignedIdentities, Microsoft.Authorization/roleAssignments, Microsoft.AAD/domainServices
Scope	Global, per tenant. The directory is replicated worldwide; data residency is set by the tenant's home region and cannot be changed after creation ⚠️ verify current residency options against current Azure docs
Unit of identity	The tenant — one directory, one boundary, one set of policies. Identified by a GUID and one or more verified domains
The SKU axis	Free → Microsoft Entra ID P1 → P2, licensed per user per month, plus add-ons: Microsoft Entra ID Governance, Microsoft Entra Workload ID, and the Entra Suite (Private Access, Internet Access). External ID bills per monthly active user instead
What each tier unlocks	Free: users, groups, SSO, security defaults, basic MFA. P1: Conditional Access, group-based app assignment, dynamic groups, self-service password reset with writeback, Entra Connect group writeback. P2: Identity Protection (risk-based policies), PIM, access reviews. ⚠️ verify exact feature-to-tier mapping against current Azure docs — Microsoft moves features between tiers
The licensing trap	Licences are per user who benefits from the feature, not per tenant. If one Conditional Access policy targets "All users", every user in scope needs P1 — including guests, under a separate external-collaboration licensing model. Nothing blocks you technically; you find out at audit
Unit of billing	Per licensed user per month; External ID per MAU; Domain Services per hour of the managed domain
SLA posture	A high availability SLA applies to paid tiers only — the Free tier has no financially-backed SLA ⚠️ verify current percentages and terms against the current SLA document
Control plane	Microsoft Graph (management of directory objects)
Data plane	The token endpoints at login.microsoftonline.com (/authorize, /token) — sign-in and token issuance
Usual companions	Azure RBAC, Key Vault, managed identities, Conditional Access, Log Analytics, Microsoft Defender for Cloud / Sentinel, every PaaS service that supports Entra auth
Primary alternative	Okta, Ping, Auth0, or Google Workspace as the IdP — federated into Entra ID rather than replacing it, because Azure resource access always requires an Entra token
AWS rough analogue	IAM (identity half) + IAM Identity Center + Cognito, and the analogy breaks at the tenant/account boundary

When Entra ID is the right tool

• Single sign-on for workforce applications — SaaS, line-of-business web apps, and anything that speaks SAML 2.0, OIDC, or OAuth 2.0. One directory, one offboarding action.
• Authenticating workloads without secrets. Managed identities and workload identity federation remove connection strings and client secrets from configuration entirely. This is the single highest-value security change available in Azure and it costs nothing.
• Risk- and context-aware access control. Conditional Access evaluating device compliance, network location, sign-in risk, and application sensitivity at every token request is a control that has no equivalent in a static permission model.
• Any access to Azure resources at all. There is no opting out — every ARM call carries an Entra token.
• B2B collaboration. Inviting a partner's identity as a guest is safer than creating an account for them, because their home tenant owns the credential and the offboarding.
• Governance at scale — access reviews, entitlement management, and time-bound privileged access through PIM, once the organisation is large enough that "who has admin?" is a real question.

When it isn't

• Customer-facing sign-up and sign-in. Use Microsoft Entra External ID. Putting consumers in your workforce tenant mixes billing models, licensing, and blast radius, and it is very hard to unpick later.
• Applications needing LDAP or Kerberos. Entra ID speaks neither. Use AD DS, or Entra Domain Services if you want a managed one.
• As a general-purpose user profile database. Directory extension attributes exist, but the directory is a security store with strict replication and query characteristics — not a place to keep application data.
• When your organisation already standardises on another IdP. Federate it in and let Entra ID be the token issuer for Azure specifically, rather than running two competing sources of truth.
• As a substitute for Azure RBAC design. Adding people to Global Administrator because "they needed access" is the classic failure. Directory roles and resource roles are separate for a reason.

What this topic covers

Sub-topic	What it covers
What & Why	The problem Entra ID kills, why it is not Active Directory and not an Azure resource, the AWS analogue and where it breaks, and the honest anti-patterns
Core Concepts	Tenants and domains, users and guests, groups, app registrations vs. enterprise applications, scopes vs. app roles, consent, the licensing SKU axis, and the vocabulary traps
Architecture	An authorisation-code sign-in traced end to end, control plane vs. data plane, token contents and validation, Conditional Access evaluation, refresh tokens and revocation latency, throttling, and the failure modes
Getting Started	Register an app, grant it a role on a resource, and get a token — three ways, portal, az/Graph PowerShell, and minimal Terraform — plus teardown
Deployment	A parameterised azuread Terraform module, remote state, an Ansible playbook, why Bicep mostly can't do this and what the Graph extension changes, OIDC-based CI/CD, environments, rollback, and drift
Integrations	Key Vault, App Service and Functions Easy Auth, AKS workload identity, Azure SQL, API Management, Log Analytics, and the two glue mechanisms that recur everywhere
Production	Security, cost and licensing, scaling and directory limits with their scopes, observability through the sign-in and audit logs, and reliability including the backup authentication service
Interview Questions	Three tiers with answer keys, from "what is a tenant" to "someone consented to a malicious app — what now"
Glossary & Cheatsheet	Every term in one line, the commands you'll actually type, the object ID shapes, and the limits worth memorising

Three ideas worth carrying into every other page

Authentication is not authorisation. Entra ID proves identity and issues a token. What that token is allowed to do is decided elsewhere — by Azure RBAC at a resource scope, by a directory role in the tenant, or by the application reading roles and scp claims. Most "permissions bugs" in Azure are one of these three being confused for another.

A tenant is a security boundary; a subscription is a billing and blast-radius boundary. Many subscriptions can trust one tenant. A subscription can be moved to a different tenant, and doing so orphans every role assignment and managed identity in it, because those principals existed in the old directory. Nobody expects this the first time.

The default is too permissive and the fix is free. A brand-new tenant lets any user create app registrations, invite guests, and consent to third-party applications on their own behalf. Three settings changed on day one — restrict app registration, restrict guest invitation, and require admin consent for applications requesting permissions — remove the most common tenant compromise paths and cost nothing. Production covers the full list.

Reading paths

• New to Entra ID: What & Why → Core Concepts → Getting Started.
• Interview preparation: Core Concepts → Architecture → Interview Questions.
• You need to ship something: Getting Started → Deployment → Integrations.
• Securing an existing tenant: Production → Architecture (Conditional Access evaluation) → Core Concepts (consent).
• Debugging a 403: Architecture, then the 403 checklist in foundations.

---

Start here: What & Why →

← Back to the article contents