Azure Identity and Access Basics: Users, Service Principals, and Managed Identities

Microsoft Entra ID: the identity foundation

All Azure identities live in Microsoft Entra ID, formerly known as Azure Active Directory. Entra ID is the cloud identity and directory service that backs every Azure authentication request. Whether a person logs into the Azure portal, a GitHub Actions pipeline deploys code, or an Azure Function reads from a storage account — they all authenticate through Entra ID first.

Entra ID stores:

• User accounts and groups
• App registrations and service principals
• Managed identity records
• Directory policies (MFA requirements, conditional access rules, password policies)
• Enterprise application configurations (SSO setups for third-party apps like Salesforce, GitHub, etc.)

Every Azure subscription is associated with one Entra ID tenant. When you grant someone access to a subscription, you’re giving a user object from that tenant’s directory a role on a scope in that subscription.

The three identity types compared

Here is a side-by-side comparison to establish the mental model before going into detail on each:

All three can be assigned RBAC roles. The difference is entirely in how they authenticate and who manages the credentials.

Users

User accounts in Entra ID represent people. They have a username (usually in the form name@yourdomain.com), a password, and optionally MFA configured. Users can log into the Azure portal, use the Azure CLI interactively (az login), and be assigned RBAC roles on any scope.

There are two types of users in Entra ID:

• Member users — accounts created directly in your Entra ID tenant. These are typically your employees.
• Guest users — external accounts from other organizations (like a contractor with their own company’s Microsoft account) who have been invited to your tenant via Azure B2B. They show up in your directory but are authenticated by their home organization.

Managing users with the Azure CLI

# List users in your Entra ID tenant
az ad user list --output table

# Create a new user
az ad user create \
  --display-name "Alex Chen" \
  --user-principal-name "alex@acme.com" \
  --password "TempPass!2026" \
  --force-change-password-next-sign-in true

# Show details about a specific user
az ad user show --id "alex@acme.com"

Service principals

When an application needs to authenticate to Azure, it uses a service principal. A service principal is the identity object that an application uses to sign requests to Azure APIs. It has a client ID, a tenant ID, and either a client secret or a certificate as its credential.

Service principals are the right choice when the workload runs outside Azure — for example, a GitHub Actions runner, a local Terraform execution, or a third-party monitoring tool connecting to your subscription. The downside is that credentials must be created, stored securely, and rotated before they expire.

For a detailed walkthrough including a real GitHub Actions example, see Azure service principals.

Managed identities

Managed identities solve the credential management problem for workloads that run inside Azure. When you enable a managed identity on an Azure resource (like a virtual machine or a Function App), Azure creates a service principal for it in Entra ID and manages all credential rotation automatically. The application code never sees a password or certificate — it just requests a token from the local Azure Instance Metadata Service endpoint, and Azure handles the rest.

There are two kinds of managed identities:

• System-assigned — tied to a specific Azure resource. Created and deleted automatically with the resource. One resource, one identity.
• User-assigned — created as a standalone resource. Can be assigned to multiple Azure resources. Useful when several resources need the same permissions, or when you want the identity to persist independently of the resource lifecycle.

# Enable a system-assigned managed identity on an existing VM
az vm identity assign \
  --name my-vm \
  --resource-group rg-webapp-prod

# Create a user-assigned managed identity
az identity create \
  --name "id-webapp-reader" \
  --resource-group rg-webapp-prod

# Assign the user-assigned identity to a VM
az vm identity assign \
  --name my-vm \
  --resource-group rg-webapp-prod \
  --identities "/subscriptions/{sub-id}/resourceGroups/rg-webapp-prod/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-webapp-reader"

For the full picture on managed identities, including system-assigned vs user-assigned trade-offs, see managed identities overview.

How RBAC connects identities to resources

Having an identity in Entra ID does not automatically grant any access to Azure resources. Access is granted through RBAC role assignments. A role assignment has three parts:

1. Who — the identity being granted access (user, group, service principal, or managed identity)
2. What — the role that defines what operations are allowed (Reader, Contributor, Owner, or a custom role)
3. Where — the scope at which the role applies (management group, subscription, resource group, or individual resource)

Role assignments are inherited: a role assigned at the subscription level applies to all resource groups and resources inside it. See Azure RBAC for the full list of built-in roles and how to create custom ones.

# Grant a user the Reader role on a resource group
az role assignment create \
  --assignee "alex@acme.com" \
  --role "Reader" \
  --scope "/subscriptions/{sub-id}/resourceGroups/rg-webapp-prod"

# Grant a managed identity Contributor access to a storage account
az role assignment create \
  --assignee "{managed-identity-principal-id}" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/{sub-id}/resourceGroups/rg-webapp-prod/providers/Microsoft.Storage/storageAccounts/acmestorage"

# List all role assignments on a resource group
az role assignment list \
  --scope "/subscriptions/{sub-id}/resourceGroups/rg-webapp-prod" \
  --output table

A real failure: using a personal account for automation

This scenario happens more often than it should. A developer sets up a deployment pipeline and, wanting something quick, configures the pipeline to use their own user account credentials. It works — for a while.

Then one of the following happens:

• The developer enables MFA, which now blocks the non-interactive authentication the pipeline uses
• The developer changes their password (or IT forces a password rotation), breaking all pipelines that used the old credentials
• The developer leaves the company; their account is disabled; every pipeline that used their credentials fails simultaneously
• The developer is a contractor and their guest access expires after 90 days, taking all pipelines down on a Sunday night

The correct approach in each of these cases is to use a dedicated service principal (for workloads outside Azure) or a managed identity (for workloads inside Azure). The pipeline’s identity is decoupled from any individual person, so it doesn’t break when people change passwords or leave the organization.

Using groups to manage access at scale

Granting roles to individual users or service principals directly becomes unmanageable at scale. The better pattern is to assign roles to Entra ID security groups and then add identities to the groups. When a new engineer joins, adding them to the “engineers” group automatically grants them all the access that group has.

# Create a security group
az ad group create \
  --display-name "engineers-team" \
  --mail-nickname "engineers-team"

# Add a user to the group
az ad group member add \
  --group "engineers-team" \
  --member-id "user-object-id"

# Assign a role to the group (all group members inherit this role)
az role assignment create \
  --assignee "group-object-id" \
  --role "Contributor" \
  --scope "/subscriptions/{sub-id}/resourceGroups/rg-dev"

Groups also work for service principals — you can add a service principal to a group and grant the role to the group rather than the individual service principal. This is useful when multiple pipelines or applications need the same access.