Microsoft Entra ID Overview: Azure's Cloud Identity Platform

What Microsoft Entra ID is

Microsoft Entra ID (formerly known as Azure Active Directory, or Azure AD) is an identity-as-a-service platform. Its primary jobs are:

• Authentication: Verifying that a person or application is who they claim to be, using passwords, multi-factor authentication, certificates, or passwordless methods.
• Authorization: Issuing tokens that tell other services what a verified identity is allowed to do.
• Directory services: Storing user accounts, groups, device registrations, and application registrations in a structured, queryable directory.
• Single sign-on: Allowing a user to authenticate once and then access thousands of applications — from Azure itself to Microsoft 365, Salesforce, GitHub, and custom apps — without logging in again.

Entra ID is not a traditional on-premises Active Directory. It is a cloud-native, REST API-based service. It does not use Kerberos or LDAP by default. If you need to integrate with on-premises AD, Microsoft Entra Connect (formerly Azure AD Connect) provides synchronization between the two.

The name change from Azure AD to Microsoft Entra ID in 2023 reflected Microsoft’s expansion of the Entra product family to include external identity governance and permissions management tools. The core functionality is unchanged.

What a tenant is

A tenant is a dedicated, isolated instance of Microsoft Entra ID. When an organization signs up for any Microsoft cloud service — Azure, Microsoft 365, Dynamics 365 — Microsoft automatically creates an Entra ID tenant for that organization. The tenant has a globally unique identifier (a GUID called the tenant ID) and a domain name like contoso.onmicrosoft.com, though custom domains like contoso.com can be added.

The tenant is the top-level container for all identity objects: every user, group, service principal, managed identity, and application registration belongs to exactly one tenant. Objects in one tenant are not visible to another tenant unless explicit cross-tenant access is configured.

Think of the tenant as the boundary of trust. When someone logs in to Azure, they are authenticating against a specific tenant. The token they receive is issued by that tenant and is only accepted by services that trust that tenant.

The tenant–subscription relationship (the part that confuses beginners most)

This is the concept that trips up nearly every person new to Azure, so it deserves a careful explanation.

A Microsoft Entra ID tenant is about identity. It stores users, groups, and applications.

An Azure subscription is about resources and billing. It is the container for virtual machines, storage accounts, databases, and every other Azure resource. It is also the billing unit — every resource cost is charged to a subscription.

The relationship between them is this:

• Every subscription must trust exactly one Entra ID tenant. That trust relationship means: “When someone tries to access resources in this subscription, check their identity against this tenant.”
• One Entra ID tenant can be trusted by many subscriptions. All those subscriptions can be controlled by users and groups from the same tenant.

This is a one-to-many relationship: one tenant, many subscriptions.

A subscription can change which tenant it trusts (a process called changing the directory), but at any point in time it trusts exactly one tenant.

A concrete multi-team company example

Contoso Ltd has one Entra ID tenant: contoso.onmicrosoft.com. In that tenant, they have created all their employee accounts: engineers, finance, HR, and IT.

They have structured their Azure environment like this:

• Subscription A — Production: Runs the live customer application. Trusted by the Contoso tenant.
• Subscription B — Staging: Pre-production environment. Trusted by the Contoso tenant.
• Subscription C — Development: Where engineers experiment. Trusted by the Contoso tenant.
• Subscription D — Finance systems: Separate subscription for cost isolation and billing. Trusted by the Contoso tenant.

All four subscriptions trust the same tenant. This means:

• An engineer account created once in the Contoso tenant can be granted access to the Development subscription for daily work and read-only access to Production for troubleshooting — no separate accounts needed.
• A managed identity created in Production has its service principal in the Contoso tenant. RBAC assignments in Production can reference that principal.
• When the IT team adds a new employee to the Contoso tenant, that employee can immediately be granted access to any subscription that trusts the tenant, without creating new accounts in each subscription.

If Contoso acquired another company, Fabrikam, that company might have its own Entra ID tenant. Fabrikam’s subscriptions trust Fabrikam’s tenant. To grant a Contoso engineer access to a Fabrikam subscription, you would need to either invite them as a guest (B2B collaboration) or configure cross-tenant access policies.

Key identity objects in a tenant

Users

User accounts represent people. They have a User Principal Name (UPN) like alice@contoso.com, a display name, and optionally group memberships and role assignments. Users can be:

• Member users: Accounts created directly in the tenant (your employees).
• Guest users: External accounts (from other tenants or consumer Microsoft accounts) invited via B2B collaboration. They appear in your tenant directory but authenticate against their home tenant.

Groups

Groups are collections of users, service principals, and other groups. Assigning an RBAC role to a group means every member of that group inherits the role. This is far more manageable than assigning roles to individual users. Groups can be:

• Security groups: Used for access control (RBAC assignments, Conditional Access).
• Microsoft 365 groups: Collaboration groups that also include a shared mailbox, Teams workspace, and SharePoint site.
• Dynamic groups: Membership is computed automatically based on user attributes (for example, all users in the “Engineering” department).

Service principals and managed identities

Non-human identities in the tenant. An application registration creates a service principal. Managed identities are a special type of service principal managed automatically by Azure. These are covered in depth on the managed identities overview page.

Enterprise applications

When a SaaS application (like Salesforce or GitHub) is integrated with your tenant for single sign-on, an enterprise application object is created in your tenant. This is also called a service principal for the external application. It represents the application’s identity within your tenant and controls who can access it.

Application registrations

When developers build custom applications that use Entra ID for authentication, they create an app registration. This gives the application a client ID, allows it to define what permissions it needs, and enables it to receive tokens. App registrations exist in the tenant where the application is registered.

How the tenant fits into the Azure resource hierarchy

The full Azure resource hierarchy from top to bottom is:

1. Microsoft Entra ID tenant — identity boundary
2. Management groups — optional grouping of subscriptions for policy inheritance
3. Subscriptions — billing and resource boundary
4. Resource groups — logical grouping of resources within a subscription
5. Resources — individual Azure services (VMs, storage accounts, etc.)

The tenant is above the resource hierarchy, not part of it. It provides the identity layer that all other levels depend on. Every RBAC assignment at every scope — management group, subscription, resource group, or resource — references a principal (user, group, or service principal) that lives in the trusted tenant.

For more detail on how management groups and subscriptions are organized, see Azure resource hierarchy.

Entra ID roles vs Azure RBAC roles

There are two distinct role systems in Azure, and beginners often conflate them:

Entra ID roles (sometimes called directory roles or admin roles) control what someone can do within the Entra ID tenant itself. For example, the User Administrator role allows managing user accounts. The Global Administrator role has full control of the tenant. These roles are assigned in the Entra ID portal, not in the subscription’s IAM settings.

Azure RBAC roles control what someone can do with Azure resources (VMs, storage, databases). These are assigned at subscription, resource group, or resource scope. The Owner, Contributor, and Reader built-in roles are Azure RBAC roles.

Being a Global Administrator in Entra ID does not automatically give you access to Azure resources. Conversely, being an Owner on a subscription does not let you manage user accounts in the tenant. The two systems are separate. A Global Administrator can, however, elevate themselves to User Access Administrator on the root management group — but this is an explicit, audited action, not automatic.

For detail on the Azure RBAC system, see Azure RBAC.

Exploring your tenant with the CLI

# Show the current tenant and subscription context
az account show --query '{subscriptionId:id, tenantId:tenantId, name:name}' --output json

# List all tenants your account has access to
az account tenant list --output table

# List users in the tenant (requires appropriate permissions)
az ad user list --query '[].{Name:displayName, UPN:userPrincipalName}' --output table

# List groups
az ad group list --query '[].{Name:displayName, ID:id}' --output table

# List enterprise applications (service principals)
az ad sp list --all --query '[].{Name:displayName, AppID:appId}' --output table