Microsoft Entra ID (Azure AD)

What is Microsoft Entra ID (formerly Azure AD)?

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service. It handles:

• Authentication and SSO for Microsoft 365, Azure, and thousands of third-party SaaS apps
• Azure RBAC - who can do what on Azure resources
• Machine identities (Managed Identities) for Azure services
• External identities (B2B for partners, B2C for customers)

Tenants and Subscriptions

• Tenant: a dedicated Entra ID instance for an organisation. Created when you sign up for Microsoft services.
• Subscription: a billing and resource container tied to a tenant. One tenant can have multiple subscriptions.
• Management Groups: hierarchical containers for subscriptions. Apply policies and RBAC at scale across many subscriptions.

Tenant: archready.io
  └── Management Group: Production
        └── Subscription: archready-prod
              └── Resource Group: archready-rg
                    └── Resources (VMs, DBs, etc.)

Azure RBAC

Role assignments have three parts: principal + role + scope.

• Principal: user, group, service principal, or managed identity
• Role: collection of permissions (e.g., Contributor, Reader, Storage Blob Data Owner)
• Scope: management group, subscription, resource group, or individual resource

Built-in roles: Owner (full access + manage access), Contributor (full access, no RBAC), Reader (read-only). Use custom roles for least privilege.

RBAC is inherited downward - a role at subscription scope applies to all resource groups and resources within.

Managed Identities

Azure's answer to service accounts / IAM roles - machine identities for Azure services without managing credentials.

• System-assigned: tied to a specific resource. Created and deleted with the resource. One-to-one.
• User-assigned: independent resource, assignable to multiple services. Lifecycle managed separately.

Pattern: App Service / Azure Function / AKS Pod -> Managed Identity -> Storage Blob Data Reader role on a Storage Account -> reads blobs without connection strings or keys in code.

Service Principals

Application identity in Entra ID. When a CI/CD pipeline (GitHub Actions, Azure DevOps) needs to deploy to Azure, it uses a service principal. Authenticate via client secret (avoid) or federated credentials (OIDC - no secrets, equivalent of AWS OIDC for GitHub Actions).

Conditional Access

Policies that control access based on conditions:

• Require MFA for all admin logins
• Block access from outside specific countries
• Require compliant device for access to sensitive apps
• Risk-based: block or step-up authentication when sign-in risk is detected

Conditional Access requires at least Entra ID P1 licence.

B2B and B2C

• B2B (Guest Access): invite partner/vendor users into your tenant as guests. They authenticate with their own identity (Microsoft, Google, SAML IdP). Use for cross-org collaboration.
• B2C (Customer Identity): separate tenant type for consumer-facing apps. Customisable sign-up/sign-in flows, social logins (Google, Facebook), custom branding. Scales to millions of users.

Entra ID vs AWS IAM

	Entra ID	AWS IAM
Primary use	Authentication + Azure RBAC	AWS API authorisation
Human identity	Yes (SSO, MFA, Conditional Access)	Limited (console users)
Machine identity	Managed Identity, Service Principal	IAM Role
External identity	B2B / B2C	IAM Identity Center
RBAC scope	Tenant -> MG -> Sub -> RG -> Resource	Account -> service hierarchy

Interview Angle

Entra ID is central to every Azure architecture. Key points: Managed Identities instead of connection strings (system-assigned for single-resource, user-assigned for shared identity), RBAC at the resource group level for least privilege, Conditional Access for zero-trust security posture. For CI/CD: federated credentials (OIDC) over service principal secrets - no expiring credentials to rotate.

How does this compare to the other clouds?

See the side-by-side comparison: AWS IAM vs Azure Entra ID vs Google Cloud IAM.