Microsoft Entra ID — The Full Identity Model Explained
Azure Active Directory, now rebranded as Microsoft Entra ID, is the identity and access management platform underpinning every Azure service and Microsoft 365 application. It is not simply a directory — it is a cloud-native identity platform that handles authentication, authorisation, application access, and Zero Trust policy enforcement at enterprise scale. Understanding its core concepts is a prerequisite for any serious Azure architecture work.
Tenants, Users, and Groups
A tenant is your organisation's dedicated instance of Entra ID. Every Azure subscription is associated with exactly one tenant, and every user, group, and application registration lives within a tenant. Tenants are isolated — there is no default trust between tenants. Cross-tenant access policies exist but require explicit configuration.
Users can be members (native to your tenant) or guests (B2B collaboration, invited from external tenants). Groups are the primary mechanism for managing permissions at scale — assign roles and policies to groups rather than individual users wherever possible. Dynamic groups (membership driven by user attribute rules) reduce manual administration overhead significantly in large organisations.
App Registrations and Service Principals
An app registration is a definition of an application in Entra ID — it establishes the application's identity, what permissions it requests, and how it authenticates. Every app registration has a corresponding service principal in each tenant where the application is used. The service principal is the runtime identity of the application.
For Azure resources authenticating to other Azure resources (a VM calling Azure Key Vault, an AKS pod reading from Azure SQL), managed identities are the correct pattern. A managed identity is a service principal whose credentials are managed automatically by Azure — no secrets to rotate, no credentials in application configuration.
Conditional Access
Conditional Access policies are the enforcement engine for Zero Trust in Entra ID. They evaluate signals — user identity, device compliance state, location, risk level — and apply controls: require MFA, block access, require compliant device, require specific network location. Conditional Access sits between authentication and authorisation; a user may authenticate successfully but still be blocked or stepped up by a Conditional Access policy.
- Named locations: Define trusted IP ranges — useful for restricting admin access to corporate network
- Device compliance: Integrates with Intune to require managed, compliant devices for sensitive applications
- Sign-in risk: Entra ID Protection detects anomalous authentication patterns and feeds risk signals to Conditional Access
Privileged Identity Management
PIM provides just-in-time privileged access for Entra roles and Azure resource roles. Users are eligible for privileged roles rather than permanently assigned — they activate the role when needed, for a bounded duration, with optional approval workflow and MFA enforcement. PIM is the correct mechanism for managing Global Administrator, Subscription Owner, and other high-privilege roles in production environments.
Key Takeaways
- Entra ID is the identity platform for all Azure and Microsoft 365 services — understanding it deeply is non-negotiable for Azure architects
- Prefer managed identities over service principal secrets for Azure-to-Azure authentication
- Conditional Access is your Zero Trust enforcement layer — invest time in policy design before going to production
- PIM eliminates standing privileged access — activate on demand rather than permanently assigning high-privilege roles
- Dynamic groups reduce administrative overhead in large tenants — use attribute-based membership rules wherever feasible
