Microsoft Entra Fundamentals

This course provides a general but complete overview of Microsoft Entra, Microsoft’s unified multi-cloud identity and access solution. It covers the three major components of Microsoft Entra: Azure Active Directory, Microsoft Entra Permissions Management, and Microsoft Entra Verified ID.

Table of Contents

• Module 1: Introduction to Microsoft Entra
  • Course Scope
  • Zero Trust and Identity as the Security Perimeter
  • The AAA Security Framework
  • What Is Microsoft Entra?
  • Microsoft Entra Family Members
  • Demo: Touring the Microsoft Entra Admin Center
  • Module 1 Key Takeaways
• Module 2: Azure Active Directory
  • External Identities: B2B and B2C Collaboration
  • Azure AD External Identity Flows
  • Azure AD Identity Protection
  • Azure AD Conditional Access
  • Demo: Configuring External Identity Support
  • Demo: Testing the Azure AD Guest User Flow
  • Demo: Implementing Azure AD Conditional Access
  • Azure AD Entitlement Management
  • Demo: Configuring Azure AD Entitlement Management
  • Demo: Testing Access to Access Packages
  • Module 2 Key Takeaways
• Module 3: Permissions Management
  • The Permissions Management Use Case
  • What Is Microsoft Entra Permissions Management?
  • Permissions Management Feature Overview
  • Relationship Among Microsoft Entra Products
  • Touring the Permissions Management Portal
  • Just-in-Time Role Elevation and Custom Roles
  • Module 3 Key Takeaways
• Module 4: Verified ID
  • Understanding Verifiable Credentials
  • Microsoft Entra Verified ID
  • Example Scenario: The University Student Credential
  • Entra Verified ID Setup Process
  • Demo: Entra Verified ID End-to-End Flow
  • Demo: Preparing Your Azure Environment
  • Demo: Configuring Entra Verified ID
  • Demo: Testing Verified Credential Functionality
  • Module 4 Key Takeaways
• Summary

Module 1: Introduction to Microsoft Entra

Course Scope

This is a fundamentals-level course: no prior Azure knowledge is required. The course begins with a general introduction to Microsoft Entra and then goes into the three marquee services that fit within it, without going too deep into any one of them:

• Azure Active Directory (Azure AD) — the long-standing cloud identity store, now consolidated under the Entra umbrella.
• Microsoft Entra Permissions Management — a cloud infrastructure entitlement management (CIEM) solution.
• Microsoft Entra Verified ID — a decentralized identity (verifiable credentials) solution.

Zero Trust and Identity as the Security Perimeter

Microsoft’s guiding cloud-architecture and information-security principles set the stage for everything else in this course.

In the early days of Active Directory — and even earlier, with Windows NT domains and workgroups — Windows was largely open by default, and it was up to the administrator to gradually lock it down. That posture has been inverted. Modern architecture assumes zero trust and assume breach: the operating assumption is that an application or identity has already been compromised, and the goal becomes limiting the resulting blast radius.

This is why identity is treated as the most important security perimeter — not just in Azure, but across all of information technology. In a typical hybrid Azure environment:

flowchart TD
    AAD[Azure Active Directory<br/>Cloud Identity Store] --> Cloud[Cloud Users, Groups,<br/>Devices, Applications]
    AAD --> OnPrem[On-premises Active Directory<br/>via Azure AD Connect / Cloud Sync]
    AAD --> Remote[Remote / Work-from-home<br/>Employees]
    AAD --> MDM[Mobile Device Management<br/>Azure AD + Microsoft Endpoint Manager]
    AAD --> External[External Identities<br/>Partners & Non-employee Users]

Azure Active Directory sits at the center as the Microsoft cloud platform’s identity store, where users, groups, devices, and applications all live. By securing identity first, organizations prevent the initial intrusion that could otherwise cascade into compromised cloud applications. Every one of these access paths — on-premises AD, remote employees, MDM-managed devices, and external identities — relies on credential validation (authentication). Once a security principal is authenticated, the next concern becomes scoping their authorization.

The AAA Security Framework

Information security has long relied on the AAA framework: Authentication, Authorization, and Accounting.

flowchart LR
    AuthN["Authentication<br/>(Identity Verification)"] --> AuthZ["Authorization<br/>(Least-Privilege Scope)"]
    AuthZ --> Acct["Accounting<br/>(Audit Trail)"]

Authentication is identity verification, historically a username/password credential pair (the username is typically an SMTP-format email address). Modern practice goes beyond a single factor and layers in multiple authentication factors:

Multi-factor authentication (MFA) combines two or more of these factors. A device such as a smartphone is frequently required to satisfy the possession factor; the Microsoft Authenticator app layers a biometric or passcode challenge on top of the device lock itself, effectively stacking multiple factors before a user can even respond to an MFA prompt.

Authorization is where the principle of least privilege comes into play. Once identity is verified, permissions for that identity should be scoped as tightly as possible, consistent with zero trust and assume-breach thinking. If an account running with only baseline permissions is compromised, the attacker can only do damage up to the amount of privilege that account has been assigned. Tools such as Azure AD Privileged Identity Management (PIM) and Microsoft Entra Permissions Management support a separate approval workflow for privilege elevation, which raises the bar considerably for a bad actor.

Accounting is the audit trail — a record of both successful and failed authentication and authorization requests. Many Azure AD and Entra security tools are backed by machine learning models that watch for anomalous behavior. For example, if a user typically works with app services and function apps and suddenly starts interacting heavily with virtual machines, Azure AD Identity Protection can flag this as anomalous and dynamically raise the account’s risk level — supplementing human security analysis with AI-driven automation.

What Is Microsoft Entra?

The name “Entra” reflects the idea that identity is the entry point into a hybrid, multi-cloud environment. Along with assume-breach, least-privilege, and MFA principles, there is also a usability challenge: the entry point needs to remain as frictionless as possible for legitimate users.

Microsoft Entra is an integrated family of multi-cloud identity and access solutions. The “multi-cloud” framing is deliberate — Microsoft recognizes that many customers run workloads across Azure, AWS, and Google Cloud simultaneously, and Entra is designed around that reality rather than pretending other providers don’t exist.

Entra also consolidates previously disparate Azure Active Directory security solutions — Azure AD Identity Protection, Azure AD Privileged Identity Management, and Azure AD Identity Governance — under one roof, with the theme of unified security governance and administration.

Microsoft Entra Family Members

A classic example of Verified ID’s value: proving you’re a university student to receive a discount. Historically this required jumping through hoops (e.g., proving ownership of a .edu email address). With Verified ID, the university issues a credential as a distributed identity (DID) partner; the student — not the identity provider — owns that credential and can selectively disclose only the claims needed for a given verification.

Demo: Touring the Microsoft Entra Admin Center

This walkthrough compares the traditional Azure portal experience with the newer, unified Microsoft Entra admin center.

1. Starting point: portal.azure.com → Azure Active Directory blade. Many advanced Azure AD capabilities are tucked away and hard to discover in this classic experience:

   • Under Users, there is a reference to Per-user MFA, but no obvious top-level “MFA” settings entry.
   • Identity Governance surfaces Entitlement Management, Access Packages, and Catalogs, but this is set within a different blade that also folds in unrelated services like Privileged Identity Management.
   • A newer Security blade aggregates things like Microsoft Defender for Cloud (formerly Security Center).
   • The Verified ID service used to be called Verifiable Credentials, another indicator that the classic portal UI has not fully caught up.

2. Alternative: aad.portal.azure.com. This is “yet another UI” — its left navigation only shows a short favorites list by default; you must click All services to reach the rest of Azure AD’s capabilities, landing on essentially the same blade seen in the standard Azure portal. Microsoft displays a banner here noting that “Microsoft Entra has a simpler, integrated experience for managing all of your identity and access management needs.”

3. The unified experience: entra.microsoft.com. This is the Microsoft Entra admin center. The overview page surfaces the three marquee features studied in this course directly: Azure AD, Entra Permissions Management, and Verified ID. Global navigation is organized by section:

   • Azure Active Directory section: users, groups, devices, registered applications.
   • Protect & secure section: Conditional Access, Identity Protection.
   • Identity Governance section: Entitlement Management and Privileged Identity Management (PIM), all under one roof.
   • Permissions Management links out to a separate DNS domain, because the underlying product is an acquisition (the SaaS company CloudKnox, acquired by Microsoft in 2021) that has not yet been fully absorbed into the Entra domain.
   • Verified ID has its own dedicated section as well.

Not everything present in the classic Azure portal has been ported over to the Entra admin center yet, so expect the two experiences to coexist for a while until Microsoft reaches full feature parity.

Module 1 Key Takeaways

• Modern Azure identity architecture is built on zero trust and assume breach: minimize blast radius rather than assume a hardened perimeter.
• Identity is the primary security perimeter across on-premises AD, remote employees, MDM-managed devices, and external identities.
• The AAA framework (Authentication, Authorization, Accounting) underlies almost every Entra capability covered in this course.
• Microsoft Entra unifies Azure AD, Permissions Management, and Verified ID under the entra.microsoft.com admin center, though full feature parity with the classic Azure portal is still in progress.
• Bookmark entra.microsoft.com going forward, while keeping portal.azure.com in your back pocket until parity is complete.

Module 2: Azure Active Directory

External Identities: B2B and B2C Collaboration

Azure Active Directory is a REST API-based identity service — fundamentally different from on-premises Active Directory Domain Services, which is a Kerberos/LDAP directory service. Azure AD natively supports vendor-neutral identity protocols such as OpenID Connect and OAuth 2.0. It is primarily used for identity management of people (users, groups) and service principals/managed identities (non-interactive service accounts), and it supports basic mobile device management in conjunction with Microsoft Endpoint Manager.

Azure AD supports two forms of external identity collaboration:

Key terminology:

• Identity provider (IdP) — the system that authenticates the external user (e.g., Google, Facebook, a SAML IdP).
• Service provider / relying party — in this case, Azure Active Directory itself.

Critically, when using B2B or B2C, your Azure AD tenant does not authenticate the external users directly — the tenant trusts the identity provider, via the federation trust relationship, to have already authenticated them.

Azure AD External Identity Flows

The invitation and federation process supports several distinct paths depending on tenant configuration:

sequenceDiagram
    participant Admin as Tenant Administrator
    participant AAD as Azure AD Tenant
    participant User as External User
    participant IdP as Identity Provider (Google / Facebook / SAML)

    Admin->>AAD: Invite external user
    AAD->>User: SMTP email invitation (optional custom message)
    User->>AAD: Redeem invitation

    alt Direct federation configured (Google, Facebook, custom SAML/WS-Fed)
        AAD->>IdP: Redirect for authentication
        IdP->>User: OAuth 2.0 consent prompt (what the tenant is requesting)
        User->>AAD: Consent granted
        AAD-->>User: Enters tenant as Guest user
    else No direct federation
        AAD->>User: Does the user have a Microsoft Account (MSA)?
        alt Has MSA
            User->>AAD: Sign in with existing MSA
        else No MSA
            AAD->>User: Prompt to create an MSA
        end
        AAD-->>User: Enters tenant as Guest user
    else Last-resort option
        AAD->>User: Send one-time passcode (OTP) via email
        User->>AAD: Transcribe OTP to complete sign-in
        AAD-->>User: Enters tenant as Guest user
    end

Notes on each path:

• Direct federation (Google/Facebook built in; custom SAML or WS-Fed identity providers can also be added) is the smoothest experience — the user hits an OAuth 2.0 consent screen showing exactly what the tenant is requesting, then is admitted as a guest.
• If no direct federation exists, the invited user’s Microsoft Account (MSA) status is checked. This was historically the only option before external identities were expanded — contractors without an MSA had to create one just to be invited.
• The one-time passcode (OTP) flow is presented as a last resort: the tenant emails a one-time code to the invited user’s email address, which they transcribe to complete sign-in. This is generally not recommended as a primary path, since compromising the user’s mailbox alone would be sufficient to gain guest access via OTP.

Azure AD Identity Protection

Two premium Azure AD features protect identities in complementary ways, and it’s important to distinguish them: Azure AD Identity Protection and Azure AD Conditional Access. Both require Azure AD Premium licensing (commonly P1 or, more likely, P2 for the capabilities discussed in this module) — and note that guest users require a license just as much as native or synchronized users.

• Identity Protection protects the identities themselves — detecting and preventing illegitimate sign-ins or compromised accounts.
• Conditional Access protects applications and data — ensuring that access is granted only when the full authentication context (device, location, risk, etc.) is appropriate.

Identity Protection evaluates two categories of risk, both driven by Microsoft’s machine learning back end:

Because Identity Protection is backed by ML, these risk levels are computed dynamically per user based on learned “normal” behavior (e.g., a user who signs in from Nashville 90%+ of the time suddenly showing sign-ins from London or Mumbai). Administrators define remediations/mitigations tied to risk thresholds rather than manually flagging individual events.

Azure AD Conditional Access

Conditional Access evaluates every sign-in attempt to the specific Azure AD applications placed in scope of a policy. A Conditional Access policy is scoped by:

• Users and groups, including external identities.
• Device compliance (via Microsoft Endpoint Manager, if MDM is in use).
• Geographic location / IP address.
• Identity Protection risk levels (native integration).

flowchart TD
    Start([Sign-in Attempt]) --> Scope{In scope for policy?<br/>users/groups, cloud apps}
    Scope -- No --> NoPolicy[Policy does not apply]
    Scope -- Yes --> Conditions{All conditions satisfied?<br/>device compliance, location,<br/>risk level, client app type}
    Conditions -- No --> Block[Access Blocked]
    Conditions -- Yes --> Grant{Grant controls satisfied?<br/>e.g. Require MFA}
    Grant -- No --> Block
    Grant -- Yes --> Allowed[Access Granted]

Conditional Access integrates natively with Azure MFA, so a grant control commonly requires a second authentication factor. In short: users may only sign in to the specific apps they should have access to, and only when every rule in the policy evaluates to true.

Demo: Configuring External Identity Support

Environment setup used for this walkthrough:

• A statically assigned group called A-Team, initially containing one fictional cloud user, Devyani (authenticated against the certstar.net tenant).
• Microsoft 365 licenses auto-assigned to the A-Team group, so new members inherit them automatically.

Steps:

1. From the tenant root, go to External identities (not directly to New user → Invite external user) to configure collaboration policy first.
2. Under Guest access, review the default: “Guest users have limited access to properties and memberships.” Members can be granted access identical to internal members, but the default (limited) setting was retained.
3. Under Guest invite settings, restrict who is allowed to invite users — options range from “anyone” (default) down to “no one in the organization.” This is a good candidate for tightening, e.g., restricting invitations to specific administrator roles, though the default was kept for the demo.
4. Confirm “Allow external users to remove themselves” is enabled (recommended) — lets guests self-remove from the tenant via myapps.microsoft.com.
5. Under External identities → All identity providers, add federated identity providers. Built-in options are Google and Facebook; custom SAML or WS-Fed identity providers can also be registered. By default, the configured providers are Azure AD itself, Microsoft Account, and Email one-time passcode.
6. To enable Google as an identity provider, supply a client ID and client secret, generated via a Google Developer account — following Microsoft’s documented step-by-step instructions to complete the federation handshake.

Demo: Testing the Azure AD Guest User Flow

1. Create an external user invitation (using Invite, not Create): name the account, optionally attach a personal message, add the user to the A-Team group, and (optionally) elevate a directory role — not done in this walkthrough.
2. Because A-Team members inherit Microsoft 365 licenses, a usage location must be specified before license assignment succeeds.
3. To streamline the next demo (entitlement management), the invited user’s manager attribute is set to a second fictional user, Team Lead.
4. After the invite, the new user shows User type: Guest, No on-premises synchronization, with a Microsoft Account linked as their identity (an artifact of a prior test account reusing the same email).
5. A second guest, Zoey, is invited using a Gmail address to specifically exercise Google federation.
6. Back in External identities → collaboration settings, enable “Enable guest self-service sign-up via user flows.”
7. In an incognito browser, navigate to myapps.microsoft.com → Sign-in options → Sign into an organization → enter the organization domain (certstar.net) → enter the Gmail address.
8. The browser redirects to Google for authentication; after selecting the Google account, the user lands on the My Apps portal and — because of A-Team’s automatic license assignment — can access Microsoft 365 apps with one click.

Demo: Implementing Azure AD Conditional Access

Identity Protection configuration:

1. Navigate to Azure AD Identity Protection. Beyond the MFA-onboarding policy type, the two policies of interest are sign-in risk policy and user risk policy.
2. For each policy: scope to users/groups (e.g., A-Team), choose a risk threshold (Low / Medium / High), and select a control — block access or allow access + require MFA (for sign-in risk) or allow access + require password change (for user risk).
3. Identity Protection risk assessment is broad: it spans all apps a user attempts to access and all behavior across the Microsoft cloud platform.

Conditional Access configuration:

1. Under Conditional Access → Named locations, define IP ranges or country geolocations that can later be referenced as trusted/untrusted locations within policies.
2. Create a new policy (“A Team Policy”):
   • Users and groups: scope to A-Team (options also include All guest and external and Directory roles).
   • Cloud apps: select which applications the policy governs. ⚠️ Being too broad here risks locking out administrators — always maintain at least one emergency break-glass global administrator account exempt from all Conditional Access policies, in case Microsoft’s own MFA/Conditional Access backbone experiences an outage.
   • Conditions: layer in Identity Protection risk thresholds (e.g., low/no risk only), device platform restrictions (e.g., Windows or Mac only), trusted locations, and client app restrictions (e.g., browser only, no legacy authentication clients).
   • Grant: choose Grant access and select at least one control, such as Require multifactor authentication.
   • Policies can be enabled in enforcement mode or report-only mode (useful for testing and eliminating false positives before going live).
3. The What If modeler lets you simulate whether a specific user, under specified conditions (device, risk level, client app, location), would be subject to a given policy — validated in the demo against the Devyani user, confirming she would be subject to the A Team Policy under low-risk, Windows, modern-auth conditions.

Azure AD Entitlement Management

Entitlement Management addresses least-privilege resource access for group-based permissions. Rather than adding a user to a group permanently (where RBAC role assignments at management-group, subscription, resource-group, or resource scope are inherited indefinitely), Entitlement Management drives a self-service request-and-approval process for defined access packages.

Key concepts:

• Catalog — a collection of resources (groups, applications, SharePoint sites) that can be bundled.
• Access package — one or more resource roles drawn from a catalog, advertised to eligible users, with configurable request/approval policies.

sequenceDiagram
    participant Admin as Administrator
    participant Catalog as Catalog & Access Package
    participant User as Requesting User
    participant Approver as Approver (e.g. Manager)
    participant Resource as Azure Resource (Group / App / SharePoint site)

    Admin->>Catalog: Create catalog, add resources
    Admin->>Catalog: Define access package (roles + policies)
    User->>Catalog: Self-service request for access package
    Catalog->>Approver: Route for approval
    Approver-->>Catalog: Approve / Deny
    Catalog->>Resource: Assign role / group membership (time-bound)
    Resource-->>User: Access granted until expiration or access review

Without this process, group memberships tend to accumulate silently: an administrator grants access, forgets about it, and years later the user still has access even after changing roles or teams. Entitlement Management is designed to keep access just-in-time and no longer than necessary.

Demo: Configuring Azure AD Entitlement Management

Setup context:

• A resource group named dp420 containing a Cosmos DB (NoSQL) account.
• Under Access control (IAM) → Role assignments, the A-Team group initially has Contributor access to this resource group.
• All three current A-Team members are removed from the group, so that only an approved entitlement request re-establishes membership (and therefore Contributor access).

Steps in the Microsoft Entra admin center, under Identity Governance:

1. Note the three related capabilities under Identity Governance: Entitlement Management, Access reviews, and Privileged Identity Management (PIM).
   • PIM focuses on privileged/high-level Azure AD and Azure resource roles and time-limited elevation to those roles (with a related feature, Privileged access groups, that overlaps somewhat with Entitlement Management).
   • Entitlement Management focuses on controlling group membership, bundled into catalogs/packages.
2. Create a catalog — e.g., AzResourceGroupCatalog — enabled (or not) for external users, depending on whether guests should be eligible.
3. Add resources to the catalog — e.g., Add resources → Groups and Teams → A-Team. Supported resource types: Azure AD groups, Microsoft Teams groups, registered applications, and SharePoint sites.
4. Create an access package — e.g., Test Package — configuring:
   • Resource roles: which catalog resources and roles are granted (e.g., become a member of A-Team, as opposed to an owner).
   • Requests: who can request access — users in the directory, users outside the directory, or nobody (administrators-only assignment).
   • Approval: whether an approval workflow is required, how many stages, and who the approvers are. By default, the requester’s manager attribute is used as the approver, but this can be overridden with specific approvers or a hybrid fallback approach.
   • Requestor information: custom questions/attributes such as a justification field (e.g., “Why do you need access to this resource?”).
   • Lifecycle: whether access package assignments expire after a set number of days/hours, or never (not recommended).
   • Access reviews: optional periodic prompts (to the user or their manager) to reconfirm continued need for the access package, keeping assignments from going stale.

Demo: Testing Access to Access Packages

1. Sign in as Devyani at myaccess.microsoft.com (the self-service portal for access package requests and consumption) and request the dp420-resource-group-package, providing a business justification (e.g., “Need to work with Cosmos, Project ABC”).
2. Because the package requires manager approval, sign in as the Team Lead account at myaccess.microsoft.com → Approvals, review the pending request details, and Approve.
3. Back in the Azure portal, under the dp420 resource group’s Access control (IAM), verify that Devyani is now listed as Contributor — inherited via her freshly re-established A-Team membership, granted entirely through the entitlement management workflow rather than a manual group edit.

Module 2 Key Takeaways

• B2B federates external partner identities into your own tenant; B2C is a separate, customer-facing tenant type for consumer applications.
• External identity flows fall back through direct federation → Microsoft Account → one-time passcode, in decreasing order of recommended use.
• Identity Protection protects identities via sign-in risk and user risk, both computed by machine learning; Conditional Access protects apps and data by evaluating the full sign-in context against policy conditions and grant controls.
• Always retain a break-glass admin account exempt from Conditional Access policies.
• Entitlement Management replaces static, easily-forgotten group memberships with self-service, approval-gated, time-bound access packages built from catalogs of groups, apps, and SharePoint sites.

Module 3: Permissions Management

The Permissions Management Use Case

Six recurring business concerns motivate this module, most acute in hybrid, multi-cloud organizations:

The umbrella term for solving these problems is CIEM — Cloud Infrastructure Entitlement Management: “a specialized identity-centric solution focused on managing cloud access risk via administrator controls and entitlement governance in hybrid, multi-cloud environments,” ideally providing auto-remediation and enforcement of least privilege.

What Is Microsoft Entra Permissions Management?

Microsoft Entra Permissions Management (EPM) is Microsoft’s CIEM solution. Background and value proposition:

• Originally CloudKnox Permissions Management, acquired by Microsoft around 2021; now branded as Microsoft Entra Permissions Management within the Entra admin center.
• Detects, helps automatically right-size, and continuously monitors unused and excessive permissions.
• Supports self-service and approval workflows, aiming to reduce the permissions gap, right-size roles, and enforce least privilege.
• Native multi-cloud support: a single toolset that manages permissions across Azure, AWS, and Google Cloud Platform.
• Analyzes risk in permissions usage — live monitoring of create/read/update/delete operations — and surfaces anomalies through alerting and remediation, AI-backed rather than purely manual.
• Licensed separately from the rest of the Microsoft Entra suite.

Permissions Management Feature Overview

EPM’s feature set is organized into three pillars:

flowchart LR
    subgraph Discover[Discover & Assess]
        D1[Auto-discovery of subscriptions,<br/>resources, users, groups, service principals]
        D2[Permission Creep Index - PCI]
    end
    subgraph Remediate[Remediate & Manage]
        R1[Granular, just-in-time<br/>self-service with approval]
    end
    subgraph Monitor[Monitor & Alert]
        M1[Autopilot: custom + built-in rules]
        M2[Right-sizing recommendations]
    end
    Discover --> Remediate --> Monitor

• Discover & Assess — auto-discovers subscriptions, resources, users/groups/service principals, and all permissions/operations, including custom RBAC role definitions. Central to this pillar is the Permission Creep Index (PCI) — not a compliance standard, but a measure of expanding or shrinking scope of permission assignments for user and workload identities.
• Remediate & Manage — granular, just-in-time self-service access requests with approval.
• Monitor & Alert — includes Autopilot, where custom rules plus built-in rules generate recommendations for right-sizing the environment’s permission structure.

Relationship Among Microsoft Entra Products

There is meaningful overlap — but by design, complementary positioning — among Azure AD Privileged Identity Management (PIM), Azure AD Entitlement Management, and Microsoft Entra Permissions Management.

flowchart TB
    subgraph Shared[Shared Capabilities]
      AR[Access Reviews]
      JIT[Just-in-Time Role Activation]
    end
    PIM["Azure AD PIM<br/>(privileged role elevation)"] --> Shared
    EM["Azure AD Entitlement Management<br/>(catalogs & access packages)"] --> Shared
    EPM["Microsoft Entra Permissions Management<br/>(cross-cloud CIEM, task-level roles)"] --> PIM
    EPM --> EM

In practice: use PIM for structuring who can hold high-privilege roles and for how long; use Entitlement Management for known-in-advance catalogs/packages and role assignments; and use Entra Permissions Management as an overlay that reports — from a trend/alerting perspective — on whether those assignments across PIM and Entitlement Management are too broad or too restrictive over time.

Touring the Permissions Management Portal

Onboarding and navigation, starting from entra.microsoft.com and clicking through to the separate EPM dashboard:

1. Create a configuration — onboard Azure subscriptions (“authorization systems” in Azure terminology; the equivalent term is account in AWS and project in Google Cloud) either via delegated management/detection, or by entering them manually.
2. For manual onboarding, grant the EPM enterprise application (“cloud infrastructure entitlements management” app) the necessary Azure roles:

# Grant the Microsoft Entra Permissions Management (formerly CloudKnox)
# enterprise application the Reader role, so it can discover resources
# and role assignments across the subscription.
New-AzRoleAssignment `
    -ApplicationId "<EPM-enterprise-app-client-id>" `
    -RoleDefinitionName "Reader" `
    -Scope "/subscriptions/<subscription-id>"

# To let EPM remediate findings (boot users out of roles, create
# custom task-level role assignments), also grant User Access Administrator.
New-AzRoleAssignment `
    -ApplicationId "<EPM-enterprise-app-client-id>" `
    -RoleDefinitionName "User Access Administrator" `
    -Scope "/subscriptions/<subscription-id>"

# Equivalent onboarding commands using the Azure CLI
az role assignment create \
    --assignee "<EPM-enterprise-app-client-id>" \
    --role "Reader" \
    --scope "/subscriptions/<subscription-id>"

az role assignment create \
    --assignee "<EPM-enterprise-app-client-id>" \
    --role "User Access Administrator" \
    --scope "/subscriptions/<subscription-id>"

The Reader role is the minimum needed for EPM to observe and report. The User Access Administrator role is what enables EPM to actually change access — accept its recommendations, remove excessive role assignments, and create granular, task-scoped custom roles.

3. Dashboard — shows the Permission Creep Index trend over time. The goal is a stable or declining PCI trend line (less permission, not more, accumulating over time). Findings surface both identity risk (inactive users, inactive applications, highly privileged users) and resource exposure (e.g., encryption-at-rest key configuration for services like Azure Storage or Cosmos DB — Microsoft-managed vs. customer-managed keys — and externally accessible resources, such as a flagged “1 Blob Container Accessible Externally” finding).
4. Analytics page — a tabular view filterable by resources, users, or service principals, drilling down to the individual task level: every create/read/update/delete operation a user performs, 24×7×365. This surfaces what identities are actually doing with their permissions, not just what role they’ve been assigned.
5. Remediation page — lets you add or remove role assignments down to the task level, and take quick actions: revoke unused tasks, revoke high-risk tasks, revoke delete tasks, or assign read-only status — all contingent on EPM having sufficient controller-level access to the authorization system.

Just-in-Time Role Elevation and Custom Roles

EPM’s task-level granularity is a key differentiator versus native Azure IAM controls. For example, a user who needs to create a virtual machine requires several specific Azure Resource Manager REST API operations in the virtual machine space — but with EPM, a user can request access to just those specific read/write operations within the microsoft.virtualmachines resource provider, rather than the broad, pre-built Virtual Machine Contributor role. When a task-level role is defined, EPM dynamically creates a custom RBAC role containing only those tasks.

This lets teams right-size roles down to exactly what a user needs for their day-to-day job, with anything beyond that requiring a time-bound elevation request. The Requests and My Requests views on the remediation page implement this approval workflow — again overlapping conceptually with Azure AD PIM’s role-activation model, but extending it to task-level custom roles.

The Reports page includes prebuilt reports (inactive groups, system identities, resources) and a granular view of permissions granted vs. used per resource — the exact permissions-gap data in tabular form. A Kusto-like query interface is also available for ad hoc auditing when the prebuilt reports don’t answer a specific question.

Module 3 Key Takeaways

• CIEM addresses the permissions gap, multi-cloud complexity, identity sprawl, orphaned privilege, permissions creep, and the need for self-service elevation.
• Microsoft Entra Permissions Management (EPM), formerly CloudKnox, is Microsoft’s CIEM solution, licensed separately, spanning Azure, AWS, and Google Cloud.
• EPM’s three pillars are Discover & Assess, Remediate & Manage, and Monitor & Alert, anchored by the Permission Creep Index.
• EPM, Azure AD PIM, and Azure AD Entitlement Management are complementary, not redundant — EPM overlays and reports on the other two over time.
• Onboarding requires granting the EPM enterprise application Reader (for discovery) and, optionally, User Access Administrator (for remediation) at the subscription scope.
• EPM can generate task-level custom RBAC roles dynamically — a capability that goes well beyond native Azure IAM.

Module 4: Verified ID

Understanding Verifiable Credentials

The core problem: can we build credentials that are less susceptible to fraud, while still respecting user privacy? Physical-world analogs — passports, driver’s licenses, student IDs, employee badges — are all vulnerable to theft or duplication, and it’s often hard to verify a claim (e.g., “I have a valid Social Security Number”) without revealing sensitive underlying data (the SSN itself).

Verifiable digital credentials combine public-key cryptography, the Bitcoin blockchain, and other distributed networks to verify claims about a subject. This is conceptually related to identity federation and single sign-on, but distinct: SSO deals with authenticating into a software system, whereas verifiable credentials are more human-centric, prioritizing user ownership and privacy. Users keep credentials on their smartphone and can selectively disclose individual claims — proving, for example, that they are enrolled with a valid SSN, or that they are employed by an organization, without revealing the SSN or employee ID itself.

Distributed crypto-backed verification is significantly harder to defeat via fraud/cloning than a card in a physical wallet.

Microsoft Entra Verified ID

Microsoft’s implementation of verifiable credentials is Microsoft Entra Verified ID (formerly Azure Active Directory Verifiable Credentials). It taps into existing decentralized-identity standards, developed in alliance with consortiums including the W3C and the Decentralized Identity Foundation (DIF).

The architecture is described as decentralized on two axes:

• Decentralized issuance — each issuer (an organization, hospital, college, university) distributes credentials directly to its people, who carry the credentials on their own devices.
• Decentralized trust — the underlying verification is handled by a decentralized trust network (blockchain), rather than a single central authority.

Under the hood, the service is standards-based: REST APIs and protocols over TLS on TCP port 443, using OpenID Connect for its sign-on/federation semantics.

sequenceDiagram
    participant Issuer as Issuer (e.g. University)
    participant Holder as Holder (Student, via Microsoft Authenticator)
    participant Verifier as Verifier (Store / Service)

    Issuer->>Holder: Issue verifiable credential
    Holder->>Holder: Store credential in Authenticator wallet
    Verifier->>Holder: Present verification request (QR code)
    Holder->>Verifier: Selectively disclose requested claims
    Verifier-->>Holder: Verification result

Example Scenario: The University Student Credential

A student at a university receives a verified ID credential via Microsoft Authenticator, which functions as their Verified ID wallet. (Note: Microsoft Authenticator is also required for passwordless Azure MFA, and serves double duty here as the credential wallet.)

Later, the student wants to redeem a discount at a store that offers pricing for verified students — whether that’s an in-person or online transaction. Traditionally, proving student status required something brittle, like a .edu email address (which becomes a problem after graduation, even for legitimate alumni). With Verified ID:

1. The store issues a verification request.
2. The user fields that request in Microsoft Authenticator.
3. The verification completes, and the store confirms the person is, in fact, a legitimate alum or currently enrolled student — without the friction of an email-based proof.

Entra Verified ID Setup Process

High-level dependencies and workflow for setting up Microsoft Entra Verified ID:

flowchart TD
    A["Global Administrator in<br/>Azure AD Tenant"] --> B["Create Azure Key Vault<br/>(stores cryptographic signing keys)"]
    B --> C["Create App Registration(s)<br/>Client ID / Client Secret / API permissions"]
    C --> D["Verify Domain / DID<br/>(well-known endpoint or ION network)"]
    D --> E["Create Organization in<br/>Microsoft Entra Verified ID"]
    E --> F["Define Credential(s)<br/>Rules model + Display model"]
    F --> G["Issue Credentials to Holders"]
    G --> H["Verify Credentials via Verifier Apps"]

• The person performing setup needs to be a global administrator in the Azure AD tenant, and should have high (ideally owner-level) privileges in the Azure subscription.
• An Azure Key Vault is required to store the cryptographic signing keys.
• A Verified ID API endpoint is created in Azure, which involves creating an app registration and configuring supporting API access.
• Within the Entra portal, one or more credentials are defined — the exact set of credentials depends entirely on the business (e.g., a hospital might define credentials for physicians, nurses, administrators, and social workers).
• Credentials are then issued in a manner similar in spirit to issuing digital certificates.

Demo: Entra Verified ID End-to-End Flow

Microsoft publishes an end-to-end demo application illustrating the full issue-and-verify lifecycle, reachable at thecontosouniversity.azurewebsites.net/landing. It hosts two fictional scenarios (a university and a bank); this walkthrough uses the Contoso University example.

The demo represents a recent graduate being onboarded to receive a digital student ID, which they then use to obtain their transcript remotely — a process that traditionally required in-person office visits, forms, or manual document verification.

1. Enter first and last name to begin.
2. The workflow is: Step 1 — retrieve your digital badge (student ID); Step 2 — confirm the credential in Microsoft Authenticator; Step 3 — access the student portal with your official transcript.
3. Clicking Get student ID displays a QR code plus a one-time PIN.
4. In Microsoft Authenticator’s Verified ID section, scan the QR code, then enter the PIN (e.g., 3350) as an additional authentication layer. (Organizations can layer in stronger attestations here — e.g., requiring a physical credential check before issuing something like a digital passport representation.)
5. Authenticator confirms: “Contoso University DID… woodgrovedemo.com verified, add a Verified ID as a student.” Tapping Add stores the credential in the Verified IDs list within Authenticator.
6. Returning to the student portal, scan a new QR code to verify the credential: Authenticator prompts “Do you want to share your student ID with the university?”, displaying exactly which claims (name, university, degree program, etc.) will be shared. Tapping Share completes verification and unlocks the transcript.

This demonstrates both halves of the workflow: (1) working with a DID issuer to obtain a credential, and (2) working with one or more verifiers to present/verify that credential.

Demo: Preparing Your Azure Environment

1. Azure Key Vault — created with an access policy granting the verifiable credential service the Get and Sign key permissions (needed so the service can use the signing key it stores there).
2. App registrations — one created for the verifiable credentials app itself:
   • Client ID — the GUID identifying the app.
   • Tenant ID — identifies the Azure AD instance.
   • Client secret — generated, used by the app to identify itself.
   • API permissions — beyond the standard Microsoft Graph permission, a permission is added and granted domain-wide admin consent for the verifiable credential service request, using a Create.All scope.
3. Sample project — the tutorial has you clone an open-source sample from GitHub, Azure-Samples/active-directory-verifiable-credentials-dotnet, which contains several project variants for different use cases. This walkthrough uses the first: 1-asp.net.core.api.idtokenhint.

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "<your-tenant-id>",
    "ClientId": "<your-app-registration-client-id>",
    "ClientSecret": "<your-client-secret>"
  },
  "VerifiedID": {
    "DidAuthority": "did:ion:<your-DID>",
    "CredentialManifest": "https://verifiedid.did.msidentity.com/v1.0/<tenant-id>/verifiableCredentials/contracts/<contract-id>",
    "IssuerAuthority": "<your-DID>"
  }
}

The bulk of the setup effort is tweaking appsettings.json to plug in values from the tenant’s own DID configuration.

Demo: Configuring Entra Verified ID

Within entra.microsoft.com → Verified ID:

1. Create an organization (only one organization is supported at a time; Organization settings → Reset allows starting over, but wipes everything, including any distributed credentials — use with caution). This walkthrough creates an organization called certstar.
2. The organization is tied to a tenant identifier (the Azure AD instance) and a separate DID — the engine used to create verified credentials.
3. Key vault location is specified (previously created).
4. Domain verification — this establishes the public web front end that interacts with the API. In this demo, a static website hosted from an Azure Storage account is used (an App Service would also work, but felt like overkill here):
   • Enable Static website on the storage account, using the default web.core.windows.net endpoint.
   • The blob container Azure creates for this purpose is named $web.
   • A hidden .well-known folder inside $web holds the DID configuration manifest files, downloaded during the domain-verification step.
   • This “organizational trust” approach is one of two ways to establish a DID; the alternative is the globally distributed ION network.
5. Define a credential — the tutorial has you create a credential called Verified Credential Expert, complete with a small badge graphic. Credential definitions include JSON fragments for the claims included and the rules governing how a user obtains the credential (e.g., a DMV-issued driver’s license credential might require attestation that the user has passed their driving test).

{
  "attestations": {
    "idTokenHints": [
      {
        "mapping": [
          { "outputClaim": "name", "required": true, "inputClaim": "$.name", "indexed": false },
          { "outputClaim": "university", "required": true, "inputClaim": "$.university", "indexed": true },
          { "outputClaim": "degreeProgram", "required": true, "inputClaim": "$.degreeProgram", "indexed": false }
        ],
        "required": false
      }
    ]
  },
  "display": {
    "locale": "en-US",
    "card": {
      "title": "Verified Credential Expert",
      "issuedBy": "Contoso University",
      "backgroundColor": "#003a5d",
      "textColor": "#ffffff"
    }
  }
}

Illustrative example of the rules/display model shape used to define a Verified ID credential — the attestations section maps input claims (e.g., from an ID token) to output claims embedded in the credential, and the display section controls how the credential card appears in Microsoft Authenticator.

Demo: Testing Verified Credential Functionality

The sample is a .NET application, tested locally alongside ngrok (a reverse-proxy service that exposes a localhost web application over the public internet).

# Build and run the ASP.NET Core sample application
dotnet build
dotnet run

# In a separate terminal session, expose local port 5000 over HTTPS
# so the Microsoft Authenticator app can reach it for verification callbacks.
ngrok http 5000

Walkthrough:

1. dotnet build followed by dotnet run starts the local application (listening on port 5000).
2. ngrok http 5000 creates a public, internet-accessible HTTPS endpoint mapped to localhost:5000. (Requires a free ngrok account and API key installed locally.)
3. Opening the ngrok-provided URL in a browser (past ngrok’s free-tier interstitial page, if applicable) loads the sample app’s front end, which demonstrates both credential issuance and credential verification.
4. Issuance, from a smartphone (iOS or Android): open Microsoft Authenticator → Verified ID section → Add account → Other (not “Personal” or “Work or school”) → scan the displayed QR code with the camera → enter the verification PIN. The Authenticator UI confirms whether the interaction is with a verified DID.
5. The credential now appears in Authenticator’s Verified IDs list, conceptually similar to a digital credit card stored in Apple Wallet.
6. Verification: when a relying party needs to verify the credential, they display a QR code; scanning it in Authenticator (via the same Add/scan flow) prompts a “Request to share” screen showing exactly which claims will be disclosed. Tapping Share (or Cancel) completes — or declines — the verification, and a Request approved confirmation is shown.

Module 4 Key Takeaways

• Verifiable credentials combine public-key cryptography and distributed/blockchain trust networks to let users own and selectively disclose claims about themselves, rather than relying on a central identity provider or easily-cloned physical documents.
• Microsoft Entra Verified ID (formerly Azure AD Verifiable Credentials) is built on open standards (W3C, DIF) and REST APIs over TLS/OpenID Connect.
• Three roles participate in every transaction: Issuer (creates/distributes credentials), Holder (stores/discloses via Microsoft Authenticator), and Verifier (requests and consumes disclosed claims).
• Setup requires a Key Vault for signing keys, one or more app registrations, domain/DID verification (via a .well-known manifest or the ION network), and defining credentials via a rules/display JSON model.
• Microsoft’s public Contoso University demo (thecontosouniversity.azurewebsites.net/landing) and the open-source active-directory-verifiable-credentials-dotnet sample are the fastest ways to see the full issue-and-verify lifecycle end to end.
• A well-known parallel example already in wide use: Microsoft certification badges issued via Credly, which are also decentralized, blockchain-verifiable digital credentials.

Summary

Microsoft Entra reframes identity as the primary security perimeter for hybrid, multi-cloud organizations, built on zero trust, assume breach, and the AAA framework (Authentication, Authorization, Accounting). It consolidates what used to be scattered Azure AD capabilities into a single admin experience, and adds two new capabilities that extend far beyond classic Azure AD: cross-cloud entitlement governance (Permissions Management) and decentralized, user-owned credentials (Verified ID).

Quick-Reference Table

Checklist: Getting Started with Microsoft Entra

• Bookmark entra.microsoft.com as the primary admin experience, while keeping portal.azure.com available until full feature parity is reached.
• Confirm at least one break-glass global administrator account is exempt from all Conditional Access policies.
• Review external collaboration settings (B2B guest invite restrictions, B2C requirements) before inviting external users.
• Enable Identity Protection sign-in and user risk policies, scoped to appropriate risk thresholds.
• Build Conditional Access policies scoped to specific apps and groups, starting in report-only mode before enforcing.
• Replace static, manually-managed group memberships with Entitlement Management catalogs and access packages where least-privilege, time-bound access matters.
• Onboard Azure (and, if applicable, AWS/Google Cloud) subscriptions into Microsoft Entra Permissions Management, granting Reader (and, where remediation is needed, User Access Administrator) to the EPM enterprise application.
• Monitor the Permission Creep Index over time and act on Autopilot recommendations to right-size roles.
• Evaluate Microsoft Entra Verified ID for any workflow that currently relies on brittle, hard-to-verify physical or email-based credentials.

Search Terms

microsoft · entra · fundamentals · azure · core · infrastructure · management · verified · permissions · identity · access · configuring · external · testing · conditional · credential · entitlement · flow · security · touring