Skip to main content

Azure Identity Services Guide

Identity is the foundation of cloud security. In a world where the network perimeter has dissolved, the strongest and most reliable security boundary is the identity of the user or workload trying to access a resource. Azure identity services provide the mechanisms to authenticate those identities, authorize their actions, and govern their entire lifecycle. Getting identity right is not a bolt‑on compliance exercise; it is the architectural decision that shapes every other security control.

Microsoft has evolved its identity platform from Azure Active Directory to Microsoft Entra, reflecting a broader vision that encompasses workforce, customer, and workload identities, along with advanced governance, permissions management, and decentralized identity. This guide explains the core Azure identity services, their architectural roles, and how to combine them into a practical, production‑ready identity architecture.

What Are Azure Identity Services?​

Azure identity services form a layered platform for managing who can access what, under what conditions, and with what level of trust. The portfolio includes:

  • Microsoft Entra ID – The cloud‑native identity provider and directory service for workforce identities, application registration, and single sign‑on.
  • Azure Managed Identities – Automatic workload identities for Azure resources, eliminating the need for embedded credentials.
  • Microsoft Entra External ID – Identity for customers, partners, and external users, replacing the legacy Azure AD B2C and B2B models.
  • Microsoft Entra Domain Services – Managed Active Directory Domain Services for legacy applications that require LDAP, Kerberos, or NTLM.
  • Microsoft Entra Permissions Management – Cloud infrastructure entitlement management (CIEM) that provides visibility and governance across multi‑cloud permissions.
  • Microsoft Entra Verified ID – A decentralized identity service for issuing and verifying credentials based on open standards.
  • Microsoft Entra Internet Access and Private Access – Secure access service edge (SASE) capabilities for Zero Trust networking.
  • Azure Active Directory B2C – The legacy customer identity service; new projects should evaluate External ID first.

Together, these services ensure that every access request—whether from a human, a virtual machine, a container, or an external partner—is explicitly authenticated, authorized, and auditable.

Identity Architecture Overview​

A typical Azure identity architecture orchestrates several flows simultaneously. The following diagram shows the most important relationships.

The flows break down into three fundamental patterns:

  1. Human authentication – A user signs in via Entra ID, optionally strengthening the session with Conditional Access and multi‑factor authentication (MFA).
  2. Workload authentication – An application or service authenticates to another Azure resource using a Managed Identity, removing the need for secrets.
  3. External identity – A partner or customer authenticates through External ID, with separate policies and lifecycle management.

These flows are backed by a common authorization layer (Azure RBAC) and a comprehensive audit trail in Entra ID logs.

Azure Identity Categories​

Microsoft Entra ID​

Microsoft Entra ID is the cloud‑native identity provider and directory service for Azure, Microsoft 365, and thousands of third‑party SaaS applications. It supports modern authentication protocols (OAuth 2.0, OpenID Connect, SAML) and offers:

  • Single sign‑on (SSO) – Users sign in once and access all their assigned applications.
  • Multi‑factor authentication (MFA) – Additional verification beyond a password.
  • Conditional Access – Risk‑based policies that evaluate user, device, location, and application before granting access.
  • Application registration and enterprise applications – The control plane for integrating custom and gallery applications.
  • B2B collaboration – Invite external users as guests in your directory.

Entra ID is the central identity platform for Azure. Every Azure subscription trusts an Entra ID tenant. All role‑based access control (RBAC) assignments, managed identities, and service principals are rooted in this tenant.

Common use cases:

  • Enterprise workforce authentication for Azure portal, Microsoft 365, and line‑of‑business apps.
  • SSO for SaaS platforms like Salesforce, ServiceNow, or GitHub.
  • Conditional Access policies that require MFA for administrators or block legacy authentication.

Azure Managed Identities​

Managed identities solve one of the most persistent security problems in cloud development: how to authenticate an application to another Azure service without embedding credentials in code, configuration files, or CI/CD pipelines.

Azure provides two types:

  • System‑assigned managed identity – Created directly on an Azure resource (e.g., a virtual machine or App Service). It shares the lifecycle of the resource and is automatically deleted when the resource is removed.
  • User‑assigned managed identity – Created as a standalone Azure resource. It can be assigned to multiple resources and has an independent lifecycle.

Both types appear as service principals in Entra ID. Once granted the appropriate RBAC role on a target resource (e.g., Key Vault, Storage, SQL), the application can obtain an access token from the Azure Instance Metadata Service (IMDS) without any secret management.

Key benefits:

  • No credentials to rotate, store, or leak.
  • Tokens are automatically refreshed by Azure.
  • Fine‑grained access via Azure RBAC.

Practical considerations:

  • Always use Managed Identities for service‑to‑service communication within Azure. Reserve service principals with client secrets for external, non‑Azure workloads or hybrid scenarios.
  • When a workload identity needs to cross tenant boundaries, use workload identity federation instead of sharing secrets.

Microsoft Entra External ID​

External ID is the modern, unified service for customer and partner identity. It replaces the legacy Azure AD B2C and extends B2B collaboration with a consistent administrative experience.

Common scenarios:

  • Customer portals – Users sign up with email, social accounts (Google, Facebook), or enterprise identity providers. Entra ID handles the authentication; your application handles authorization and user profile data.
  • Partner collaboration – Invite external partners as guest users with limited directory visibility, while enforcing your Conditional Access policies.
  • SaaS multi‑tenancy – A single application can accept identities from multiple customer Entra ID tenants.

Architectural decision point: Use External ID when you must authenticate users who are not part of your organization and need self‑service registration, branding, and privacy controls. For simple B2B collaboration among a few known partners, Entra ID B2B guest accounts may suffice.

Microsoft Entra Domain Services​

Many legacy enterprise applications still depend on traditional Windows authentication protocols: LDAP for directory queries, Kerberos for ticket‑based authentication, and NTLM for older Windows clients. Azure does not provide a full, customer‑managed Active Directory domain by default.

Microsoft Entra Domain Services fills this gap by providing a managed domain with a subset of Active Directory features. It replicates identity data from Entra ID and creates a pair of domain controllers that you can use for:

  • Domain‑joining virtual machines.
  • LDAP authentication for legacy web applications.
  • Kerberos and NTLM for applications that cannot be modernized.

When to use it:

  • You are migrating a legacy application to Azure and cannot immediately replace LDAP/Kerberos with modern OIDC/SAML.
  • You need Group Policy objects for compliance but do not want to manage domain controllers yourself.

Limitations: It does not provide Schema Admin or Enterprise Admin access. You cannot extend the schema arbitrarily, and it is not a full replacement for on‑premises Active Directory. For lift‑and‑shift migrations that require full Active Directory, consider deploying domain controllers on Azure VMs.

Authentication vs Authorization​

These two terms are often conflated, but they address fundamentally different questions.

AuthenticationAuthorization
Who are you?What are you allowed to do?
Verifies identity (user, workload)Determines permissions on a resource
Protocols: OAuth 2.0, OpenID Connect, SAMLMechanisms: Azure RBAC, ACLs, application logic
Produces a token or sessionEvaluates the token’s claims and the resource’s policy

Azure identity services handle both layers: Entra ID authenticates and issues tokens; Azure RBAC and application‑level authorization evaluate those tokens against permissions. A common mistake is to assume that a user who successfully signs in is automatically authorized to access every resource. Always apply least privilege at both the control plane (Azure RBAC) and data plane (e.g., database permissions).

Authorization​

Azure provides a layered authorization model:

  • Azure RBAC – Controls management plane access (e.g., create a virtual machine, read a storage account key). Roles are built‑in (Owner, Contributor, Reader) or custom. Assignments are scoped to management groups, subscriptions, resource groups, or individual resources.
  • Data plane authorization – Specific to each service. For example, Azure Storage uses its own RBAC roles (Storage Blob Data Contributor) separate from the management plane.
  • Application‑level authorization – Enforced by your code, often using claims from the Entra ID token.

Best practices:

  • Grant only the minimum permissions needed for a task. Use custom roles when built‑in roles are too broad.
  • Regularly review privileged role assignments. Use Microsoft Entra Privileged Identity Management (PIM) to grant just‑in‑time access.
  • Separate management plane permissions from data plane permissions. A developer who deploys an App Service may not need to read the production database.

Identity Security Best Practices​

Securing your identity infrastructure is the single most effective way to reduce your cloud attack surface.

  • Enable MFA for all users, without exception. MFA blocks 99.9% of automated credential attacks.
  • Use Conditional Access to enforce device compliance, location‑based restrictions, and risk‑based challenges.
  • Eliminate passwords where possible. Adopt passwordless methods (Windows Hello, FIDO2 keys, phone sign‑in) and migrate service principals to workload identity federation.
  • Treat Managed Identities as the default for Azure workloads. Never put a service principal secret in a config file.
  • Apply least‑privilege RBAC. Avoid granting Owner to anyone except a small, audited group of cloud administrators. Use built‑in roles and custom roles liberally.
  • Implement identity governance with access reviews, entitlement management, and lifecycle workflows to remove stale accounts.
  • Monitor continuously. Stream Entra ID sign‑in and audit logs to Log Analytics or Sentinel, and alert on impossible travel, suspicious IP addresses, and excessive failed sign‑ins.

A Zero Trust architecture starts with the assumption that no identity, whether inside or outside the network, is inherently trusted. Every access request must be verified explicitly, and every session must be continuously evaluated.

Common Architecture Patterns​

Web Application with Managed Identity​

A typical three‑tier application running on App Service authenticates users via Entra ID. The web app itself uses a system‑assigned Managed Identity to retrieve secrets from Key Vault and access Azure SQL Database. No secrets are stored in the application code or configuration files.

Microservices on AKS​

Each microservice uses a user‑assigned Managed Identity with scoped permissions. The Kubernetes pods authenticate to Azure resources via Microsoft Entra Workload ID, which federates a Kubernetes service account with the Managed Identity. This eliminates the need to pass client secrets to the cluster.

Enterprise Workforce SSO​

Employees sign in to all corporate applications—SaaS and custom—through a central Entra ID tenant. Conditional Access requires MFA for high‑risk sign‑ins and enforces device compliance for access from unmanaged endpoints.

Customer Portal with External ID​

A consumer application uses External ID for self‑service sign‑up and social login. The application validates tokens and enforces its own authorization based on the user’s profile data. Entra ID handles the authentication and token issuance; the application remains the authorization authority.

Hybrid Enterprise with Domain Services​

An on‑premises Active Directory is synchronized with Entra ID via Microsoft Entra Connect (cloud sync). Legacy VMs in Azure are domain‑joined to Microsoft Entra Domain Services, which provides LDAP and Kerberos without requiring you to manage domain controllers. Modern applications use Entra ID directly for authentication.

Monitoring​

Visibility into your identity infrastructure is essential for detecting and responding to threats.

  • Microsoft Entra sign‑in logs – Record every authentication attempt, including location, device, client application, and conditional access evaluation result.
  • Microsoft Entra audit logs – Capture changes to users, groups, application registrations, and role assignments.
  • Azure Monitor and Log Analytics – Ingest Entra ID logs and correlate with resource and application telemetry.
  • Microsoft Sentinel – Provides pre‑built analytics rules for identity‑based attacks, such as password spray, impossible travel, and suspicious service principal activity.

Set up alerts for:

  • Multiple failed sign‑ins from the same IP.
  • Sign‑ins from risky or anonymous IP addresses.
  • Changes to privileged role assignments.
  • Service principal credential creation or modification.

Common Mistakes​

  • Embedding service principal secrets in code or config files. Even if the secret is stored in a “secure” config store, it still needs rotation and lifecycle management. Prefer Managed Identities or Workload Identity Federation.
  • Overusing Global Administrator. The Global Admin role should be reserved for emergency access and very few users. Use more granular roles (e.g., User Administrator, Application Administrator) for daily tasks.
  • Neglecting Conditional Access. MFA alone is not enough; you need policies that evaluate device health, location, and sign‑in risk for each request.
  • Ignoring legacy authentication protocols. Protocols like IMAP, POP, and SMTP do not support MFA. Block them entirely via Conditional Access.
  • Granting permanent Owner or Contributor access to development teams. Developers should operate in non‑production environments with just‑in‑time elevation when required.
  • Sharing service principals across unrelated applications. This creates a single point of compromise. Each application should have its own identity.

Identity services do not exist in a vacuum. Understanding the boundaries between them prevents duplicated effort and security gaps.

ServicePrimary Responsibility
Microsoft Entra IDIdentity provider, directory, authentication, and RBAC
Azure Key VaultSecrets, keys, and certificate management
Microsoft Defender for CloudSecurity posture management and workload protection
Microsoft SentinelSIEM and SOAR; security analytics and incident response
Azure PolicyGovernance and compliance enforcement on resource configuration
Azure RBACCoarse‑grained access control on Azure resources (built into Entra ID)

Entra ID handles the who; Key Vault handles the credentials; Defender for Cloud assesses the environment; Sentinel detects attacks; and Policy enforces the rules. All must work together for a complete security posture.

The following services are deeply integrated with Azure identity and form the backbone of a secure architecture:

  • Azure App Service / Functions / AKS – Workloads that consume Managed Identities and authenticate users.
  • Azure SQL Database / Storage / Cosmos DB – Resources that enforce data plane authorization using Entra ID tokens.
  • Azure Key Vault – Stores secrets and certificates; accessed via Managed Identities.
  • Azure API Management – Validates tokens and enforces policy at the API gateway.
  • Azure Monitor / Log Analytics / Sentinel – Collects and analyzes identity signals.

Best Practices Summary​

  • Use Microsoft Entra ID as the single identity provider for all Azure and SaaS applications.
  • Prefer Managed Identities for any workload running in Azure. For external workloads, use Workload Identity Federation.
  • Enable MFA for every user, without exceptions.
  • Apply Conditional Access to enforce risk‑based authentication, device compliance, and location controls.
  • Follow the principle of least privilege for all RBAC assignments. Use PIM for privileged roles.
  • Eliminate long‑lived credentials. Rotate secrets automatically, and move toward passwordless authentication.
  • Monitor authentication events continuously and set up alerts for anomalous behavior.
  • Regularly review access assignments, stale identities, and application permissions.

Further Reading​