█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/DevOps and Infrastructure/Cloud Platforms — Microsoft Azure/Entra ID (Azure AD)
55 minIntermediate

Entra ID (Azure AD)

After this lesson, you will be able to: Use Entra ID (Azure AD) for users, groups, roles, enterprise applications, and conditional access. Understand why Entra appears in interviews even at AWS-heavy shops.

Entra ID is the most important Azure service for cross-cloud careers. This lesson covers it deeply.

Prerequisites:Azure Core Services

What Entra ID actually is

Microsoft's cloud identity service. Identities (users + service principals + managed identities), groups, roles, applications, devices. Used by: every Microsoft 365 customer, most enterprises for SSO into any SaaS, GitHub Enterprise Cloud auth, Microsoft Teams. Free tier: 50K users + basic auth. P1 / P2 add Conditional Access, Identity Protection, Privileged Identity Management. Even an AWS-only company often uses Entra ID for human auth and federates INTO AWS roles.

Users vs service principals vs managed identities

User: a human. Has a username + password + MFA. Service Principal (SP): an identity for an APP. Used by SaaS apps to authenticate to Azure / Microsoft Graph. Has a client ID + client secret OR certificate. Managed Identity (MI): an SP that Azure manages for you (creates, rotates, deletes credentials automatically). Comes in System-Assigned (tied to the resource lifecycle) + User-Assigned (reusable across resources). Modern best practice: Managed Identities everywhere. Never store SP secrets if MI works.

Roles + RBAC + scope

Azure RBAC is built on Entra identities + role assignments. Built-in roles: Owner, Contributor, Reader, plus 200+ resource-specific. Custom roles: define your own (e.g. 'can list VMs but not start/stop'). Scope: assign role at Management Group / Subscription / Resource Group / Individual Resource. Lower scope = least privilege. Same identity, different scope = different permissions per resource. Layer carefully.

💡 Conditional Access (the killer feature)

Conditional Access policies (P1 / P2) let you require MFA, compliant device, specific location, or block sign-in based on signals. Examples: 'require MFA from outside corporate network'; 'block sign-in from countries we don't operate in'; 'require compliant Intune-enrolled device for admin access'. This is what most enterprises buy Entra P1 for. No equivalent in AWS that's as well-integrated.

Create + manage users with az ad

CLI commands you'll use daily.

tsx
# List users
az ad user list --display-name 'Alex' --output table
# Create a user
az ad user create --display-name 'Test User' --user-principal-name testuser@your-tenant.onmicrosoft.com --password 'TempPass123!' --force-change-password-next-sign-in true
# Add to a group
az ad group member add --group 'devops-team' --member-id <user-objectId>
# Assign a role at a resource group scope
az role assignment create \
--assignee [email protected] \
--role 'Contributor' \
--resource-group rg-staging
# List role assignments on a user
az role assignment list --assignee [email protected] --output table

Federation: SSO into AWS, GitHub, Salesforce, etc.

Entra ID supports SAML 2.0 + OIDC. Register the target SaaS as an 'Enterprise Application' in Entra. Configure user provisioning (auto-create accounts when a user is added to a specific Entra group). Result: corporate identity = one source of truth. New hire gets a Entra account; AWS / GitHub / Slack accounts auto-provision; on offboarding, disable in Entra = everything else disables. This is why enterprises use Entra ID even on AWS.

Common mistakes only experienced engineers avoid

Storing SP secrets in code or env vars when Managed Identity works. Granting Owner / Contributor at Subscription scope. Always scope down. Skipping Conditional Access on Global Administrator accounts. The highest-value targets are the easiest to lock down. Static-password service accounts. Replace with MI + key rotation. Not enabling Privileged Identity Management (PIM) for admin roles. PIM = role activation on demand + approval workflow + auto-expiry.

Quick Check

Your App Service needs to read from a Storage Account. What's the modern auth pattern?

Pick the keyless option.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Azure Databases
Back to Cloud Platforms — Microsoft Azure
Azure App Service→