What is Microsoft Entra ID?

What is Entra ID?

Microsoft Entra ID is Microsoft's cloud identity and access management service. It is the directory of users, groups, and applications that decides who can sign in to what - whether the "what" is Microsoft 365, the Azure portal, a SaaS app like Salesforce, or your own custom application registered against it.

It speaks the protocols every modern stack already knows - OpenID Connect, OAuth 2.0, and SAML - so apps integrate with it the same way they would with any other identity provider. What is distinctive about Entra ID is the reach: it is the same directory that Microsoft 365 and Azure already authenticate against, so adding it to a new app usually means the same users your organization already has.

Microsoft Entra ID is a cloud-based identity and access management service that helps your employees access external resources and internal resources.- Microsoft Learn

It is the foundation of the Microsoft Entra family. Every other Entra product - External ID, ID Governance, Permissions Management, Private Access, Internet Access - assumes Entra ID is there. If you only learn one piece of Entra first, this is the piece.

The Azure AD rename

One thing trips up everyone who started before 2023: "Azure Active Directory" and "Microsoft Entra ID" are the same product. Microsoft renamed it as part of consolidating the identity family under the Entra umbrella - same service, same APIs, same endpoints, new label.

If you read a tutorial that mentions Azure AD, app registrations in Azure AD, or Azure AD B2B - assume Entra ID and keep going. The Azure portal still has an "Microsoft Entra ID" blade in the same place "Azure Active Directory" used to live; the dedicated admin center at entra.microsoft.com is the surface Microsoft now actively designs around.

The tenant

A tenant is your dedicated instance of Entra ID. It contains your users, your groups, your app registrations, your sign-in policies, and the secrets and certificates those apps use to talk to it. Every organization that uses Microsoft 365 or Azure has at least one tenant - it was created the moment they signed up.

The tenant has two identifiers worth knowing:

• Tenant ID - a GUID like 11111111-2222-3333-4444-555555555555. This is what app config files, scripts, and OIDC URLs use to point at your directory.
• Default domain - something like contoso.onmicrosoft.com, assigned at creation. You almost always add one or more verified custom domains on top (contoso.com) so usernames look right.

Tenants are isolated. A user in contoso.com is not a user in fabrikam.com, even though both tenants are Entra ID. To let users from one tenant access apps in another, you set up B2B collaboration through Entra External ID - and the visitors come in as guests, not as members.

Core objects

Most of your time in Entra ID is spent with five primitives:

• Users. The individual identities that sign in. Member users belong to your organization; guest users are from another tenant or are personal Microsoft accounts you've invited in.
• Groups. Collections of users (and sometimes other groups) that you assign permissions and licenses to. Security groups for access; Microsoft 365 groups for shared mailboxes and Teams.
• App registrations. One per application or API that authenticates against your tenant. Holds the client ID, the redirect URIs, the secrets and certificates, and the API permissions the app needs.
• Service principals. The runtime identity of an app inside your tenant - the instance that holds the permissions you grant. The app registration is the template; the service principal is what actually shows up in sign-in logs and role assignments.
• Managed identities. Service principals that Azure manages for you, attached to a virtual machine, function app, or container app. No secrets to rotate, no credentials in app settings - Azure injects a token at runtime.

Everything else - Conditional Access policies, roles, license assignments, audit logs - is metadata that hangs off these five primitives. Learn them and the admin center makes sense.

How a sign-in works

The classic case: a user opens your web app in a browser, the app needs to know who they are. Entra ID handles the credentials; your app just sees a token at the end. Step by step:

That is standard OAuth 2.0 + OpenID Connect. Entra ID supports several flow variants for different app shapes - authorization code with PKCE for SPAs and mobile, client credentials for server-to-server, device code for CLIs - but the shape is always: redirect, sign in, get back a token, send the token to APIs.

You almost never write any of this by hand. MSAL (Microsoft Authentication Library) is the official client SDK in every major language, and it handles the redirects, token cache, and refresh logic for you.

Conditional Access

Authentication is "who is signing in." Conditional Access is "on what terms." It is the policy engine that sits between a successful credential check and the token your app receives, and it is where most of the actual security work happens in a modern Entra ID tenant.

A Conditional Access policy reads as a sentence:

If a user in this group signs in to this app from that location on that kind of device - then require MFA, block, or grant.

The signals it can match on:

Conditional Access is where Entra ID earns its keep in a Zero Trust architecture. Every sign-in flows through it, every decision is logged, every policy is testable in report-only mode before it goes live.

Entra ID vs on-prem Active Directory

The single most confusing thing about Entra ID for anyone with a Windows Server background: it is not Active Directory in the cloud. The name is similar, the products solve overlapping problems, and they are designed to work together - but they are different things with different APIs and different protocols.

Hybrid setups - where on-prem AD is synchronized into Entra ID via Entra Connect - are common in larger organizations. Users sign in once and access both on-prem file shares (via AD) and Microsoft 365 (via Entra ID) with the same identity. If your workloads still need Kerberos or LDAP in the cloud, Entra Domain Services is the managed AD-compatible domain Microsoft offers as part of the Entra family.

The short version: Entra ID is the modern identity layer; AD DS is the legacy one; they coexist. Don't try to apply AD mental models (forests, OUs, Group Policy) to Entra ID - the equivalents are different and the names overlap only superficially.

Editions: Free, P1, P2

Entra ID comes in three tiers. The Free tier is included with every Azure or Microsoft 365 subscription, so most organizations are already on it whether they realize it or not. Paid tiers unlock the features most teams eventually need - Conditional Access and Identity Protection in particular.

P1 ships with Microsoft 365 E3 and Business Premium. P2 ships with Microsoft 365 E5. Standalone licenses are available too. The practical advice: if you have ever heard your security team mention "require MFA from outside the office" or "block sign-ins from risky countries," they are describing P1 features. If they talk about "risky sign-ins" or "JIT admin elevation," that is P2.