Identity, Access & Privileged Access

Identity, Access & Privileged Access — Full Guide

Unit 1 of 7. The comprehensive full-coverage note for Identity, Access & Privileged Access (Entra, RBAC, PIM, Conditional Access). Companion notes: quick recall in the cheat-sheet section · the highest-yield concepts in the High-ROI entry · date-sensitive facts, glossary, and the deprecation timeline in 99-Appendix. Prerequisites: none. Identity is the front-loaded Zero Trust control plane and the universal prerequisite for every later unit — see the sequencing rationale in 00-Strategy-and-Map.

Identity is the Zero Trust control plane and the prerequisite for every later unit. This unit owns the identity primitives end to end. Where identity is merely a consumer or signal source, the relevant unit is referenced rather than re-taught: Key Vault (the Data, Storage & Key Management unit teaches the vault; here we wire a managed identity to it), Entra Internet/Private Access SSE (the Secure Networking unit), Defender for Identity AD attack detection and Identity Protection risk engine internals (the Security Operations unit), Intune device compliance (the Secure Compute & Endpoint unit), and Azure Policy governance (the Posture & Governance unit).

1. Microsoft Entra ID as the identity foundation (hybrid + multicloud)

Entra ID is the cloud IdP providing SSO, the directory of users/groups/apps, and the issuer of tokens. SC-100 asks you to design a solution for Entra ID including hybrid and multicloud; AZ-500 assumes the tenant exists and you operate within it.

Hybrid identity sync

On-prem AD DS is synchronized into Entra via Microsoft Entra Connect Sync (server-based, the traditional full-featured engine) or Entra Cloud Sync (lightweight agent, multi-forest, Microsoft-managed). Three authentication methods, in increasing order of cloud trust:

• Password Hash Synchronization (PHS) — a hash of the on-prem password hash syncs to the cloud and Entra authenticates locally. Simplest and most resilient (survives an on-prem outage), and it enables leaked-credential detection. This is the default recommendation.
• Pass-Through Authentication (PTA) — credential validation happens on-prem via lightweight agents; no password material lands in the cloud, but you carry an on-prem dependency for every sign-in.
• Federation (AD FS) — an external Security Token Service; the most complex option with the largest attack surface. Microsoft actively steers customers away from AD FS toward cloud authentication — the AD FS-to-Entra migration is an SC-100-relevant modernization play.

Multicloud

Entra federates to AWS/GCP for human SSO, and workload identity federation (§6) handles non-human identities across clouds. SC-100 frames Entra as the single control plane spanning SaaS / PaaS / IaaS / on-prem / multicloud.

2. Azure RBAC vs Microsoft Entra roles — two separate authorization systems

This distinction is the single most heavily tested identity concept and the most common distractor source on both exams. They are separate systems with separate stores.

Azure RBAC mechanics

A role assignment binds three things: a security principal (user, group, service principal, or managed identity) + a role definition + a scope. Scope has four nested levels — management group → subscription → resource group → resource — and permissions inherit downward, so a role granted at subscription scope applies to every RG and resource beneath it. Least privilege means assigning at the narrowest scope that works.

A role definition lists Actions and NotActions (control plane — managing the resource) and DataActions / NotDataActions (data plane — e.g. reading a blob’s contents vs managing the storage account). Critically:

Built-in roles to know cold

• Owner — full access plus the right to grant access (manage role assignments).
• Contributor — full access to manage resources, except it cannot grant access (no role assignments).
• Reader — view only.
• User Access Administrator — manage access only (role assignments), no resource operations.
• Role Based Access Control Administrator — assign roles but constrained: it can be scoped so a delegate may hand out only specific roles. This is the least-privilege delegation role, unlike Owner which can grant anything.

Microsoft Entra roles

These authorize operations on directory objects — managing users, groups, app registrations, Conditional Access, etc. Examples: Global Administrator, Privileged Role Administrator (manages role assignments and PIM), User Administrator, Application Administrator, Security Administrator. They are tenant-wide by default; some can be scoped to an administrative unit (AU) or to specific app objects. Custom Entra roles are built from Entra role permissions and require Entra ID P1.

Custom Azure roles (AZ-500: “manage custom roles”)

Start from a built-in role and edit the JSON. Hard limits and edge cases to memorize:

• 5,000 custom roles per tenant (2,000 for Azure operated by 21Vianet).
• Only one wildcard per action string.
• AssignableScopes cannot be root (/) and cannot contain wildcards.
• Only one management group may appear in AssignableScopes.
• A role containing DataActions cannot be assigned at management-group scope (it can still be defined with a mgmt group in scope, but assigned only at subscription scope or lower).

A common real-world driver is the role-assignment limit per scope: collapsing several built-in roles held by one principal into a single custom role frees assignment slots.

3. Privileged Identity Management (PIM)

PIM delivers just-in-time, time-bound, audited privilege, and is the engineering answer to “minimize standing admin rights.” It requires Entra ID P2 or Entra ID Governance, licensed per user who holds an eligible/time-bound assignment, who can approve or reject activation requests, or who is assigned to or performs access reviews.

Assignment model — eligible vs active

Every assignment is eligible (the user must perform an action — activation — before the privileges apply) or active (privileges apply immediately). Combined with optional start/end dates this yields four shapes:

1. Permanent eligible
2. Permanent active
3. Time-bound eligible
4. Time-bound active

Activation (role) settings — configured per role

• Maximum activation duration.
• Require MFA on activation. (Nuance: MFA can be enforced on eligible activation; for an active assignment PIM can require MFA only at assignment time, since the user is already active.)
• Require justification and/or ticket information.
• Require approval — approvers need no role themselves; Microsoft recommends ≥2 approvers.
• Require a Conditional Access authentication context — ties activation to a CA policy (e.g. phishing-resistant MFA + compliant device).

Scope of PIM

PIM manages Microsoft Entra roles, Azure resource roles (integrated directly into the resource’s Access control (IAM) blade), and PIM for Groups — making membership/ownership of a group eligible, which indirectly gates any access the group confers (roles, app assignments, SaaS access).

Break-glass

Keep two cloud-only emergency Global Administrator accounts, permanently active, not assigned to specific individuals, excluded from Conditional Access and PIM, with credentials split and stored offline. License expiry of P2 removes eligible assignments and ends access reviews but leaves permanent assignments intact — another reason break-glass is permanent-active.

4. MFA and Conditional Access

MFA — three delivery models (knowing which to recommend is tested)

• Conditional Access-based MFA — the modern, granular approach (require MFA only under risky conditions). Needs Entra ID P1. Preferred.
• Per-user MFA — legacy, applies to all sessions with no conditionality. Avoid for new designs.
• Security defaults — free, all-or-nothing baseline (MFA for admins and all users, blocks legacy auth). For tenants without P1; mutually exclusive with CA policies.

Conditional Access — the Zero Trust policy engine

CA is Microsoft’s Zero Trust policy engine: simple if-then statements evaluated after first-factor authentication (so it is not a frontline defense against, e.g., DoS — the password check already happened). A policy = assignments (who/what) → access controls (grant or block).

Signals / conditions: user / group / role (and, in preview, agent identity), IP / named location, device (compliant via Intune, Microsoft Entra hybrid joined, or a device filter to target e.g. PAWs), client app, sign-in / user risk from Entra ID Protection, and Defender for Cloud Apps session signals.

Grant controls: block; or require one/more of — MFA, authentication strength (named methods, e.g. phishing-resistant MFA = FIDO2 / Windows Hello / certificate), compliant device, hybrid-joined device, approved client app, app protection policy, password change, terms of use.

Session controls: sign-in frequency, persistent browser, app-enforced restrictions, Defender for Cloud Apps conditional access app control, and continuous access evaluation.

Continuous Access Evaluation (CAE)

CAE solves the access-token latency problem. Standard access tokens live 60–90 minutes, so a disabled user keeps access until expiry. CAE has Entra push critical events to CAE-capable resource APIs (Exchange Online, SharePoint, Microsoft Graph, Teams) in near-real-time:

• Account disabled or deleted
• Password changed or reset
• MFA enabled
• Admin token revocation (admin explicitly revokes all refresh tokens)
• Entra ID Protection elevated (high) user risk
• (CAE-enabled resources can also enforce location-based CA-policy changes mid-session)

Critical-event evaluation needs no Conditional Access policy and works in any tenant; CA-policy evaluation (e.g. location) is the part that re-checks your policies. Note SharePoint Online does not honor user-risk events — a tested exception.

As a resilience benefit, with CAE the resource-API token lifetime can increase by up to 28 hours (proactively refreshed by MSAL) instead of 60–90 minutes — longer-lived yet revocable in near-real-time, so you gain both security and resiliency.

Protected actions

Protected actions add a CA authentication-context requirement to the highest-impact Entra operations themselves — e.g. modifying or deleting Conditional Access policies or editing cross-tenant access settings. This stops a compromised admin token from dismantling the very controls protecting the tenant. (It defends the defenses.)

Risk scoring (SC-100 modern auth strategy)

Entra ID Protection computes sign-in risk (this authentication) and user risk (account likely compromised). CA risk-based policies then force MFA on medium-risk sign-ins and a secure password change on high user risk. The detection internals belong to the Defender / Identity-Protection unit (Security Operations); here you consume the risk signal in CA.

5. App registrations, service principals, and managed identities

Four objects, frequently conflated. Keep them distinct.

• Application object (app registration) — the global definition of an application, created in its home tenant. It declares redirect URIs, exposed scopes (delegated permissions) and app roles (application permissions), requested API permissions, the Application ID URI (default api://{clientId}), and credentials (client secrets / certificates / federated credentials). One application object exists regardless of how many tenants use the app.
• Service principal — the local instance of an application within a tenant; the concrete identity that receives role assignments, consent grants, and sign-in policies. A multi-tenant app has one app object (home tenant) and a service principal in every tenant that consents. The portal’s Enterprise applications blade is the service-principal view; App registrations is the application-object view. (Managed-identity SPs and legacy/third-party SPs also exist.)
• Managed identity — a service principal whose credential lifecycle Azure fully manages (no secret in code):
  • System-assigned — created on a single Azure resource, shares its lifecycle, deleted with it. Use for 1:1, self-contained workloads.
  • User-assigned — an independent Azure resource attachable to many resources, surviving any one of them. Use for shared identity, pre-provisioning, or to avoid re-granting permissions on redeploy.

Code obtains tokens from the Instance Metadata Service (IMDS) endpoint; DefaultAzureCredential in the Azure SDKs picks it up transparently — no secret on disk.

Operating them (AZ-500): create app registrations; configure exposed scopes and app roles; manage permission consent; create/assign managed identities; manage and use service principals (including credential rotation for app registrations — which managed identities make unnecessary). Hardening: prefer managed identity over app-registration secrets; if secrets are unavoidable prefer certificates or federated credentials; audit credential expiry and over-privileged app permissions.

6. Workload identity federation (secretless, including outside Azure)

Managed identities exist only for resources running in Azure. For workloads elsewhere — GitHub Actions, on-prem or non-Azure Kubernetes (AKS / EKS / GKE), AWS, GCP — workload identity federation removes secrets via OIDC trust.

You configure a federated identity credential (FIC) on a user-assigned managed identity or an app registration. It is not supported on a system-assigned managed identity. The FIC names an external IdP by:

• Issuer — matches the iss claim (an OIDC-discovery URL).
• Subject — matches the sub claim, e.g. repo:org/name:ref:refs/heads/main for GitHub or system:serviceaccount:ns:sa for Kubernetes.
• Audience — exactly one, verified during token exchange, default api://AzureADTokenExchange.

At runtime the external workload presents its own IdP-issued token; Entra validates issuer / subject / audience and exchanges it for an Entra access token — no client secret stored anywhere.

7. OAuth permissions, scopes, and consent

The Microsoft identity platform has two permission models:

• Delegated permissions (scopes / oauth2Permissions) — used in delegated access: the app acts on behalf of a signed-in user and is bounded by both its granted scopes and the user’s own privileges. An app with delegated Files.Read.All reads only files the signed-in user can read.
• Application permissions (app roles / app-only) — used in app-only access (daemons, background services): the app acts as itself with no user, bounded only by the permission. An app with application Files.Read.All reads every file in the tenant. Application permissions always require admin consent.

Consent is how permissions are granted:

• User consent can cover low-risk delegated scopes (subject to tenant user-consent policies).
• Admin consent is required for application permissions and for high-privilege delegated permissions (e.g. Directory.ReadWrite.All).

The result of consent is recorded as an oauth2PermissionGrant (delegated) or an appRoleAssignment (application). Preauthorization lets a resource owner grant client apps without prompting users; the .default scope drives the Grant admin consent experience.

Configuring scopes (AZ-500): expose a web API’s delegated scopes (e.g. access_as_user, with “who can consent” = admins-only or admins-and-users) and define app roles for application callers under the app registration. Scopes typically take the form resourceURI/scopeName; the registration portal recommends the resource URI api://{clientId}. To client apps, scopes appear as delegated permissions and app roles appear as application permissions.

8. External identities

• B2B collaboration — invite external users as guest objects in your workforce tenant; they sign in with their own home identity and can be added to groups/apps like employees.
• B2B direct connect — a mutual, two-way trust between two Entra organizations with no guest object created (the canonical use is Teams shared channels); each side configures inbound/outbound.
• Microsoft Entra External ID in external tenants — the CIAM product for customer-facing apps; the successor to Azure AD B2C (B2C is on a deprecation path for new tenants). Separate external tenant, customized sign-up/sign-in, social IdPs.
• Cross-tenant access settings — govern B2B collaboration and direct connect: inbound/outbound scoping by user/group/app, trust MFA and device claims (compliant / hybrid-joined) from the partner so guests aren’t re-challenged, automatic redemption, and cross-cloud collaboration (Commercial ↔ Government ↔ China, partner identified by tenant ID). No limit on the number of partner organizations.
• External collaboration settings — who may invite guests, guest default permissions, and allow/deny domain lists.
• Decentralized identity / Microsoft Entra Verified ID — issue and verify verifiable credentials (e.g. proof-of-employment) that the holder controls in a wallet; the SC-100 answer to “decentralized identity.”

9. Enterprise access model, secure admin, CIEM, AD DS hardening, PAW

Enterprise access model

The successor to the legacy AD tier model organizes privileged access by plane:

• Tier 0 = the control plane — identity systems and anything that can grant control of the environment. Ruthlessly minimized and isolated.
• Former Tier 1 splits into a management plane (enterprise-wide IT admin) and a data/workload plane (per-workload admin, dev/DevOps).
• Former Tier 2 splits into user access (incl. B2B/B2C/public) and app access (the API surface).

Design rule: lower planes never control higher planes.

Privileged Access Workstation (PAW)

A dedicated, hardened device used only for administration — the single trusted entry point into the control plane. Controls: Credential Guard, Device Guard, Exploit Guard, AppLocker application control, BitLocker, Intune-managed with a security baseline, and deny-default web access (only a small allowlist of admin endpoints), with no general browsing / email / productivity. Tiered profiles run Enterprise → Specialized → Privileged. Admins use separate accounts and devices for productivity.

CIEM — the major change

CIEM now lives natively in Microsoft Defender for Cloud’s Defender CSPM plan, analyzing human and workload identities across Azure, AWS, and GCP to surface overprovisioned/inactive identities, enforce least privilege, and feed attack-path / lateral-movement analysis and Cloud Security Explorer. SC-100 “design a solution for cloud infrastructure entitlement management” should reference Defender for Cloud CIEM, not the retired Entra product. (The Posture & Governance unit owns CSPM/CWPP depth; here CIEM is the identity-permissions lens.)

AD DS hardening (SC-100)

For “specify requirements to harden AD DS” and “evaluate AD DS resilience to common attacks,” the deliverable is a hardening requirement set:

• Enforce tier isolation — Tier 0 admins never log on to lower tiers.
• Deploy Windows LAPS to randomize local admin passwords.
• Remove standing membership of Domain / Enterprise / Schema Admins (use just-in-time / PAM patterns).
• Protect domain controllers; restrict and monitor privileged groups.
• Detect AD attacks (Kerberoasting, DCSync, Golden Ticket) with Defender for Identity — the detection tooling belongs to the Security Operations unit; here you produce the requirements.

Securing tenant administration (SC-100)

Consolidate everything above into a coherent secure-administration design spanning the cloud tenant, SaaS, and multicloud: PIM-gated eligible roles, phishing-resistant MFA via CA + authentication strength, protected actions on tenant-control operations, PAWs for all control-plane admins, break-glass governance, and access reviews of admins and guests.

AZ-500 (operate) ↔ SC-100 (design) — the through-line

Cross-references

• Quick recall: Cheat-sheet — Unit 1
• Highest-yield concepts + worked scenarios: High-ROI — Unit 1
• Glossary, exam index, deprecation/retirement timeline: 99-Appendix
• Strategy & sequencing rationale: 00-Strategy-and-Map

Downstream units that consume this unit’s primitives

• Secure Networking & Edge Protection — Entra Internet/Private Access SSE consume Entra identity; identity is its prereq.
• Data, Storage & Key Management — Key Vault access via RBAC and managed identity (wired here, taught there).
• Secure Compute, Containers & Endpoint Baselines — Bastion/JIT, AKS authentication, Windows LAPS.
• Posture, Governance & Compliance — Azure Policy governance; CIEM (Defender for Cloud).
• Security Operations — Entra ID Protection risk-engine internals; Defender for Identity AD attack detection.