Entra ID crash course

The hierarchy, top to bottom

Why Global Admin and Privileged Role Admin should never be standing

• Blast radius — one compromised credential means full tenant control, no extra step.
• No audit correlation — a permanent account generates no "this person elevated for a reason" event.
• NIST 800-53 AC-6 and CIS Control 5 both explicitly expect time-bound privileged access, not standing admin accounts.
• Microsoft's own guidance: 2–4 emergency break-glass accounts outside PIM, monitored closely; everyone else via PIM eligible assignment.

Administrative Units (AUs)

A container (business unit, region, subsidiary) that a role assignment can be scoped to — the direct cloud equivalent of delegating an OU in on-prem AD. A User Administrator scoped to an AU can only manage users inside that AU, not tenant-wide.

Custom roles

Built-in roles are fixed permission bundles. A custom role lets you define an exact permission set when no built-in role fits cleanly — worth mentioning if asked how you'd handle least-privilege for a role with no clean built-in match.

Hands-on — assigning a role via Graph API

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"

New-MgRoleManagementDirectoryRoleAssignment `
  -PrincipalId "user-object-id" `
  -RoleDefinitionId "role-template-id" `
  -DirectoryScopeId "/"

Same Connect-MgGraph pattern you already use for lifecycle scripts — just a different cmdlet family (RoleManagement instead of Users/Groups).

Eligible vs active

• Eligible — approved to hold a role, zero standing access. Dormant until activated.
• Active — currently usable, either activated from eligible, or (discouraged) permanently assigned.

Eligible is the default posture for anything above routine operational access. This is the single biggest lever for passing a NIST/CIS access review.

The activation workflow

1. User requests activation
2. MFA challenge
3. Business justification typed in
4. (Optional) routed to a designated approver
5. Role becomes active for a defined window (commonly 1–8 hours)
6. Auto-expires
7. Every step logged — who, when, why, for how long, approved by whom

Access reviews

Periodic (often quarterly) recertification of who holds eligible/active roles, run by a designated reviewer, to catch stale or over-provisioned access. This turns PIM from a one-time control into a continuously-audited one — "we set up PIM with recurring access reviews" is a stronger story than "we set up PIM once."

Hands-on — creating a PIM-eligible assignment via Graph

New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest `
  -Action "AdminAssign" `
  -PrincipalId "user-object-id" `
  -RoleDefinitionId "role-template-id" `
  -DirectoryScopeId "/" `
  -ScheduleInfo @{
    StartDateTime = (Get-Date)
    Expiration = @{ Type = "AfterDuration"; Duration = "P90D" }
  }

This script grants eligibility, not access. The user still self-activates through MFA when they need the role.

The SAML handshake (SP-initiated)

1. User requests the app (Service Provider)
2. App redirects browser to Entra (Identity Provider) with a SAML request
3. Browser follows redirect to Entra
4. Entra authenticates the user, checks MFA/Conditional Access
5. Entra returns a signed SAML assertion to the browser
6. Browser posts the assertion to the app
7. App validates the signature (trusts Entra's pre-configured certificate)
8. Session granted

SP-initiated vs IdP-initiated

SP-initiated — flow starts at the app (above). IdP-initiated — flow starts from the Entra "My Apps" portal; the user clicks the app tile and Entra sends the assertion directly without the app requesting it first.

SCIM — the provisioning half

SCIM (System for Cross-domain Identity Management) creates, updates, and deactivates user accounts inside the target app automatically — configured on the same enterprise app's "Provisioning" tab, separate from SSO.

Direct tie to your experience: SailPoint automates this same lifecycle on-prem and across connected apps via its own connectors. SCIM is Microsoft's native version, built into Entra enterprise app registrations for apps that support the standard.

Troubleshooting a SAML failure — what to check first

Browser dev tools → Network tab → find the POST to the app's ACS URL. Check:

<saml:Attribute Name="emailaddress">
  <saml:AttributeValue>user@company.com</saml:AttributeValue>
</saml:Attribute>

Issuer: https://sts.windows.net/{tenant-id}/
Audience: https://app.vendor.com/saml/metadata
NotOnOrAfter: 2026-07-25T14:32:00Z

Most real-world failures are one of: attribute mapping mismatch (app expects a claim Entra isn't sending), audience/entity ID mismatch, or an expired/rotated signing certificate.

The three flavors

Migrating a legacy service account to a managed identity

1. Inventory: what does the legacy account authenticate to, and how (connection strings, scheduled tasks, configs)?
2. Create a system-assigned or user-assigned managed identity on the Azure resource running the workload.
3. Grant that identity a scoped role — e.g., Key Vault Secrets User, not Owner.
4. Update app code/config to use DefaultAzureCredential instead of a stored password.
5. Disable, then delete, the legacy account after confirming nothing breaks.

The detail interviewers listen for: step 3. Least-privilege has to apply to non-human identities too — granting a managed identity Owner "for convenience" recreates the exact standing-privilege problem PIM solves for humans.

M365 admin center is the umbrella console (users, groups, billing, reporting) sitting on top of Entra ID for identity and Exchange admin center for mail.

Ten Exchange concepts worth knowing cold

1. Mailbox types — user, shared (no license/password, permission-based access), resource (room/equipment)
2. Mailbox permissions — Full Access, Send As, Send on Behalf — granted/revoked as part of onboarding/offboarding
3. Mail flow (transport) rules — if/then logic on messages in transit; where phishing/BEC controls often live
4. Group types — distribution group (mail-only) vs mail-enabled security group vs Microsoft 365 group (unified, ties into Entra group-based licensing)
5. Exchange Online RBAC — its own role-group system (Organization Management, Recipient Management, Help Desk); architecturally separate from Entra roles even though Global Admin often has de facto control
6. Litigation hold / retention — preserves mailbox content on offboarding; place a hold before deprovisioning, don't delete outright
7. Delegation vs impersonation — a person acting on a mailbox (delegation) vs an app/service account acting as a user (impersonation, much higher risk — ties to Block 4)
8. Modern auth vs legacy auth — legacy (basic auth) bypasses MFA/Conditional Access entirely; blocking it tenant-wide is standard hardening
9. Mailbox auditing — logs who accessed a mailbox and what they did; same audit logic as PIM logs, different data source
10. Connectors — inbound/outbound mail flow to/from specific domains or on-prem Exchange in hybrid setups

Honest framing for this section

The Enterprise Access Model

• Tier 0 — identity, domain controllers
• Tier 1 — servers, applications
• Tier 2 — workstations, end users

A concrete naming framework

Tier 0 (identity/DC-equivalent):   adm-t0-{name}
Tier 1 (servers/apps):             adm-t1-{name}
Tier 2 (workstations/end user):    adm-t2-{name}
Service accounts:                  svc-{app}-{purpose}
PIM-eligible groups:               pim-elig-{role}-{scope}
SSO-enabled app groups:            app-{vendorname}-{accesslevel}

Rolling this out without breaking things

Parallel-run, never big-bang: build the new structure alongside the old, migrate group by group starting with the highest-risk tier (Tier 0 / service accounts), validate access after each migration, deprecate old names last.

Answer these out loud, end to end, no notes.