Wednesday, May 6, 2026

Microsoft Entra ID (Azure Active Directory) Complete Guide

Microsoft Entra ID (Azure Active Directory) — Complete Guide

Identity Management · Authentication · Conditional Access · PIM · Hybrid Identity · B2B · Zero Trust · Scenarios · Cheat Sheet

Core Concepts — Basics
Identity & Authentication
Access Control & RBAC
Identity Protection & Conditional Access
Hybrid Identity & B2B
Privileged Identity Management (PIM)
Scenario-Based Questions
Cheat Sheet — Quick Reference

1. Core Concepts — Basics

What is Microsoft Entra ID and how does it differ from Active Directory?

Microsoft Entra ID (formerly Azure Active Directory / Azure AD) is Microsoft's cloud-based Identity and Access Management (IAM) service. It is NOT Active Directory moved to the cloud — it is a fundamentally different identity platform.

Active Directory Domain Services (AD DS) — on-premises:
→ Protocol: Kerberos, NTLM, LDAP
→ Structure: forests, domains, OUs, GPOs
→ Objects: computers, printers, users, groups
→ Authentication: Kerberos tickets to domain-joined machines
→ Use: corporate network, on-prem apps, file shares
→ Management: AD Users & Computers, Group Policy

Microsoft Entra ID — cloud:
→ Protocol: OAuth 2.0, OpenID Connect, SAML 2.0
→ Structure: tenant (flat — no OUs, no GPOs, no forests)
→ Objects: users, groups, service principals, managed identities, devices
→ Authentication: JWT access tokens, refresh tokens
→ Use: cloud apps, SaaS (M365, Salesforce), external users
→ Management: Azure Portal, Graph API, PowerShell

Key distinctions:
→ No Kerberos or NTLM in Entra ID
→ No Organisational Units (OUs) — flat directory
→ No Group Policy Objects (GPOs) — use Intune/Conditional Access
→ Manages internet-facing identities, not domain-joined machines

Tip: The most common mistake is confusing Entra ID with AD DS. They coexist — Entra Connect synchronises identities from AD DS to Entra ID for hybrid environments.

What is a Microsoft Entra ID tenant and its key components?

A tenant is a dedicated, isolated instance of Entra ID representing one organisation. Created when signing up for M365 or Azure. Has a unique tenant ID (GUID) and primary domain (contoso.onmicrosoft.com).

Component	Description
Users	Member users (employees) and guest users (B2B externals)
Groups	Security groups, M365 Groups, Distribution groups
App Registrations	Your apps calling Graph/APIs — developer-owned definitions
Enterprise Applications	SaaS apps + service principals (runtime instances)
Service Principals	Identity of an application within a specific tenant
Managed Identities	System or user-assigned identity for Azure resources
Devices	Entra registered, Entra joined, or Hybrid Entra joined

Tip: Tenant ID = the organisation's Entra directory. Application (Client) ID = the app registration. Object ID = unique identifier of any directory object. Know all three.

What are the Entra ID licence tiers?

Entra ID Free (included with Azure/M365):
→ User/group management, SSO for 10 apps per user
→ Basic MFA for admins, self-service password reset (cloud only)
→ Entra Connect sync from AD DS

Entra ID P1 (M365 E3 / EMS E3):
→ All Free features +
→ Full Conditional Access policies
→ Hybrid identity (with password writeback)
→ Identity Protection (sign-in risk detection)
→ Dynamic groups
→ Application Proxy (publish on-prem apps)
→ Self-service password reset with on-prem writeback

Entra ID P2 (M365 E5 / EMS E5):
→ All P1 features +
→ Privileged Identity Management (PIM)
→ Identity Protection (user risk policies)
→ Access Reviews
→ Entitlement Management

Critical licensing facts:
Full Conditional Access  → P1 minimum
PIM                      → P2 required
User risk policies        → P2 required
Access Reviews           → P2 required
Dynamic groups           → P1 required

2. Identity & Authentication

What authentication methods does Entra ID support?

Method	Phishing Resistant	Notes
FIDO2 security keys	Yes	Highest security — YubiKey, hardware tokens
Windows Hello for Business	Yes	Biometric/PIN tied to device TPM — passwordless
Certificate-based auth	Yes	X.509 certificates, smart cards
Microsoft Authenticator (push)	Yes (with number matching)	Most practical MFA method
OATH TOTP tokens	No	Authenticator app TOTP codes
Temporary Access Pass (TAP)	N/A	Time-limited passcode for bootstrapping/recovery
SMS / Voice call OTP	No	Vulnerable to SIM swap — not recommended
Password	No	Weakest — being phased out as primary auth

Tip: Microsoft's recommended path: Password → Authenticator with number matching → FIDO2/Windows Hello → passwordless. Always move away from SMS — SIM swap attacks make it unreliable.

What is SSO in Entra ID and what protocols does it use?

SSO allows users to authenticate once with Entra ID and access multiple applications without re-entering credentials.

SSO protocols:

OpenID Connect (OIDC):
→ Modern, built on OAuth 2.0
→ Returns ID token (JWT) with user claims
→ Best for: modern web/mobile apps, custom apps, M365 integrations

SAML 2.0:
→ XML-based enterprise federation standard
→ Returns SAML assertion with user attributes
→ Best for: enterprise SaaS apps (Salesforce, ServiceNow, SAP, Workday)

Password-based SSO:
→ Entra ID stores/injects credentials into apps
→ For legacy apps with no federation support
→ Requires browser extension

App Proxy SSO (on-prem apps):
→ Publish on-prem web apps through Entra ID App Proxy
→ User authenticates to Entra ID → App Proxy forwards to on-prem
→ Supports: Kerberos Constrained Delegation, header-based

OIDC SSO flow:
1. User accesses app → redirect to login.microsoftonline.com
2. Authenticates (MFA if CA requires it)
3. Entra ID issues ID token + access token
4. Tokens returned to app → user logged in
5. Subsequent apps: silent token reuse (no re-login)

What is the difference between App Registration and Enterprise Application?

App Registration: global definition of your application in the developer's home tenant. Defines: application ID, redirect URIs, API permissions, client secrets/certificates, exposed API scopes.

Enterprise Application (Service Principal): local instance of an application within a specific tenant. Created when an app is consented to. Controls: who can access, SSO settings, provisioning, Conditional Access assignment.

Relationship:
App Registration (global, developer's home tenant)
  → When consented in same tenant: creates Service Principal (Enterprise App)
  → When consented in another tenant: creates Service Principal there too

Multi-tenant app:
App Registration in Tenant A (developer)
  → Service Principal in Tenant A (same tenant use)
  → Service Principal in Tenant B (Tenant B admin consents)
  → Service Principal in Tenant C (Tenant C admin consents)

Gallery SaaS apps (Salesforce, Workday):
→ Enterprise Application (Service Principal) in your tenant
→ No App Registration (owned by the ISV)

Tip: App Registration = APPLICATION definition (developer-owned). Service Principal = APPLICATION INSTANCE in a tenant (runtime identity). One app registration → many service principals across tenants.

What is a Managed Identity?

Managed Identity is an automatically managed Azure identity for Azure resources — no credentials to manage.

Types:
System-assigned: created when enabled on a resource (VM, Function App, Logic App)
                 tied to resource lifecycle — deleted when resource deleted
                 one-to-one with the resource

User-assigned:   standalone Azure resource
                 assigned to multiple Azure resources
                 independent lifecycle
                 use when multiple resources share the same identity

Why prefer Managed Identity over Service Principal + secret:
Service Principal + secret:
→ Secret must be generated, stored, rotated, and kept secure
→ Rotation failure → app breaks
→ Secret can be leaked (committed to Git, exposed in logs)
→ Manual credential management overhead

Managed Identity:
→ No credentials to manage
→ No secret to rotate or leak
→ Azure IMDS issues tokens automatically to the resource
→ RBAC assignments control what the identity can access

Code comparison:
// With client secret (requires management):
var credential = new ClientSecretCredential(tenantId, clientId, secret);

// With managed identity (zero credential management):
var credential = new DefaultAzureCredential();
// Uses managed identity in Azure, developer credentials locally

Tip: Managed Identity is the answer to any "how do you securely authenticate an Azure resource to another Azure service" question. Always recommend over service principal + secret.

3. Access Control & RBAC

What is Azure RBAC and how does it work?

Azure RBAC components:
Security principal: WHO gets access (User, Group, Service Principal, Managed Identity)
Role definition:    WHAT they can do (built-in or custom set of allowed actions)
Scope:              WHERE it applies (Management Group > Subscription > RG > Resource)
Role assignment:    WHO + WHAT + WHERE (combination of above three)

Scope hierarchy (parent roles inherited by children):
Management Group → Subscription → Resource Group → Resource

Key built-in roles:
Owner                    → full access + manage RBAC assignments
Contributor              → full resource management, CANNOT manage RBAC
Reader                   → read-only access to all resources
User Access Administrator → manage RBAC only, no resource access

Role inheritance example:
Subscription: Alice = Reader
  Resource Group A: Alice = Contributor (overrides subscription Reader)
    Resource 1: Alice inherits Contributor from RG A
    Resource 2: Alice inherits Contributor from RG A
  Resource Group B: Alice inherits Reader from Subscription

Tip: Owner = Contributor + ability to assign RBAC roles. Never give Owner to service accounts — use Contributor + specific additional roles only where needed.

What are Entra ID roles vs Azure RBAC roles?

Entra ID roles (directory roles):
→ Control operations on Entra ID directory itself
→ Examples: Global Administrator, User Administrator,
            Conditional Access Administrator, Security Reader,
            Application Administrator, Groups Administrator
→ Assigned via: Entra admin centre or PIM
→ Apply to: tenant-wide directory operations

Azure RBAC roles (resource roles):
→ Control operations on Azure resources
→ Examples: Owner, Contributor, Reader, Key Vault Secrets Officer,
            Storage Blob Data Contributor, Virtual Machine Operator
→ Assigned via: Azure Portal IAM blade, CLI, or Terraform
→ Apply to: management group / subscription / resource group / resource

CRITICAL: These are completely separate permission systems:
Global Admin ≠ Owner:
→ Global Admin can reset any user's password (directory operation)
→ Global Admin has NO Azure resource access by default
→ Azure Owner has NO Entra ID admin access by default

Exception (nuclear option):
Global Admin can ELEVATE themselves to User Access Administrator
on the root management group — gaining access to ALL Azure resources.
Use with extreme caution and audit trail.

What are dynamic groups?

Dynamic groups automatically manage membership based on rules evaluated against user or device attributes.

Dynamic user group rules:
user.department -eq "Finance"
user.jobTitle -contains "Manager"
user.country -eq "UK"
(user.department -eq "Finance") -or (user.department -eq "Accounting")

Dynamic device group rules:
device.deviceOSType -eq "Windows"
device.managementType -eq "MDM"
device.enrollmentProfileName -eq "Corporate"

Use cases:
→ Auto-assign M365 licences: "Sales" dept → Salesforce licence
→ Auto-apply Conditional Access: all contractors → restricted policy
→ Auto-provision SharePoint access by department
→ Auto-assign Intune device policies by OS type

Requirements: Entra ID P1 licence for dynamic user groups
Sync time: membership evaluated within 24 hours of attribute change

Tip: Dynamic groups eliminate manual membership management. When user joins Finance department, they automatically get all Finance group memberships — and all access those groups grant. Leaving removes access automatically.

What are Access Reviews?

Access Reviews (Entra ID P2) provide periodic automated reviews of access rights — ensuring users still need the access they have.

Review Type	What Is Reviewed
Group membership	Do members still need group membership?
Application access	Do users still need access to an enterprise app?
Privileged roles	Do admins still need their admin roles? (PIM integrated)
Guest users	Do external guests still need access to the tenant?

Configuration:
Reviewers:    self / manager / specific users / group owners
Frequency:    one-time / weekly / monthly / quarterly / annually
Duration:     7, 14, or 30 days for reviewers to respond
On no response: auto-approve (lenient) or auto-deny (strict — recommended)
Apply results: automatically remove access when denied

Compliance value:
→ SOC 2 Type II: evidence of periodic access reviews
→ ISO 27001 A.9.2.5: user access reviews requirement
→ GDPR: evidence of regular personal data access review
→ Export review results as compliance audit evidence

4. Identity Protection & Conditional Access

What is Entra ID Identity Protection?

Identity Protection uses ML to detect suspicious sign-in patterns and compromised credentials, generating risk signals used by Conditional Access.

Sign-in risk (per authentication):
→ Anonymous IP address (Tor, VPN proxies)
→ Atypical travel (impossible travel — London then NY within 1 hour)
→ Malware-linked IP address
→ Unfamiliar sign-in properties (new device, location, browser)
→ Password spray attack detected
→ Token issuer anomaly

User risk (accumulates over time):
→ Leaked credentials (found in dark web breach dumps)
→ Azure AD threat intelligence (known attack patterns)
→ Anomalous user activity

Risk levels: Low / Medium / High / None

Conditional Access risk-based policies (P2 required):
Sign-in risk ≥ Medium → require MFA re-authentication
Sign-in risk = High   → block access
User risk = High      → require password change + MFA
User risk = Medium    → require MFA

Self-remediation:
→ User completes MFA → sign-in risk cleared (no admin needed)
→ User changes password → user risk cleared (no admin needed)

What is Conditional Access?

Conditional Access is the Entra ID policy engine evaluating signals and enforcing access decisions — the "if/then" engine of Zero Trust.

# Conditional Access policy structure:
WHEN (Assignments):
  Users:    All users / specific groups / guest users
  Apps:     All cloud apps / specific apps
  Conditions:
    Sign-in risk:    Low / Medium / High (Identity Protection)
    User risk:       Low / Medium / High (Identity Protection)
    Device platform: Windows / iOS / Android / macOS
    Location:        Named locations (trusted IPs / countries)
    Client apps:     Browser / Mobile apps / Legacy auth
    Device state:    Compliant / Hybrid joined / Unregistered

THEN (Grant controls):
  Block access
  OR Allow with:
    Require MFA
    Require device compliance (Intune)
    Require hybrid Entra join
    Require approved client app
    Require app protection policy

Session controls:
  Sign-in frequency:        re-auth every N hours
  Persistent browser:       No (close browser = sign out)
  App-enforced restrictions: browser-only on SharePoint

Key policies to implement:
1. Require MFA for ALL users (exclude break-glass accounts)
2. Block legacy authentication (HIGHEST IMPACT — single policy)
3. Require compliant device for Office 365
4. Browser-only for personal/unmanaged devices
5. Block access from high-risk sign-in locations
6. Risk-based: MFA on medium risk, block on high risk

What are Named Locations and Continuous Access Evaluation?

Named Locations:
→ Define trusted IP ranges (corporate office, VPN) or countries
→ Used in Conditional Access conditions
→ Types: IP ranges (CIDR notation) / Countries/Regions

Use cases:
→ Allow access without MFA from trusted corporate IPs
→ Block access from specific high-risk countries
→ Identity Protection: trusted IP sign-ins get lower risk signal
→ Exclude break-glass accounts: allow access from named trusted IPs

Sign-in frequency:
→ Forces re-authentication after specified period
→ Every 1 hour: high security apps (financial, HR)
→ Every 8 hours: standard business apps
→ Every 24 hours: moderate security apps
→ Never persistent: session ends on browser close (shared computers)

Continuous Access Evaluation (CAE):
→ Near real-time token revocation (not waiting for token expiry)
→ User disabled in Entra ID → token revoked within minutes
→ User location changes → session re-evaluated immediately
→ Supported by: Exchange Online, SharePoint, Teams, Azure services
→ Default token lifetime (1 hour) without CAE can leave compromised
  accounts active for up to 1 hour after disabling

What are break-glass accounts?

Break-glass accounts are emergency access accounts used only when all normal admin access paths fail.

Requirements:
→ Minimum 2 accounts (each a backup for the other)
→ Cloud-only (not synced from AD — immune to on-prem outages)
→ No MFA requirement (accessible even if MFA infrastructure fails)
→ 25+ character random passwords stored physically (safe or split custody)
→ No licences assigned (reduces attack surface)
→ Excluded from ALL Conditional Access policies
→ Monitored: alert on ANY sign-in (Azure Sentinel / Monitor alert)

Configuration:
→ Role: Global Administrator (permanent active, not eligible)
→ CA exclusion: add both accounts to exclusion group in all CA policies
→ Account type: use .onmicrosoft.com UPN (not custom domain — domain
  could become unavailable)
→ MFA: skip MFA requirement (but store in secure physical location)
→ Password: document in physical safe + rotate annually

Critical: If you lock yourself out without break-glass accounts, recovery requires contacting Microsoft Support — which can take hours. Break-glass accounts are mandatory for any production Entra ID tenant.

What is Entra ID Password Protection?

Components:
Global banned password list:
→ Microsoft maintains 100,000+ commonly breached passwords
→ Applied automatically to ALL Entra ID tenants
→ Not configurable — always enforced

Custom banned password list (P1/P2):
→ Admin adds org-specific terms (company name, product names, city)
→ Up to 1,000 custom entries
→ Variations auto-detected: ContosoW1nter2024! → matches "Contoso" + "Winter"

Smart lockout:
→ Locks account after N failed attempts (configurable threshold)
→ Distinguishes attacks from legitimate mistyping
→ Lockout duration increases exponentially
→ Cloud and on-prem lockout counters maintained separately

On-premises Password Protection:
→ Deploy DC Agent on ALL domain controllers
→ Enforces same banned password list for AD DS password changes
→ Extends cloud protection to on-prem AD
→ Critical for hybrid environments — commonly missed control

5. Hybrid Identity & B2B

What is Entra Connect and how does hybrid identity work?

Microsoft Entra Connect (formerly Azure AD Connect) synchronises identities from AD DS to Entra ID.

Authentication methods:

Password Hash Sync (PHS) — RECOMMENDED:
→ Hash of password hash synced to Entra ID
→ Authentication happens IN ENTRA ID (cloud)
→ Works even if on-prem is unavailable
→ Enables leaked credential detection (Identity Protection)
→ Simplest to deploy and maintain

Pass-Through Authentication (PTA):
→ Auth request forwarded to PTA agent on on-prem AD
→ Authentication happens AGAINST ON-PREM AD
→ Password never leaves on-prem
→ Requires on-prem infrastructure available during auth
→ Cannot detect leaked credentials (no password hash in cloud)
→ Use when: policy prohibits any password data in cloud

Federation (AD FS):
→ Full federation with on-prem AD FS or third-party IdP
→ Most complex, most expensive, most maintenance
→ Use when: smart cards, advanced on-prem auth scenarios
→ Microsoft recommends migrating away from AD FS

Writeback features:
Password writeback: password reset in cloud → writes back to AD DS
Group writeback:    M365 Groups written back to AD as distribution lists
Device writeback:   Entra ID device objects written back to AD

What is Entra ID B2B collaboration?

Entra ID B2B enables organisations to invite external users to collaborate using their own credentials — no separate accounts needed.

B2B invitation flow:
1. Admin/user invites: partner@fabrikam.com
2. Guest receives email invitation
3. Guest redeems → consent screen
4. Guest user object created in Contoso's Entra ID
   (userType = "Guest", UPN = partner_fabrikam.com#EXT#@contoso.onmicrosoft.com)
5. Guest accesses resources granted to them

Supported identity providers for guests:
→ Entra ID / Azure AD (partner has M365) → federated sign-in
→ Microsoft personal account
→ Google Workspace → Google federation
→ Email OTP: for users without any supported IdP

Cross-tenant access settings:
Inbound:  control what external tenants can access in YOUR tenant
Outbound: control what YOUR users can access in external tenants
Trust:    trust MFA claims from specific partner tenants
          (avoids double MFA prompt for trusted partners)

B2B vs B2C:
B2B: partner/vendor enterprise users — use their own org identities
     Managed in Entra ID as guest users
     Use case: partner project collaboration

B2C: consumer-facing apps — customers create local accounts or use
     social IdPs (Google, Facebook, Apple)
     Separate Azure AD B2C tenant (NOT your corporate Entra ID)
     Use case: customer-facing applications

What are Entra ID device join options?

Type	Ownership	AD DS Required	Managed By	SSO
Entra ID Registered	Personal (BYOD)	No	Optional Intune	Cloud apps only
Entra ID Joined	Corporate	No	Intune recommended	Cloud + on-prem (with PHS)
Hybrid Entra ID Joined	Corporate	Yes	Intune or GPO	Cloud + on-prem (Kerberos)

Tip: Hybrid Entra ID Joined = migration path for existing AD DS estates. New devices in cloud-first organisations should use Entra ID Joined — no AD DS required.

What is Entitlement Management?

Entitlement Management (P2 / Governance) automates access request, approval, assignment, and review for groups, apps, and SharePoint sites.

Key components:
Access packages: bundle of resources requestable by users
                 (groups + app roles + SharePoint sites)
Policies:        who can request, approval workflow, duration, expiry, reviews
Catalogs:        containers for access packages (HR catalog, IT catalog)
Connected orgs:  allow external B2B users to request access packages

Example: "Finance Analyst" access package
Resources:
  → Finance SharePoint site (Member)
  → Finance M365 Group (Member)
  → SAP Finance role (Viewer)

Policy:
  Requestable by: Finance department employees + approved external auditors
  Approval:       Finance manager approval required
  Duration:       90 days (auto-expires)
  Access review:  quarterly
  External users: allowed (connected organisations)

User journey:
1. User visits myaccess.microsoft.com
2. Requests "Finance Analyst" access package + justification
3. Manager approves/denies (email + Teams notification)
4. On approval: user gets all 3 resource accesses simultaneously
5. After 90 days: access expires automatically
6. Quarterly review: manager recertifies or access revoked

6. Privileged Identity Management (PIM)

What is PIM and how does it work?

PIM provides just-in-time (JIT) privileged access — elevated roles only when needed, for limited time, with approval and audit trail.

Role assignment types:
Eligible:  user CAN activate the role but is not currently active
Active:    role is live — user has elevated permissions now
Permanent: always active (break-glass accounts only)

JIT activation flow:
1. User requests role activation (selects role + duration + justification)
2. Approval notification sent to designated approvers
3. Approver approves/denies (with optional MFA requirement)
4. Role becomes Active for the specified duration
5. After duration: role auto-deactivates
6. Full audit trail: who activated, why, when, duration, approver

Without PIM:
Global Admin permanently assigned → compromised account =
attacker has Global Admin access 24/7

With PIM:
Global Admin eligible → user activates for 2 hours when needed
→ Justification: "Creating new app registration for Project X"
→ Approval: IT Security manager approves
→ 2 hours later: role expires automatically
→ Compromised account: attacker has NO elevated access

PIM activation settings (configurable per role):
Max duration:              1 hour to 24 hours
Require justification:     Yes (always recommended)
Require approval:          Yes for Global Admin, Security Admin
Require MFA on activation: Yes always
Notification:              email to approvers + admin on activation

What roles should be managed in PIM?

High priority for PIM (manage ALL of these):
Global Administrator         → most powerful role in M365
Security Administrator       → manage security policies
Exchange Administrator       → access to all mailboxes
SharePoint Administrator     → access to all SharePoint data
Teams Administrator          → control Teams configuration
Compliance Administrator     → access to compliance data
Billing Administrator        → manage subscriptions and billing
User Administrator           → manage users (can reset passwords)
Privileged Role Administrator → manage PIM itself

Azure RBAC roles (also manage in PIM):
Owner (root management group)     → access to all Azure resources
Contributor (production sub)      → deploy/delete all Azure resources
User Access Administrator (prod)  → manage RBAC assignments

PIM for Azure resources:
→ PIM also works for Azure RBAC roles, not just Entra ID directory roles
→ Configure JIT access for production subscription Owner/Contributor
→ Same activation flow: eligible → activate → justification → approval

7. Scenario-Based Questions

Scenario: Design a Zero Trust identity strategy for a 5,000-person hybrid organisation.

Hybrid identity: Entra Connect with Password Hash Sync + Seamless SSO. Enable password writeback. Hybrid Entra ID Join all existing domain-joined devices.
MFA for everyone: Conditional Access — require MFA for all users, all cloud apps. Use Authenticator with number matching. Enable SSPR with writeback.
Block legacy auth: Conditional Access — block all legacy authentication protocols. Highest-impact single action.
Device compliance: Intune enrolment required. Conditional Access — require compliant device for Office 365. Unmanaged devices: browser-only.
Risk-based policies (P2): Identity Protection — sign-in risk ≥ Medium: require MFA. User risk = High: require password change.
PIM for all admin roles: no standing admin assignments. All admin roles eligible-only. Activation requires justification + approval + MFA.
Named locations: define corporate IP ranges. Consider excluding trusted IPs from MFA requirement (risk tolerance dependent).
Break-glass accounts: two cloud-only Global Admin accounts excluded from ALL CA policies. Azure Sentinel alert on any sign-in.
Access Reviews (P2): quarterly review of admin roles, guest user access, and sensitive group memberships.
Password Protection: deploy DC Agent to all domain controllers. Add company name and product names to custom banned list.

Scenario: A user is locked out and cannot sign in. How do you diagnose?

Check sign-in logs first: Entra ID → Sign-in logs → search for user → check error code:

50076: MFA required but not completed
53003: Conditional Access blocked access
50126: Invalid username or password
50053: Account locked (smart lockout triggered)
50057: Account disabled in Entra ID
70011: Invalid grant / token expired

Check account status: Entra ID → Users → find user → verify "Account enabled" toggle is ON.
Check Conditional Access: if error 53003 → use "What If" tool in CA to simulate the sign-in and identify which policy blocked.
Check MFA registration: user changed phone? MFA methods stale? Issue a Temporary Access Pass (TAP) for re-registration.
Check Identity Protection: user risk = High? → require password reset. Sign-in risk = High? → may be blocked by risk policy.
Resolution options:
- Unlock: dismiss smart lockout from Entra ID portal
- Reset password: admin reset or SSPR
- Issue TAP: Temporary Access Pass for MFA bootstrap/recovery
- Dismiss risk: in Identity Protection if confirmed false positive

Tip: Always check sign-in logs first — exact error codes explain the failure. The CA "What If" tool is invaluable for diagnosing CA-related lockouts without the user retrying.

Scenario: Onboard 500 external partner users for a 6-month project.

Create an Entitlement Management access package containing all project resources — SharePoint project site, Teams team, project M365 group.
Add partner's Entra ID tenant as a connected organisation — enables B2B federation with partners' own credentials.
Self-service request: configure access package as requestable by connected organisation users. Partners visit myaccess.microsoft.com to request.
Approval workflow: project manager approves requests. Auto-deny if no response within 7 days.
Time-limited access: set access package policy to expire in 180 days. No manual cleanup — access revoked automatically at expiry.
Guest Conditional Access: require MFA for all guest sign-ins. Configure cross-tenant trust to accept partner's MFA claims (avoid double-prompt).
Mid-project access review: at 3 months, project manager recertifies which guests still need access. Revoke inactive guests.
Offboarding: access expires automatically at 6 months. Run monthly cleanup of stale guest accounts via Access Reviews.

Scenario: Investigate a suspected account compromise.

Immediate containment: Entra ID → User → Revoke sessions. Invalidates all existing tokens — forces re-authentication. Reset password immediately.
Check Identity Protection: review user risk level and specific detections. Look for leaked credentials, impossible travel, anonymous IP.
Review sign-in logs: look for unusual locations, legacy auth protocol usage, credential stuffing patterns (multiple failures then success), unusual hours.
Review audit logs: look for:
- New app consents granted (attacker adds persistent OAuth app)
- New MFA methods registered (attacker adds their own phone)
- Role assignments changed
- New applications or credentials created
Check OAuth app consents: attacker may have granted a malicious app read access to mailbox/OneDrive. Review enterprise app consents granted by the user. Revoke suspicious consents.
Check mail forwarding rules: compromised accounts often have auto-forwarding rules. Check Exchange Online for forwarding rules created by the user.
Remediate: once password reset and sessions revoked → dismiss user risk in Identity Protection. Monitor for 30 days.

8. Cheat Sheet — Quick Reference

Authentication Methods Priority

Most secure (phishing-resistant):
1. FIDO2 security keys (hardware)
2. Windows Hello for Business (biometric/PIN + TPM)
3. Certificate-based authentication

Strong (recommended for most users):
4. Microsoft Authenticator (push with number matching)
5. OATH TOTP (authenticator apps)

Weak (avoid or phase out):
6. SMS / Voice OTP (SIM swap vulnerable)
7. Password alone (phishing/spray vulnerable)

Emergency:
8. Temporary Access Pass (time-limited, for recovery only)

RBAC Scope Hierarchy

Management Group
  └── Subscription
       └── Resource Group
            └── Resource

Role assignment at parent scope = inherited by all children
More specific (lower scope) assignment overrides parent

Built-in roles:
Owner           = Contributor + assign RBAC
Contributor     = full resource management, NO RBAC assignment
Reader          = read-only to all resources
User Access Admin = manage RBAC only, no resource access

Entra ID Roles vs Azure RBAC

Entra ID roles (directory):          Azure RBAC roles (resources):
→ Global Administrator               → Owner
→ User Administrator                 → Contributor
→ Conditional Access Administrator   → Reader
→ Security Administrator             → Key Vault Secrets Officer
→ Application Administrator          → Storage Blob Data Contributor

These are COMPLETELY SEPARATE systems.
Global Admin ≠ Owner (no implicit Azure resource access)

Conditional Access Policy Templates

Policy 1: Require MFA for all users (most important):
  Users: All  |  Apps: All cloud apps
  Grant: Require MFA
  Exclude: Break-glass accounts

Policy 2: Block legacy authentication (highest impact):
  Users: All  |  Apps: All cloud apps
  Conditions: Client apps = Exchange ActiveSync + Other clients
  Grant: Block access

Policy 3: Require compliant device for Office 365:
  Users: All  |  Apps: Office 365
  Grant: Require device compliance (Intune)

Policy 4: Browser-only for personal devices:
  Users: All  |  Apps: SharePoint / OneDrive
  Conditions: Device state = Unregistered
  Session: App-enforced restrictions (browser only)

Policy 5: Risk-based MFA (P2):
  Sign-in risk ≥ Medium → Require MFA
  Sign-in risk = High   → Block access
  User risk = High      → Require password change

Hybrid Identity Decision

Choose Password Hash Sync (PHS) when:
→ Most organisations — simplest and most resilient
→ Want leaked credential detection (Identity Protection)
→ Want authentication to work if on-prem is unavailable
→ Migrating away from AD FS

Choose Pass-Through Authentication (PTA) when:
→ Policy prohibits any password data (even hashed) in cloud
→ Need real-time on-prem account state enforcement

Choose Federation (AD FS) when:
→ Smart card / certificate authentication required
→ Already heavily invested in AD FS infrastructure
→ Complex claims transformation needed
→ (Consider migrating away from AD FS for simplicity)

PIM Role Management

Priority roles for PIM (all should be eligible, not permanent):
Entra ID roles:
  Global Administrator, Security Administrator, Exchange Administrator,
  SharePoint Administrator, Teams Administrator, Compliance Administrator,
  User Administrator, Privileged Role Administrator

Azure RBAC roles:
  Owner (production subscription), Contributor (production),
  User Access Administrator (production)

Activation settings:
  Max duration: 1-4 hours for most admin roles
  Require justification: always
  Require approval: Global Admin, Security Admin, PRA
  Require MFA: always

Only permanent active:
  Break-glass accounts (2 maximum, excluded from all CA policies)

Top 10 Tips

Entra ID ≠ Active Directory — no Kerberos, no OUs, no GPOs, no forests. Entra ID uses OAuth 2.0/OIDC for cloud apps, AD DS uses Kerberos for domain-joined machines. Know this fundamental distinction.
App Registration ≠ Enterprise Application — App Reg = global app definition. Enterprise App = service principal instance in a tenant. One app registration → many service principals across tenants.
Managed Identity over service principal + secret — no credential management, no rotation risk, no leakage. Always recommend for Azure-to-Azure authentication scenarios.
Block legacy auth = highest single-impact security action — legacy auth (POP, IMAP, SMTP basic auth) cannot support MFA. Primary attack vector for credential stuffing. One Conditional Access policy blocks it all.
PIM = no standing admin access — all admin roles should be eligible-only with JIT activation. Permanent Global Admin = massive blast radius if compromised. Always recommend PIM for any admin role discussion.
Password Hash Sync is recommended over AD FS — PHS is simpler, more resilient (works if on-prem fails), and enables leaked credential detection. AD FS is complex and Microsoft recommends migrating away.
Break-glass accounts are mandatory — two cloud-only Global Admins excluded from ALL CA policies. Azure Sentinel alert on any sign-in. Without them, a CA misconfiguration can lock you out permanently.
Access Reviews for compliance — quarterly reviews of admin roles, guest users, and sensitive groups. Evidence for SOC 2, ISO 27001, and GDPR audits. Auto-deny on non-response is the strict-but-recommended setting.
Entitlement Management for external access at scale — access packages + connected organisations = self-service B2B access with time-limits and auto-expiry. Far better than manually managing guest users.
Continuous Access Evaluation (CAE) closes the token expiry window — without CAE, a disabled user's token remains valid for up to 1 hour. With CAE, revocation is near-instantaneous. Know this for any breach response scenario.

Wednesday, May 6, 2026