Entra ID (Azure AD) — Identity Management That Actually Makes Sense

A developer hardcodes a storage account key in a GitHub repo. Twelve minutes later, a bot scrapes it and racks up $14,000 in crypto mining charges. This is not a hypothetical — it happens every week. Microsoft Entra ID exists to make sure your applications authenticate without secrets lying around in code.

What Is Microsoft Entra ID?

Microsoft Entra ID (formerly Azure Active Directory, still called Azure AD in many tools) is Microsoft's cloud-based identity and access management service. It is the backbone that answers two questions for every request:

1. Authentication — Who are you? (Prove it.)
2. Authorization — What are you allowed to do?

Every Azure subscription is associated with exactly one Entra ID tenant. That tenant is your identity boundary — the directory that holds your users, groups, and application registrations.

Tenants and Directories

Think of a tenant as your organization's identity namespace. When you sign up for Azure, a tenant is created automatically with a default domain like yourcompany.onmicrosoft.com.

# Show your current tenant details
az account show --query tenantId --output tsv

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

# List subscriptions and their associated tenants
az account list \
  --query "[].{Name:name, SubscriptionId:id, TenantId:tenantId, State:state}" \
  --output table

Managing Users and Groups

Creating and Managing Users

# Create a new user in your directory
az ad user create \
  --display-name "Priya Sharma" \
  --user-principal-name priya@yourcompany.onmicrosoft.com \
  --password "TempP@ss123!" \
  --force-change-password-next-sign-in true

# List all users
az ad user list \
  --query "[].{Name:displayName, UPN:userPrincipalName, ObjectId:id}" \
  --output table

# Delete a user
az ad user delete --id priya@yourcompany.onmicrosoft.com

Creating Groups

Groups are how you manage permissions at scale. Assigning roles to individual users does not survive past 10 employees.

# Create a security group
az ad group create \
  --display-name "Platform Engineering" \
  --mail-nickname platform-engineering

# Add a user to the group
az ad group member add \
  --group "Platform Engineering" \
  --member-id <user-object-id>

# List group members
az ad group member list \
  --group "Platform Engineering" \
  --query "[].{Name:displayName, UPN:userPrincipalName}" \
  --output table

App Registrations and Service Principals

When an application needs to access Azure resources, it needs an identity. This is a two-step process:

1. App Registration — the application's identity definition (like a blueprint)
2. Service Principal — the actual identity instance in your tenant (like a running instance of that blueprint)

# Register an application
az ad app create \
  --display-name "deploy-pipeline" \
  --sign-in-audience AzureADMyOrg

# Create a service principal for the app
APP_ID=$(az ad app list --display-name "deploy-pipeline" --query "[0].appId" --output tsv)
az ad sp create --id $APP_ID

# Assign a role to the service principal
az role assignment create \
  --assignee $APP_ID \
  --role "Contributor" \
  --scope /subscriptions/<subscription-id>/resourceGroups/rg-prod-webapp-eastus

The problem: Service principals still require credentials (secrets or certificates) that you need to rotate and protect. This brings us to the better approach.

Managed Identities — The Zero-Secret Solution

Managed identities are Azure's answer to "how do I authenticate without managing credentials?" Azure creates and rotates the credentials automatically. You never see a password or certificate.

There are two types:

Type	Created With	Lifecycle	Use Case
System-assigned	The resource itself	Tied to the resource (deleted with it)	Single-purpose: VM accesses Key Vault
User-assigned	You create it independently	Independent of resources	Shared across multiple VMs or apps

System-Assigned Managed Identity

# Enable system-assigned managed identity on a VM
az vm identity assign \
  --resource-group rg-prod-webapp-eastus \
  --name vm-prod-web-001

# Get the principal ID
PRINCIPAL_ID=$(az vm show \
  --resource-group rg-prod-webapp-eastus \
  --name vm-prod-web-001 \
  --query identity.principalId \
  --output tsv)

# Grant it access to a storage account
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-prod-webapp-eastus/providers/Microsoft.Storage/storageAccounts/stprodappeastus2025

User-Assigned Managed Identity

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

# Assign it to a VM
az vm identity assign \
  --resource-group rg-prod-webapp-eastus \
  --name vm-prod-web-001 \
  --identities id-app-reader

# Grant it a role
IDENTITY_PRINCIPAL=$(az identity show \
  --name id-app-reader \
  --resource-group rg-prod-webapp-eastus \
  --query principalId --output tsv)

az role assignment create \
  --assignee $IDENTITY_PRINCIPAL \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-prod-webapp-eastus/providers/Microsoft.KeyVault/vaults/kv-prod-eastus

Rule of thumb: If one resource needs one identity, use system-assigned. If multiple resources share the same permissions, use user-assigned.

Conditional Access Policies

Conditional access is the "if-then" engine of Entra ID. It evaluates signals (who, where, what device, what app) and enforces decisions (allow, block, require MFA).

Common policies:

• Require MFA for all users accessing Azure portal
• Block sign-ins from countries where your company has no employees
• Require compliant devices for accessing sensitive applications
• Force password change when sign-in risk is detected

Conditional access policies are configured in the Azure portal or via Microsoft Graph API — there is no direct Azure CLI support. However, you can query their state:

# List conditional access policies via Microsoft Graph
az rest \
  --method GET \
  --url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  --query "value[].{Name:displayName, State:state}" \
  --output table

MFA Enforcement

Multi-Factor Authentication should be non-negotiable for every organization. Entra ID supports multiple MFA methods:

• Microsoft Authenticator app (push notifications)
• FIDO2 security keys (hardware tokens)
• SMS verification (least secure, but better than nothing)
• Phone call verification

The modern approach is to enforce MFA through conditional access policies rather than per-user MFA settings. This gives you granular control — require MFA for admin roles but allow passwordless for regular users on compliant devices.

B2B and B2C Scenarios

B2B (Business-to-Business): Invite external users (contractors, partners) into your tenant as guest users. They authenticate with their own organization's credentials.

# Invite an external user
az ad user invite \
  --invited-user-email-address contractor@partnercompany.com \
  --invite-redirect-url https://portal.azure.com \
  --invited-user-display-name "External Contractor"

B2C (Business-to-Consumer): A separate Entra ID service for customer-facing apps. Supports social logins (Google, Facebook, Apple), custom sign-up flows, and branded login pages. B2C is a different tenant type entirely — you create it specifically for consumer identity scenarios.

SSO Integration

Single Sign-On lets your users authenticate once and access multiple applications. Entra ID supports several SSO protocols:

• SAML 2.0 — enterprise standard, supported by thousands of SaaS apps
• OpenID Connect / OAuth 2.0 — modern web and mobile apps
• Password-based SSO — for legacy apps that only support form-based login

The Azure AD App Gallery has pre-built integrations for over 3,000 applications including Salesforce, Slack, AWS, and GitHub.

Wrapping Up

Identity is the new security perimeter. Forget about firewalls — if an attacker has valid credentials, they walk right through. Use managed identities to eliminate secrets from your code, enforce MFA through conditional access, and assign roles to groups instead of individuals. Your future self will thank you when the next audit comes around.

---

Next up: Azure CLI vs PowerShell — a side-by-side comparison to help you pick the right tool for managing Azure resources.