Microsoft Identity and Access Administrator Study Guide

Explanation

Cloud computing is the delivery of computing services over the internet, including servers, storage, databases, networking, software, and analytics. Organizations choose between public (shared Microsoft infrastructure), private (dedicated on-premises), and hybrid (combined) deployments based on control, cost, and compliance needs.

Think of it as: Renting apartments vs. owning houses — public cloud is apartment living (shared facilities, lower cost, less control), private cloud is owning your own house (full control, higher cost), hybrid is owning a house with shared community amenities.

Key Mechanics: - Public cloud: Microsoft manages all infrastructure, customers manage data and access - Private cloud: Organization manages everything but infrastructure is dedicated - Hybrid cloud: Workloads move between public and private based on requirements - Wrong choice = forced migration costs, compliance violations, security gaps - Cloud type choice affects data residency, regulatory compliance, and operational costs

Examples

Example 1 — [Success] Hybrid cloud for regulated data A healthcare provider uses Azure public cloud for non-regulated patient portals and patient education sites, but keeps electronic health records (EHR) on private on-premises servers to meet HIPAA data residency requirements. Development teams seamlessly move workloads between public and private as needed.

Example 2 — [Blocked] Public cloud only, compliance fails A financial services firm chooses Azure public cloud for all systems to reduce costs. During audit, regulators require all customer account data remain in country-specific data centers. Fix required: Emergency migration of customer data to Azure Government Cloud (sovereign region), causing $2M in unplanned costs.

Key Mechanisms

- Core function: Cloud computing is the delivery of computing services over the internet, including servers, storage, databases, networking, software, and analytics. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hybrid cloud for regulated data - Decision clue: Industry: Retail (Multi-channel Commerce)

Review Path

Steps — Entra Admin Center: (Reference, inform architecture)

1. Navigate to entra.microsoft.com → Organization overview 2. Review tenant region and data residency settings 3. For cloud strategy, check: Manage → Settings → Data location 4. Review Microsoft Learn for regulatory requirements by region 5. Consult Azure compliance documentation for your industry 6. Plan hybrid connectivity: Azure → On-premises via ExpressRoute or VPN

Docs: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/cloud-computing-basics https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree https://learn.microsoft.com/en-us/azure/compliance/offerings/

Explanation

The shared responsibility model defines which security tasks Microsoft handles (security OF the cloud) versus what you handle (security IN the cloud). Microsoft secures the physical infrastructure, host OS, and hypervisor; you secure identities, applications, data, and network controls. The boundary shifts based on service type (IaaS, PaaS, SaaS).

Think of it as: Apartment building responsibility — building owner maintains structure and common areas (like Microsoft), you lock your doors and secure your belongings (like your data).

Key Mechanics: - IaaS: You manage most (OS, apps, data), Microsoft manages infrastructure - PaaS: Microsoft manages more (runtime, middleware), you manage apps and data - SaaS: Microsoft manages most, you manage user access and data classification - Assumption trap: Believing "cloud means Microsoft secures everything" leads to data breaches - Your oversight gaps = your liability regardless of Microsoft's infrastructure security

Examples

Example 1 — [Success] Correct responsibility split for SaaS A company uses Microsoft 365 Teams (SaaS). Microsoft secures Teams infrastructure, updates, and platform. The company manages: user identities, MFA enforcement, DLP policies, data classification labels, guest access rules. Clear boundary prevents security gaps.

Example 2 — [Blocked] Responsibility confusion in IaaS A developer team deploys a web app on Azure VMs (IaaS) but assumes Microsoft automatically patches the guest OS and application code. They skip OS patching. Attacker exploits unpatched vulnerability in Windows Server. Root cause: Confusion about responsibility boundaries — in IaaS, Microsoft doesn't patch your guest OS or app code.

Key Mechanisms

- Core function: The shared responsibility model defines which security tasks Microsoft handles (security OF the cloud) versus what you handle (security IN the cloud). - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Correct responsibility split for SaaS - Decision clue: Industry: Healthcare (Data Protection)

Review Path

Steps — Entra Admin Center: Security → Regulatory Compliance

1. Navigate to entra.microsoft.com → Security → Regulatory Compliance 2. Review applicable compliance standards (HIPAA, SOC 2, PCI-DSS) 3. Access Microsoft Trust Portal: aka.ms/trustcenter for responsibility maps 4. For each Azure service used, consult: Azure Service Trust Portal → Service Compliance 5. Document your team's responsibilities in a shared responsibility matrix 6. Assign owners to your side (identity, access, data classification, patching)

Docs: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-model https://learn.microsoft.com/en-us/azure/compliance/shared-responsibility-matrix/ https://aka.ms/trustcenter

Explanation

Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It authenticates users and apps, enforces access policies, issues tokens for cloud and on-premises resources, and integrates with thousands of SaaS applications. It serves as the central identity plane for hybrid and cloud-only organizations.

Think of it as: Your organization's digital ID card issuer and bouncer — Entra ID issues credentials, verifies identity, and decides who gets access to which resources.

Key Mechanics: - All users authenticate to Entra ID (cloud-native or synced from on-premises AD) - Tokens issued by Entra ID grant access to Azure resources, Microsoft 365, and integrated apps - Conditional Access policies evaluate every authentication attempt in real-time - Integration with on-premises AD via Microsoft Entra Connect maintains hybrid identity - Assumption trap: "Entra ID = password management" — it's actually federated identity + policy enforcement engine

Examples

Example 1 — [Success] Hybrid Entra ID with on-premises sync An enterprise syncs 10,000 employees from on-premises AD to Entra ID via Microsoft Entra Connect. Users sign in with corporate credentials (same username). Conditional Access policies block sign-in from anonymous IPs. On-premises servers validate tokens issued by Entra ID for SSO to legacy apps.

Example 2 — [Blocked] Entra ID misconfigured, legacy auth leaks A company enables Entra ID but leaves legacy authentication (Basic Auth, NTLM) enabled in Conditional Access. Attackers brute-force accounts via legacy Exchange protocols and bypass MFA. Root cause: Entra ID's Conditional Access doesn't block legacy auth by default — requires explicit policy.

Key Mechanisms

- Core function: Microsoft Entra ID is Microsoft's cloud-based identity and access management service. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hybrid Entra ID with on-premises sync - Decision clue: Industry: Enterprise (Global Workforce)

Review Path

Steps — Entra Admin Center: Overview

1. Navigate to entra.microsoft.com (Entra Admin Center) 2. Go to Overview to see tenant info, default domain (*.onmicrosoft.com) 3. For hybrid setup: Identity → Hybrid management → Microsoft Entra Connect Health 4. Check sync status and monitor user/device sync 5. Review Users → All users to verify sync or cloud-only users 6. Configure MFA: Protection → Authentication methods → Settings 7. Test Conditional Access: Protection → Conditional Access → Test policies

Docs: https://learn.microsoft.com/en-us/entra/identity-platform/v2-overview https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect https://learn.microsoft.com/en-us/entra/identity/authentication/overview-authentication

Explanation

Company branding customizes the Entra ID sign-in experience with company logos, colors, and custom text. This creates brand consistency when users authenticate to Microsoft services and integrated applications, increasing trust and user adoption. Branding is tenant-wide and can vary by language/locale.

Think of it as: White-labeling — your company logo appears on authentication pages instead of generic Microsoft branding, reinforcing company identity.

Key Mechanics: - Upload logo (280x60px), background image (1920x1080px), custom CSS - Configure per language (English, Spanish, French, German, etc.) - Applied to Entra ID sign-in page, password reset page, app launcher - Assumption trap: "Branding is cosmetic" — actually impacts user trust and phishing resistance - Custom sign-in text can include security messaging to prevent credential phishing

Examples

Example 1 — [Success] Branded sign-in reduces phishing clicks A financial firm adds company logo and custom text "Never share credentials with anyone" to sign-in page. Phishing emails imitating the company are now obviously fake because they lack the branded page. User phishing click-through rate drops 40%.

Example 2 — [Blocked] Missing branding, users assume fake page A consulting firm doesn't configure company branding. Users receive legitimate Entra ID sign-in prompts but assume they're phishing (because they don't see company branding) and click suspicious links in fake emails instead. Root cause: Lack of visual trust markers on actual sign-in pages.

Key Mechanisms

- Core function: Company branding customizes the Entra ID sign-in experience with company logos, colors, and custom text. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Branded sign-in reduces phishing clicks - Decision clue: Industry: B2B SaaS (Multi-tenant)

Review Path

Steps — Entra Admin Center: Branding

1. Navigate to entra.microsoft.com → Branding 2. Go to Company branding → Configure 3. Upload company logo (280x60px, .png/.jpg, <1MB) 4. Set background color or upload background image (1920x1080px) 5. Enter custom sign-in page text (e.g., "Welcome to Contoso") 6. Set username hint text (optional, e.g., "first.last@contoso.com") 7. Configure additional languages: Add language-specific branding 8. Save and test by accessing a sign-in page in incognito mode

Docs: https://learn.microsoft.com/en-us/entra/fundamentals/how-to-customize-branding https://learn.microsoft.com/en-us/entra/external-id/customize-branding

Explanation

Tenant properties control organization-wide Entra ID configuration including tenant name, technical contacts, privacy URLs, and regional data location. User settings restrict capabilities (app registrations, LinkedIn integrations, guest access). Group and device settings manage who can create groups, naming policies, device registration, and device management scope.

Think of it as: Organization bylaws — tenant properties set the rules for what users can do, what groups must be named, and who can access what device management features.

Key Mechanics: - Tenant name = organization display name shown in Microsoft 365 and Entra ID - User settings: Fine-grained control over user capabilities (app registration, linked accounts) - Group settings: Group creation permissions, naming policies (e.g., "DEPT_GroupName_Region") - Device settings: Who can join devices, device registration scope, device management policies - Assumption trap: "Default settings are secure" — many settings default to permissive (all users can register apps)

Examples

Example 1 — [Success] Locked-down tenant defaults An admin restricts: users cannot register applications, users cannot create groups (admins only), users cannot connect LinkedIn, users cannot access enterprise applications. Guest users limited to directory-scoped access. Result: Reduced shadow IT and unauthorized app sprawl.

Example 2 — [Blocked] Permissive defaults, security nightmare Default settings allow: all users to register apps, all users to create groups, all users to invite guests. An employee registers an unauthorized SaaS app on behalf of the company, grants it org-wide permissions, then leaves. That app now has persistent unauthorized access to all tenant data. Root cause: Tenant setting not restricting app registration.

Key Mechanisms

- Core function: Tenant properties control organization-wide Entra ID configuration including tenant name, technical contacts, privacy URLs, and regional data location. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Locked-down tenant defaults - Decision clue: Industry: Government (Regulatory Compliance)

Review Path

Steps — Entra Admin Center: Settings

1. Navigate to entra.microsoft.com → Manage → Settings 2. Configure tenant name and primary domain 3. For user settings: Go to User settings - Set "App registrations": Restricted or disabled - Set "LinkedIn account connection": Disabled (if required by policy) - Set "Access to Enterprise Applications": Restricted 4. For group settings: Go to Groups → General settings - Set "Group creation": Admins or Selected groups only - Add naming policy: "PREFIX_[GroupName]_SUFFIX" 5. For device settings: Go to Devices → Device settings - Set "Users may join devices to Entra ID": All, Selected, or None - Set MDM auto-enrollment scope if using Intune 6. Save changes

Docs: https://learn.microsoft.com/en-us/entra/fundamentals/how-to-manage-groups https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities

Explanation

Custom domains allow organizations to use branded domain names (like user@contoso.com) instead of default .onmicrosoft.com addresses for user identities and email. Domains must be verified via DNS records, and one domain is set as primary for new user provisioning. DNS records (MX, SPF, DKIM) enable email routing and security.

Think of it as: Email address branding — instead of users signing in as user@company.onmicrosoft.com (generic), they sign in as user@company.com (professional).

Key Mechanics: - Add domain in Entra ID, then prove ownership via DNS TXT record - Set as primary domain so new users get @company.com instead of @company.onmicrosoft.com - .onmicrosoft.com always remains as backup (cannot be removed) - MX records route email to Exchange Online - SPF/DKIM prevent email spoofing - Assumption trap: "Only names matter" — domain verification and MX records are required for email to work

Examples

Example 1 — [Success] Custom domain verified, email working Company adds contoso.com, adds DNS TXT record "MS=ms12345678", waits for validation (verified after 1 hour), sets contoso.com as primary. New users created with @contoso.com addresses. Email routing works via correct MX records.

Example 2 — [Blocked] Domain added but not verified, users cannot sign in Admin adds customer.com to Entra ID but forgets to add the DNS TXT verification record. Creates user john@customer.com, but john cannot sign in because the domain is unverified. Root cause: Domain verification is required before any user can authenticate with that domain.

Key Mechanisms

- Core function: Custom domains allow organizations to use branded domain names (like user@contoso.com) instead of default .onmicrosoft.com addresses for user identities and email. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Custom domain verified, email working - Decision clue: Industry: Professional Services (Multi-Domain)

Review Path

Steps — Entra Admin Center: Custom domains

1. Navigate to entra.microsoft.com → Manage → Custom domain names 2. Click "Add custom domain" 3. Enter domain name (e.g., contoso.com) 4. View DNS verification record (TXT): Name and Value 5. Go to your DNS provider (GoDaddy, Cloudflare, etc.) 6. Add TXT record with exact name and value from step 4 7. Return to Entra ID, click "Verify" 8. Once verified, optionally set as "Primary domain" 9. For Exchange Online email: - Go to Exchange admin center → Mail flow → Connectors - Add MX record to DNS provider - Configure SPF and DKIM in Exchange admin center 10. Test: Send email to new user@contoso.com, verify delivery

Docs: https://learn.microsoft.com/en-us/entra/fundamentals/add-custom-domain https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains

Explanation

License management assigns Microsoft 365, Microsoft Entra ID P2, and other Microsoft service subscriptions to users and groups. Licenses enable specific features (Teams, advanced MFA, Intune management, Power BI). Group-based licensing automates license assignment; per-user assignment is manual. Usage location must be set before license assignment.

Think of it as: Software keys — each license unlocks specific service capabilities; assign licenses to grant users access.

Key Mechanics: - Usage location (country) must be set before license assignment (required for compliance) - Licenses assigned directly to user or via group membership (group-based = preferred) - License SKUs include all dependent services (e.g., Microsoft 365 E5 includes Teams, Outlook, etc.) - Service plans within SKUs can be disabled per user (e.g., disable Teams within E5) - Assumption trap: "License = service activated" — service must also be provisioned and user must have permission

Examples

Example 1 — [Success] Group-based licensing with service plan disablement Admin creates "Sales Team" group, assigns Microsoft 365 E5 licenses to group. All 200 sales users automatically get E5 (Teams, Exchange, SharePoint, Power BI). Admin disables Power BI license (service plan) for Sales to reduce costs; Sales still gets Teams and Exchange. Users don't need individual license management.

Example 2 — [Blocked] License assigned without usage location Admin creates user john@company.com and assigns Microsoft 365 E3 license. Assignment fails with error "Usage Location must be set." Root cause: License assignment requires usage location (for tax and compliance purposes). Admin must set usage location first.

Key Mechanisms

- Core function: License management assigns Microsoft 365, Microsoft Entra ID P2, and other Microsoft service subscriptions to users and groups. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Group-based licensing with service plan disablement - Decision clue: Industry: Manufacturing (Cost Optimization)

Review Path

Steps — Entra Admin Center: Licenses

1. Navigate to entra.microsoft.com → Identity → Users → All users 2. Select user → Licenses 3. Set "Usage Location" if not already set (required first step) 4. Click "Assignments" → Add licenses 5. Select license SKU (Microsoft 365 E5, E3, etc.) 6. Optionally disable specific service plans (Teams, Power BI, etc.) if not needed 7. Click Assign 8. For group-based licensing: - Create group: Groups → New group - Add members to group - Go to group → Licenses → Assign licenses - Members automatically receive licenses 9. Monitor: Licensing dashboard shows usage and remaining licenses 10. Export license report for cost tracking

Docs: https://learn.microsoft.com/en-us/entra/fundamentals/licensing-assign-licenses https://learn.microsoft.com/en-us/entra/fundamentals/licensing-group-assign

Explanation

Bulk operations perform large-scale user management tasks using CSV files. Supported operations include bulk user creation (onboarding), bulk updates (department changes), bulk deletion (offboarding), and bulk guest invitations. Each operation requires a correctly formatted CSV template with required fields. Operations are tracked in audit logs for compliance.

Think of it as: Batch processing — instead of creating 1,000 users one-at-a-time, upload a CSV with all 1,000 rows and Entra ID processes them in parallel.

Key Mechanics: - Download CSV template from Azure portal with required columns - Populate columns: DisplayName, UserPrincipalName, Department, Title, Manager, etc. - Required: UserPrincipalName and initial password (for create) - CSV encoding: UTF-8 (prevents special character corruption) - Max file size: 1GB (typically 10,000+ rows per file) - Assumption trap: "Bulk = instant completion" — large operations may take hours; async processing is not real-time

Examples

Example 1 — [Success] Bulk create for fall semester University downloads bulk create template, populates 5,000 new student rows (name, email, department), uploads CSV. Entra ID processes all 5,000 students within 30 minutes. All students can sign in to Microsoft 365 on day 1. Bulk operation audit log tracks all 5,000 creates.

Example 2 — [Blocked] Bulk operation fails due to CSV format Admin attempts bulk create with column headers in Spanish, data in mixed case (Name instead of DisplayName), and missing UserPrincipalName column. Bulk operation is rejected. Root cause: CSV column headers must exactly match template (case-sensitive), and all required fields must be present.

Key Mechanisms

- Core function: Bulk operations perform large-scale user management tasks using CSV files. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Bulk create for fall semester - Decision clue: Industry: Education (Seasonal Onboarding)

Review Path

Steps — Entra Admin Center: Bulk operations

1. Navigate to entra.microsoft.com → Identity → Users → Bulk operations 2. Select operation type (Create, Update, Delete, or Invite) 3. Download CSV template matching your operation 4. Open template in Excel or text editor 5. Populate required columns (DisplayName, UserPrincipalName, etc.) 6. Validate: No duplicate emails, required fields filled, UTF-8 encoding 7. Upload CSV file 8. Monitor job status in "Recent jobs" (may take 30 minutes to hours) 9. Review results: Download error file to see any failures 10. For failures, fix rows and re-upload (does not re-process successful rows)

Docs: https://learn.microsoft.com/en-us/entra/identity/users/users-bulk-add https://learn.microsoft.com/en-us/entra/identity/users/users-bulk-delete https://learn.microsoft.com/en-us/entra/identity/users/users-bulk-download

Explanation

User identities in Entra ID represent distinct principals that authenticate and access resources. Types include internal users (employees), external/guest users (partners), and service accounts (apps). Each identity has attributes (name, email, licenses, groups, authentication methods) and a unique Object ID. Lifecycle spans creation (onboard), modification, and deletion (offboard).

Think of it as: ID card types — internal employees have full-access cards, contractors have limited-access cards, and apps have automated service cards.

Key Mechanics: - Internal users: Cloud-only (created in Entra ID) or synced from on-premises AD - External users: B2B guests invited via email, authenticate in their home tenant, can access shared resources - Service accounts: Non-human identities (apps, scripts) using client credentials or managed identities - Assumption trap: "Guest users = employees with limited access" — guests maintain home tenant identity; they're not employees

Examples

Example 1 — [Success] Mixed identity types with proper access Company has: 5,000 internal employees (cloud synced from on-prem AD), 200 B2B guests from partner companies (can access specific Teams channel), 50 service accounts (CI/CD pipelines, Azure Functions). Each identity type has appropriate permissions per their role.

Example 2 — [Blocked] Guest invited but cannot access shared resources Admin invites external vendor john@vendor.com as guest, but john receives email saying "You don't have permission." Root cause: Guest was invited but not added to the group that owns the shared resource (SharePoint site or Teams). Guest invitations don't automatically grant access; explicit group membership is required.

Key Mechanisms

- Core function: User identities in Entra ID represent distinct principals that authenticate and access resources. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Mixed identity types with proper access - Decision clue: Industry: Consulting (Multi-tenant Collaboration)

Review Path

Steps — Entra Admin Center: Users

INTERNAL USER (Create): 1. Navigate to entra.microsoft.com → Identity → Users → All users 2. Click "New user" or "Create user" 3. Fill in: Display name, User principal name (email), Password (auto-generated or custom) 4. Assign licenses if needed 5. Add to groups for resource access 6. Click Create

GUEST USER (Invite): 1. Go to Users → All users → Invite guest user 2. Enter guest email (e.g., partner@external.com) 3. Add to group or Teams for resource access 4. Guest receives invitation email; must accept to create account 5. Guest signs in with home tenant credentials

SERVICE ACCOUNT (Via App Registration): 1. Go to Identity → Applications → App registrations 2. Register new application (see App Registrations section) 3. Create client secret 4. Assign roles via role assignment

Docs: https://learn.microsoft.com/en-us/entra/fundamentals/how-to-create-delete-users https://learn.microsoft.com/en-us/entra/external-id/b2b-quickstart-add-guest-users-portal https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

Explanation

Disabling user accounts blocks new sign-ins while preserving user data, settings, and permissions for potential re-enabling. Revoking sessions immediately invalidates all active authentication tokens, forcing re-authentication on all devices. These controls are essential for security incidents, employee termination, and temporary access suspension scenarios.

Think of it as: Lock vs. evict — disabling is like locking an employee out of the building (they can't enter, but their desk remains). Revoking sessions is like ejecting them from all rooms immediately (even if they have a key).

Key Mechanics: - Disable account: Prevents new sign-in attempts; existing sessions may continue until token expires (up to 1 hour) - Revoke sessions: Immediately invalidates all refresh tokens; forces re-login on all devices within minutes - Combined approach: Disable + revoke for maximum security during incident response - Assumption trap: "Disable = immediately signed out" — sessions persist until tokens expire; revoke is required for immediate logout

Examples

Example 1 — [Success] Employee departure, disable + revoke Employee resigns Friday. IT disables account (Block sign-in = ON) + revokes sessions (invalidates all tokens). Employee is immediately signed out from Teams, Outlook, SharePoint on all devices. Email is preserved for manager handoff. Monday, all access is gone.

Example 2 — [Blocked] Disable only, former employee still has Teams access Admin disables account for departing contractor but forgets to revoke sessions. Contractor's Teams client continues working because the local cached token is still valid for 1 hour. Contractor downloads customer data before token expires. Root cause: Disable alone doesn't immediately log out active sessions; revoke is required.

Key Mechanisms

- Core function: Disabling user accounts blocks new sign-ins while preserving user data, settings, and permissions for potential re-enabling. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Employee departure, disable + revoke - Decision clue: Industry: Healthcare (HIPAA Compliance)

Review Path

Steps — Entra Admin Center: User management

DISABLE ACCOUNT: 1. Navigate to entra.microsoft.com → Identity → Users → All users 2. Select user to disable 3. Go to Overview tab 4. Click "Block sign-in" toggle → ON 5. Confirm and save 6. User cannot sign in, but data is preserved

REVOKE SESSIONS: 1. In the user's profile → Devices tab 2. Click "Revoke sessions" → Confirm 3. All active tokens invalidated (takes 5-15 minutes to propagate) 4. User must re-authenticate on all devices

COMBINED APPROACH (Incident Response): 1. Click "Revoke sessions" (immediate logout) 2. Click "Block sign-in" (prevent re-login) 3. Review group memberships → Remove from sensitive groups if necessary 4. Transfer user's email/OneDrive to manager (if data needed)

PowerShell (for automation): ```powershell # Disable account Set-MgUser -UserId "john@company.com" -AccountEnabled:$false

# Revoke all sessions Revoke-MgUserSignInSession -UserId "john@company.com"

# Bulk offboarding $offboardUsers = Import-Csv "offboard.csv" foreach ($user in $offboardUsers) { Revoke-MgUserSignInSession -UserId $user.UserPrincipalName Set-MgUser -UserId $user.UserPrincipalName -AccountEnabled:$false } ```

Docs: https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access https://learn.microsoft.com/en-us/entra/identity/users/users-delete-permanently

Explanation

Groups are collections of users or devices used for permission management and collaboration. Security groups assign permissions to resources. Microsoft 365 groups enable team collaboration (Teams, SharePoint, shared mailbox). Dynamic groups use rules to auto-populate members based on attributes. Group membership can be assigned (manual) or dynamic (rule-based).

Think of it as: Team rosters — assign individual permissions would be like listing each player, while group assignment is like "Sales Team gets access to Sales SharePoint site."

Key Mechanics: - Security groups: Resource permissions, policy assignments - Microsoft 365 groups: Collaboration (Teams, SharePoint, shared mailbox) - Dynamic groups: Auto-populate based on user attributes (department, job title, location) - Nested groups: Groups containing other groups (supports multi-level organization) - Assumption trap: "Group = static list" — dynamic groups automatically add/remove based on attributes

Examples

Example 1 — [Success] Dynamic group auto-manages team membership IT creates dynamic group "Sales_Department" with rule: department -eq "Sales". Whenever HR updates a user's department to "Sales" in on-premises AD, they're automatically added to the group. When they switch departments, they're removed. No manual group management needed.

Example 2 — [Blocked] Static group causes access confusion Admin manually manages "Project_Alpha" group, adding/removing members by hand. Team member transfers to new project but admin forgets to remove them from old group. User still has access to old project's confidential data. Root cause: Manual group management is error-prone; dynamic groups would have auto-removed them.

Key Mechanisms

- Core function: Groups are collections of users or devices used for permission management and collaboration. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Dynamic group auto-manages team membership - Decision clue: Industry: Technology (Matrix Organization)

Review Path

Steps — Entra Admin Center: Groups

CREATE SECURITY GROUP (Assigned): 1. Navigate to entra.microsoft.com → Identity → Groups → All groups 2. Click "New group" 3. Group type: Security 4. Group name: "Sales_Team" 5. Membership type: Assigned 6. Click Create 7. Add members manually: Members → Add members

CREATE MICROSOFT 365 GROUP: 1. New group → Group type: Microsoft 365 2. Name, description, owners 3. Privacy: Public (anyone can join) or Private (admin approval) 4. Click Create (auto-creates Teams channel, SharePoint site)

CREATE DYNAMIC GROUP: 1. New group → Group type: Security 2. Membership type: Dynamic User or Dynamic Device 3. Click "Add dynamic query" 4. Set rule: Property -eq Value (e.g., department -eq "Sales") 5. Test rule on sample users (to verify before saving) 6. Save

Docs: https://learn.microsoft.com/en-us/entra/identity/users/groups-create-rule https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership-rules

Explanation

Device identities represent computers, phones, and tablets connecting to organizational resources. Devices can be Entra registered (personal devices, user-level only), Entra joined (corporate devices, device-level), or hybrid joined (on-premises AD + Entra). Device compliance policies enforce requirements (encryption, firewall enabled, antivirus installed). Stale devices are automatically cleaned up after inactivity.

Think of it as: Device passports — registered devices get basic access, joined devices get full corporate treatment, hybrid devices work in both on-premises and cloud.

Key Mechanics: - Entra registered: BYOD personal devices, MAM-only (mobile app management), no device-level policies - Entra joined: Corporate Windows/Mac devices, full Intune MDM, Conditional Access device-based rules - Hybrid joined: Domain-joined devices also registered in Entra ID, supports on-premises + cloud access - Device compliance: Policies require encryption, firewall, antivirus; non-compliant devices can be blocked - Assumption trap: "Device registration = enrollment" — registration is optional BYOD, enrollment is mandatory corporate

Examples

Example 1 — [Success] Hybrid device compliance enforcement Company hybrid-joins 500 domain workstations. Intune compliance policy requires encryption (BitLocker) and Windows Defender. Compliant devices get Conditional Access approval for Microsoft 365. Non-compliant devices (encryption disabled) are blocked from accessing Exchange Online. Users enable encryption to regain access.

Example 2 — [Blocked] Personal device tries to access corporate resources Employee registers personal iPad (Entra registered) and tries to access SharePoint corporate files. Conditional Access policy requires "device managed by Intune." iPad is registered but not managed (no MDM profile installed). Access blocked. Employee must install Intune Company Portal app to be managed.

Key Mechanisms

- Core function: Device identities represent computers, phones, and tablets connecting to organizational resources. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hybrid device compliance enforcement - Decision clue: Industry: Finance (Compliance + Security)

Review Path

Steps — Entra Admin Center & Intune

VIEW DEVICES: 1. Navigate to entra.microsoft.com → Identity → Devices → All devices 2. Filter by device type, join type, compliance status 3. Select device to see details, users, group memberships

REGISTER PERSONAL DEVICE (BYOD): 1. On personal device: Settings → Accounts → Access work or school 2. Click "Connect" → Enter work email 3. Complete MFA/authentication 4. Accept device management (or decline for limited access) 5. Device appears in Entra ID as "Microsoft Entra registered"

ENTRA JOIN CORPORATE DEVICE: 1. New device at OOBE: "Set up for organization" → Sign in with work account 2. Or existing device: Settings → Accounts → Access work or school → Join 3. Device gets corporate certificates, Intune policies 4. Appears as "Microsoft Entra joined"

CONFIGURE DEVICE COMPLIANCE (Intune): 1. Navigate to intune.microsoft.com → Devices → Compliance policies 2. Create policy → Select platform (Windows, iOS, Android) 3. Configure requirements: Encryption, firewall, antivirus, minimum OS version 4. Assign to device group 5. Non-compliant devices can be blocked via Conditional Access

PowerShell: ```powershell # Get all devices Get-MgDevice | Format-Table DisplayName, IsCompliant

# Delete stale devices (>90 days inactive) $staleDate = (Get-Date).AddDays(-90) Get-MgDevice -All | Where-Object {$_.ApproximateLastSignInDateTime -lt $staleDate} | Remove-MgDevice ```

Docs: https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started

Explanation

External collaboration settings control B2B guest invitations, domain allowlists/blocklists, guest user permissions, and self-service sign-up capabilities. Settings determine who can invite guests (admins only vs. all users), which external domains are allowed, and what directory access guests have. These settings balance security with business collaboration needs.

Think of it as: Visitor control policies — who can bring visitors, which visitors are allowed, what areas they can access.

Key Mechanics: - Invitation settings: Restrict to admins, enable for guest inviters, or allow all users - Domain allow/deny lists: Whitelist trusted partners, blacklist competitors or risky domains - Guest permissions: Full directory access (same as members) vs. limited (own profile only) - Self-service sign-up: Enable external users to sign up without invitation - Assumption trap: "Guest access = no security risk" — unrestricted guest invitations can leak company data

Examples

Example 1 — [Success] Restricted guest access with domain allowlist Company restricts guest invitations to admins only. Only users from trusted partner domains (salesforce.com, acme.com) can be invited. Invited guests have limited directory access (cannot see other company employees). Result: Secure B2B collaboration without data leakage.

Example 2 — [Blocked] Unrestricted invitations, competitor employee gains access Default settings allow all users to invite anyone. Employee invites "john@competitor.com" thinking he's a partner. Competitor employee now has full directory access, sees list of all 5,000 company employees and projects. HR cannot audit who invited him. Root cause: Permissive guest settings enabled unauthorized access.

Key Mechanisms

- Core function: External collaboration settings control B2B guest invitations, domain allowlists/blocklists, guest user permissions, and self-service sign-up capabilities. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Restricted guest access with domain allowlist - Decision clue: Industry: Consulting (Controlled Partner Access)

Review Path

Steps — Entra Admin Center: External collaboration

1. Navigate to entra.microsoft.com → External identities → External collaboration settings 2. Configure "Guest invitation settings": - "Guest can invite": Admins only / Guests + Admins / All users 3. Configure "Guest user access restrictions": - "Guest users have limited access": Limited / Same as members 4. Configure "Collaboration restrictions": - "Allowlist domains": Add trusted partner domains (partner1.com, partner2.com) - "Blocklist domains": Add competitor/risky domains 5. Optional: Enable "Self-service sign-up" for external partners 6. Save and test by attempting external invitation

Docs: https://learn.microsoft.com/en-us/entra/external-id/external-collaboration-settings-configure

Explanation

Cross-tenant access settings control how users and applications across different Entra ID tenants can collaborate. Settings include B2B collaboration (guest invitations between tenants), B2B direct connect (Teams shared channels without guest accounts), and cross-tenant synchronization. Default settings apply to all external organizations; specific settings override defaults for trusted partners.

Think of it as: Inter-company policies — decide which other companies' employees can access your resources and under what conditions.

Key Mechanics: - Default settings: Apply to all external organizations unless overridden - Organization-specific settings: Configure trust for particular partner tenants - B2B collaboration: Guest users invited from external tenant - B2B direct connect: Seamless Teams collaboration without guest account creation - Assumption trap: "Cross-tenant access = automatically secure" — requires explicit allow for each partner

Examples

Example 1 — [Success] Cross-tenant sync for merged companies Contoso and Fabrikam merger requires synced users. Cross-tenant sync configured: Contoso users automatically provisioned in Fabrikam tenant with appropriate groups. Users sign in with home tenant credentials but access both tenants. No manual guest management needed.

Example 2 — [Blocked] Outbound block prevents partner collaboration Company blocks all outbound B2B collaboration (default policy). Partner invites company employees for Teams collaboration. Invitation fails because outbound access is blocked. Root cause: Cross-tenant default settings block all external organizations; partner must be explicitly allowed.

Key Mechanisms

- Core function: Cross-tenant access settings control how users and applications across different Entra ID tenants can collaborate. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Cross-tenant sync for merged companies - Decision clue: Industry: Mergers & Acquisitions (Integration)

Review Path

Steps — Entra Admin Center: Cross-tenant access

1. Navigate to entra.microsoft.com → External identities → Cross-tenant access settings 2. Configure default inbound/outbound settings: - "Inbound access from external organizations": Allow B2B Collab, Direct Connect - "Outbound access to external organizations": Allow same 3. For trusted partners, create organization-specific override: - Click "Add organization" → Enter partner tenant ID or name - Configure partner-specific B2B/Direct Connect/Sync settings 4. Test: Attempt to invite external user or join shared Teams channel 5. Monitor: Activity log shows cross-tenant access attempts

Docs: https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration

Explanation

Zero Trust is a security framework assuming no implicit trust — every access request must be verified explicitly regardless of source. Core principles are: verify identity + device + risk, grant least privilege access, and assume breach (minimize lateral movement). Implementation requires strong authentication, device compliance, conditional access policies, and data protection across all access layers.

Think of it as: Always-locked doors — every person entering must show ID and credentials, even employees; no "trusted" networks exist.

Key Mechanics: - Verify explicitly: Strong auth (MFA), device compliance, risk assessment - Least privilege: Just-in-time (JIT) access for elevated roles; minimal standing permissions - Assume breach: Minimize blast radius through segmentation, encryption, and monitoring - Continuous verification: Re-evaluate every access attempt, not one-time authentication - Implementation layers: Identity, Device, Network, Application, Data

Examples

Example 1 — [Success] Zero Trust implementation blocks breach Company implements Zero Trust: MFA required, device must be compliant, Conditional Access blocks high-risk sign-ins. Attacker steals employee password but cannot sign in (MFA blocks). Attacker compromises employee device but device is marked non-compliant, preventing cloud access. Result: Attack contained, data protected.

Example 2 — [Blocked] Traditional perimeter model, insider threat succeeds Company has corporate firewall but no MFA, trusts all internal network traffic, minimal device checks. Malicious insider connects to corporate network, accesses shared drive containing customer data, exfiltrates undetected. Root cause: No verification of insider, no encryption, no behavioral monitoring within perimeter.

Key Mechanisms

- Core function: Zero Trust is a security framework assuming no implicit trust — every access request must be verified explicitly regardless of source. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Zero Trust implementation blocks breach - Decision clue: Industry: Pharmaceutical (Data Protection)

Review Path

Steps — Entra Admin Center: Zero Trust Implementation

1. Enable MFA: - Navigate to Security → Authentication methods - Enable Microsoft Authenticator, FIDO2, Windows Hello - Require MFA for all users (or high-risk groups first)

2. Enable Conditional Access: - Security → Conditional Access → Create policy - Require MFA for high-risk sign-ins - Block legacy authentication (non-modern auth clients) - Require compliant devices

3. Enable Identity Protection: - Security → Identity Protection → User risk policy - Set to "Require password change" for high-risk users - Monitor risk detections via activity log

4. Implement Device Compliance: - Intune → Devices → Compliance policies - Require encryption, firewall, antivirus - Block non-compliant devices from accessing cloud resources

5. Enable PIM for Privileged Roles: - Identity governance → PIM - Make admin roles time-limited and approval-required - Audit all admin actions

Docs: https://learn.microsoft.com/en-us/security/zero-trust/ https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview

Explanation

Authentication methods are the techniques users employ to verify identity. Methods range from passwords (weakest) to FIDO2 security keys and Windows Hello (strongest). Administrators can require specific methods, disable weaker ones, and track registration. Each method has trade-offs: strength vs. user experience vs. cost.

Think of it as: ID proof types — driver's license (password) is basic, passport (FIDO2) is secure, biometric (Windows Hello) is modern and user-friendly.

Key Mechanics: - Passwordless methods: FIDO2, Windows Hello, Microsoft Authenticator (most secure) - Password + MFA methods: Password + Microsoft Authenticator, SMS, phone call - Passwordless preferred: Eliminate password guessing and phishing - Assumption trap: "MFA = always secure" — SMS and phone calls (weakest MFA) are vulnerable to SIM swap attacks

Examples

Example 1 — [Success] Migration from passwords to passwordless Company disables basic SMS, enables FIDO2 and Microsoft Authenticator. Admins required to use FIDO2 keys. Regular users transition to Authenticator. Password attacks drop 80% because no passwords to steal/guess.

Example 2 — [Blocked] Weak MFA allows account takeover Company requires MFA but allows SMS as only option. Attacker performs SIM swap (tricks carrier into moving victim's phone number to attacker's SIM). Attacker receives SMS codes and signs in. Root cause: SMS MFA is vulnerable to SIM swap; stronger methods (FIDO2, Authenticator) required.

Key Mechanisms

- Core function: Authentication methods are the techniques users employ to verify identity. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Migration from passwords to passwordless - Decision clue: Industry: Finance (Regulatory Compliance)

Review Path

Steps — Entra Admin Center: Authentication methods

1. Navigate to entra.microsoft.com → Protection → Authentication methods → Policies 2. Enable required methods: - Click each method (FIDO2, Authenticator, SMS, etc.) - Set "State: Enabled" - Set "Include targets: All users" or select group - Set "Require registration: Yes" (if mandatory) 3. Configure registration requirements: - "Require registration": Users must register before using - "Registration enforcement timeout": Days before user is forced to register 4. Disable weaker methods (SMS, phone call) over time: - For privileged users immediately - For all users after 6-month transition period 5. Monitor adoption: - Protection → MFA → Users - View which methods users have registered 6. Test: Attempt sign-in with different authentication methods

Docs: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-azure-mfa

Explanation

Multi-factor authentication (MFA) requires two or more independent verification factors: something you know (password), something you have (phone/token), or something you are (biometric). MFA can be enforced through Conditional Access policies, security defaults, or per-user settings. It dramatically reduces account takeover risk by making compromised passwords alone insufficient for access.

Think of it as: Bank vault — password is the first lock, MFA is the second lock; attacker needs both to succeed.

Key Mechanics: - Security defaults: Basic MFA for all (managed identity accounts excluded) - Conditional Access: Smart MFA policies (require for high-risk, optional for low-risk) - Per-user MFA: Legacy method (one user at a time), not recommended - Challenge factors: Microsoft Authenticator, SMS, phone call, OATH tokens - Assumption trap: "MFA = fully secure" — weak MFA (SMS) is still vulnerable

Examples

Example 1 — [Success] Conditional Access MFA reduces friction Company enables Conditional Access: Low-risk sign-ins (office network, trusted device) = no MFA required (frictionless). High-risk sign-ins (new location, unmanaged device) = MFA required. Users get convenience + security.

Example 2 — [Blocked] MFA fatigue attack causes user to approve malicious request Company requires MFA on every single sign-in attempt. Attacker signs in 100 times, bombarding user with MFA prompts. User fatigue causes them to approve attacker's request. Root cause: Unconditional MFA + no rate limiting. Conditional Access (MFA only for risky attempts) is better.

Key Mechanisms

- Core function: Multi-factor authentication (MFA) requires two or more independent verification factors: something you know (password), something you have (phone/token), or something you are (biometric). - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Conditional Access MFA reduces friction - Decision clue: Industry: Healthcare (HIPAA Compliance)

Review Path

Steps — Entra Admin Center: MFA Configuration

ENABLE SECURITY DEFAULTS (Simple approach): 1. Navigate to entra.microsoft.com → Manage → Properties 2. Scroll to "Security defaults" section 3. Click "Enable security defaults" 4. Confirm: All users now require MFA registration 5. Note: Managed identities and service accounts are excluded

ENABLE CONDITIONAL ACCESS MFA (Recommended): 1. Go to Security → Conditional Access → Create policy 2. Conditions: - Users: All users (exclude emergency access) - Apps: All cloud apps - Risk: Sign-in risk = High/Medium 3. Controls: Grant → Require MFA 4. Set policy to Report-only initially (test before enforcement) 5. Monitor compliance before enabling

PER-USER MFA (Legacy, not recommended): 1. Navigate to Users → All users 2. Select user → Multi-factor authentication (legacy link) 3. Enable MFA per user individually 4. User must register methods via https://aka.ms/mfasetup

Monitor MFA Adoption: 1. Go to Report → Sign-ins 2. Filter by "MFA Status" to see enrollment rates 3. Target 90%+ adoption before enforcement

Docs: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-azure-mfa https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common

Explanation

Self-service password reset allows users to reset forgotten passwords without contacting helpdesk using pre-registered authentication methods. Methods include alternate email, mobile phone (SMS/call), or security questions. SSPR reduces IT support costs, improves user productivity, and can write-back new passwords to on-premises AD for hybrid scenarios.

Think of it as: Password reset ATM — users self-serve 24/7 without waiting for helpdesk.

Key Mechanics: - Registration: Users pre-register email/phone for identity verification - Verification: User answers pre-registered methods to prove identity - Reset: User creates new password meeting complexity policy - Write-back: On-premises AD password updated (optional, requires configuration) - Assumption trap: "SSPR = no security" — proper verification prevents unauthorized password resets

Examples

Example 1 — [Success] SSPR reduces helpdesk burden Company enables SSPR with 2-factor verification (email + SMS). Users forget password, reset via SSPR in 2 minutes. Helpdesk ticket eliminated. Company saves 500 hours/year in helpdesk labor.

Example 2 — [Blocked] SSPR without verification allows account takeover Admin enables SSPR with only security questions (what's your pet's name?). Attacker researches employee on social media, finds pet name, resets password. Root cause: Single weak factor; need 2-factor verification (email + phone).

Key Mechanisms

- Core function: Self-service password reset allows users to reset forgotten passwords without contacting helpdesk using pre-registered authentication methods. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] SSPR reduces helpdesk burden - Decision clue: Industry: Education (Scale)

Review Path

Steps — Entra Admin Center: SSPR

1. Navigate to entra.microsoft.com → Identity → Password reset → Properties 2. Set "Self-service password reset enabled": Yes (for all or selected users) 3. Go to Password reset → Authentication methods 4. Configure allowed methods: - "Email address": Yes (for alternate email) - "Mobile phone": Yes (for SMS) - "Phone": Yes (for voice call, optional) - "Security questions": Yes (optional) 5. Set "Number of methods required to reset": 2 (recommended) 6. Go to Password reset → Registration - Set "Require users to register": Yes - Grace period: Users have 7 days to register before required 7. Optional - Enable password writeback (on-premises AD): - Microsoft Entra Connect → Configure → Configure device options → Enable password writeback 8. Test: Visit aka.ms/sspr, attempt password reset

Docs: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr https://learn.microsoft.com/en-us/entra/identity/authentication/howto-sspr-writeback

Explanation

Passwordless authentication eliminates passwords entirely, using stronger factors like biometrics, hardware tokens, or cryptographic keys. Methods include Windows Hello (face/fingerprint), FIDO2 security keys (USB/NFC), and Microsoft Authenticator app (phone approval + biometric). Passwordless approaches improve both security (no guessing/phishing) and user experience (faster, more convenient).

Think of it as: Modern ID verification — fingerprint or face (passwordless) is faster and more secure than memorizing passwords.

Key Mechanics: - Windows Hello: Local biometric/PIN, device-bound (cannot remote attack) - FIDO2 keys: Portable hardware tokens, phishing-resistant (website URL checked) - Authenticator app: Phone-based, location-aware, app shows context - Assumption trap: "Passwordless = instant adoption" — users need training and fallback methods during transition

Examples

Example 1 — [Success] Phased passwordless rollout Company starts admins-only passwordless (FIDO2 keys), 6 months later enables for all users (Authenticator + Windows Hello choices). After 12 months, passwords disabled for regular users. Phased approach allows support for late adopters.

Example 2 — [Blocked] Mandatory passwordless without fallback causes lockout Company mandates FIDO2-only, no fallback methods. User loses USB key. User is completely locked out; must wait for IT. Root cause: Passwordless should have fallback (backup security key, Authenticator, etc.) for outage scenarios.

Key Mechanisms

- Core function: Passwordless authentication eliminates passwords entirely, using stronger factors like biometrics, hardware tokens, or cryptographic keys. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Phased passwordless rollout - Decision clue: Industry: Technology (Security-first)

Review Path

Steps — Entra Admin Center: Passwordless

1. Enable Passwordless Methods: - Navigate to Protection → Authentication methods → Policies - Enable "FIDO2 Security Key": * State: Enabled * Include targets: All users (or admins first for pilot) - Enable "Windows Hello for Business": * For group policy control (Windows enterprise only) - Enable "Microsoft Authenticator": * Feature: Passwordless phone sign-in * State: Enabled

2. Register Authentication Methods: - Users visit https://aka.ms/mfasetup - Register FIDO2 key, Windows Hello, or Authenticator - Test authentication with each method

3. Conditional Access for Passwordless Encouragement: - Create policy: Allow password + MFA OR passwordless methods - Gradually phase out password option over time - Monitor adoption via sign-in logs

4. Manage Fallback Access: - Enable Temporary Access Pass (TAP) for locked-out users - TAP is 15-min emergency code, single-use

Docs: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-deployment

Explanation

Workload identities are non-human identities for applications, services, scripts, and containers to authenticate and access resources. Types include service principals (registered apps with credentials), managed identities (automatic credential management), and application registrations (OAuth-enabled apps). Workload identities enable secure automation without hardcoded credentials in code or config files.

Think of it as: Digital service accounts — instead of a person signing in, an automated system uses a workload identity to prove it should be trusted.

Key Mechanics: - Service principal: Created via app registration, uses client secret or certificate - Managed identity: Automatic credential rotation, no credential management needed - System-assigned: Tied to Azure resource lifecycle (created/deleted with resource) - User-assigned: Standalone, reusable across multiple resources - Assumption trap: "Service account = credentials in code" — modern approach uses managed identity or secret storage (Key Vault)

Examples

Example 1 — [Success] Managed identity eliminates credential storage Azure Function uses system-assigned managed identity to access Key Vault secrets. No credentials in code or config. If Function is deleted, identity is deleted. Secrets cannot be leaked in code review because no secrets in code.

Example 2 — [Blocked] Service principal credentials hardcoded in script DevOps engineer hardcodes service principal client secret in deployment script. Secret is committed to GitHub. Attacker finds it, signs in as service principal, accesses all Azure resources. Root cause: Credentials in code; should use managed identity or secret storage (Key Vault) instead.

Key Mechanisms

- Core function: Workload identities are non-human identities for applications, services, scripts, and containers to authenticate and access resources. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Managed identity eliminates credential storage - Decision clue: Industry: FinTech (CI/CD Automation)

Review Path

Steps — Entra Admin Center & Azure: Workload identities

CREATE APP REGISTRATION (Service Principal): 1. Navigate to entra.microsoft.com → Identity → App registrations 2. Click "New registration" 3. Name: "CI-CD-ServicePrincipal" 4. Account type: Single tenant (for internal apps) 5. Create 6. Go to "Certificates & secrets" → "New client secret" 7. Copy secret value immediately (not shown again)

CREATE SYSTEM-ASSIGNED MANAGED IDENTITY: 1. Create Azure resource (Function, VM, App Service) 2. Resource → Settings → Identity 3. System assigned → Status: On 4. Save (identity auto-created)

CREATE USER-ASSIGNED MANAGED IDENTITY: 1. Azure portal → Create → User Assigned Managed Identity 2. Name: "shared-app-identity" 3. Create 4. Assign to resources: App Service → Identity → User assigned → Add

ASSIGN PERMISSIONS: 1. Go to resource (Key Vault, Storage Account) 2. Access Control (IAM) → Add role assignment 3. Role: Select least-privilege role (Reader, Contributor, Data Reader) 4. Assign to: Managed identity or service principal 5. Scope: Specific resource (not entire subscription)

Docs: https://learn.microsoft.com/en-us/entra/identity-platform/workload-identity-federation https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

Explanation

Application registrations create identities for applications in Entra ID, enabling them to authenticate users and access protected resources. Registrations define application permissions (what the app can do), delegated permissions (what users can authorize), authentication flows (OAuth code, PKCE, client credentials), and redirect URIs. Each registration creates a service principal in the tenant.

Think of it as: Application passport — the registration is the passport; the service principal is the customs office validating the passport.

Key Mechanics: - Redirect URI: Where OAuth provider sends user after login (must be HTTPS in production) - Permissions: Delegated (user context) vs. application (app-only, needs admin consent) - OAuth flows: Authorization code (web), PKCE (mobile/SPA), client credentials (service-to-service) - Admin consent: Required for application permissions; delegated can use user consent - Assumption trap: "App registration = auto-grants access" — registration is configuration; permissions must be explicitly granted

Examples

Example 1 — [Success] Multi-tenant SaaS app registration Consulting firm registers SaaS app as multi-tenant. Office 365 Teams add-in uses delegated User.Read permission (team sees Teams contact picker works). Other organizations can consent to install the add-in. App can be installed in 100 customer tenants using single registration.

Example 2 — [Blocked] Redirect URI mismatch causes OAuth failure Developer registers web app with redirect URI "https://localhost:3000/auth". During deployment to production, app is at https://app.contoso.com/auth. OAuth fails because redirect URI doesn't match registration. Root cause: Registration redirect URIs must exactly match production URLs.

Key Mechanisms

- Core function: Application registrations create identities for applications in Entra ID, enabling them to authenticate users and access protected resources. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Multi-tenant SaaS app registration - Decision clue: Industry: SaaS (Multi-tenant)

Review Path

Steps — Entra Admin Center: App Registration

1. Navigate to entra.microsoft.com → Identity → App registrations 2. Click "New registration" 3. Enter application name 4. Select account type: - Single tenant: Internal use only - Multi-tenant: Installable in other organizations 5. Configure Redirect URI: https://yourdomain.com/auth/callback 6. Click Register 7. Copy Application (client) ID and Tenant ID

Configure Credentials: 1. Go to Certificates & secrets 2. Click "New client secret" 3. Add description and expiration (max 2 years) 4. Copy secret value (displayed once only)

Configure Permissions: 1. Go to API permissions 2. Click "Add a permission" 3. Select Microsoft Graph 4. Choose Delegated or Application permissions 5. Search and select required permissions (User.Read, Mail.Send, etc.) 6. Click "Grant admin consent" if application permissions

Configure Advanced: 1. Go to Authentication 2. Set implicit grant if needed (ID + access tokens) 3. Configure token lifetimes (default 1 hour)

Docs: https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app https://learn.microsoft.com/en-us/graph/auth/auth-concepts

Explanation

Managed identities provide Azure services with automatically managed identities in Entra ID, eliminating credential management. System-assigned identities are tied to individual resources; user-assigned identities are standalone and reusable. Azure automatically manages credential rotation, token generation, and lifecycle, reducing operational overhead and security risk.

Think of it as: Automatic employee ID — your Azure resource automatically gets an ID without you managing paperwork; ID is auto-retired when resource is deleted.

Key Mechanics: - System-assigned: Created with resource, deleted with resource, one per resource - User-assigned: Created independently, can be shared across multiple resources - Token management: Automatic refresh tokens, no credential storage needed - IMDS: Instance Metadata Service provides tokens to applications on the resource - Assumption trap: "Managed identity = no security" — identity has same role-based permissions as any other principal

Examples

Example 1 — [Success] App Service with managed identity accesses Key Vault App Service enabled with system-assigned managed identity. App code: credential = ManagedIdentityCredential(); client = SecretClient(vault_url, credential); secret = client.GetSecret(). No secrets in code, no credential management, automatic token rotation.

Example 2 — [Blocked] Manual credential management causes secret sprawl Developer hardcodes database password in App Service config. Password visible in Azure portal, checked into GitHub. Attacker finds it. Multiple apps hard-coded same password (secret sprawl). Root cause: Should use managed identity to access Key Vault for secrets, not hardcode.

Key Mechanisms

- Core function: Managed identities provide Azure services with automatically managed identities in Entra ID, eliminating credential management. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] App Service with managed identity accesses Key Vault - Decision clue: Industry: Microservices (Container Apps)

Review Path

Steps — Azure Portal: Managed Identity

ENABLE SYSTEM-ASSIGNED: 1. Navigate to resource (Function, App Service, VM) 2. Go to Settings → Identity 3. System assigned tab → Status: On 4. Save (identity auto-created) 5. Copy Object ID (used for role assignments)

CREATE USER-ASSIGNED IDENTITY: 1. Azure portal → Create resource → User Assigned Managed Identity 2. Name: "shared-identity" 3. Region: Same as resources using it 4. Create

ASSIGN ROLE TO IDENTITY: 1. Go to target resource (Key Vault, Storage Account, Database) 2. Access Control (IAM) → Add role assignment 3. Role: Select appropriate role (Reader, Contributor, Data Owner) 4. Assign to: Managed identity 5. Select identity (system-assigned or user-assigned)

CONFIGURE APP TO USE MANAGED IDENTITY: PowerShell example: ```powershell # Get managed identity token $token = (Invoke-RestMethod -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -Headers @{Metadata="true"}).access_token

# Use token to access Key Vault $secret = Invoke-RestMethod -Uri "https://myvault.vault.azure.net/secrets/mysecret?api-version=7.0" -Headers @{Authorization="Bearer $token"} ```

Docs: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-sign-in

Explanation

User risk policies automatically respond to accounts showing signs of compromise based on threat intelligence. Risk is detected through leaked credentials (dark web), impossible travel, sign-ins from anonymous networks, and malware-infected devices. Policies can block access, require password change, or require MFA registration. High-risk users are flagged for investigation.

Think of it as: Fraud detection — suspicious account activity automatically triggers protective actions (like a credit card company blocking suspicious transactions).

Key Mechanics: - Risk detection: Continuous analysis of user activity and threat intelligence - Risk levels: Low, Medium, High (admins set policy thresholds) - Policy actions: Block, allow + MFA, allow + password change, allow + monitoring - Assumption trap: "Risk policies = always accurate" — false positives occur; proper triage is needed

Examples

Example 1 — [Success] User risk policy detects credential leak Microsoft detects user password on dark web (leaked from external breach). Entra ID marks user as high-risk. User risk policy triggers: Block sign-in. User calls IT, admin verifies legitimacy, resets password. User can sign in again.

Example 2 — [Blocked] No user risk policy, leak goes undetected User password leaked in external data breach. No Entra ID user risk policy configured. Attacker slowly accesses company data over weeks. Root cause: User risk policy would have detected compromised credentials and blocked access.

Key Mechanisms

- Core function: User risk policies automatically respond to accounts showing signs of compromise based on threat intelligence. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] User risk policy detects credential leak - Decision clue: Industry: Financial Services (Compliance)

Review Path

Steps — Entra Admin Center: User Risk Policy

1. Navigate to entra.microsoft.com → Security → Identity Protection → User risk policy 2. Configure assignment: - Users: Include all (exclude emergency access) - Conditions: Risk level = High (or High + Medium for stricter) 3. Configure controls: - Access: Allow / Block - If Allow: Require password change (recommended) - If Allow: Require MFA (alternative) 4. Set policy to "Report-only" initially (test before enforcement) 5. Monitor: Go to Risky users → review flagged accounts 6. Once tested, set policy to "Enabled"

Monitor Risk Detections: 1. Go to Security → Identity Protection → Risk detections 2. View all detected risks, user details, location, device 3. Filter by risk type (leaked credentials, impossible travel, etc.) 4. Manually dismiss or confirm risk (for false positives)

Docs: https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies

Explanation

Sign-in risk policies evaluate each authentication attempt in real-time and enforce controls based on risk assessment. Risk factors include location (unfamiliar country), device (non-compliant), network (anonymous IP), and behavioral anomalies. Policies can block high-risk sign-ins, require MFA, or allow with monitoring. Sign-in risk is assessed per-request, not per-user.

Think of it as: ATM fraud detection — unusual ATM withdrawal triggers extra verification (PIN re-entry) or blocks transaction.

Key Mechanics: - Real-time evaluation: Each sign-in attempt assessed independently - Risk factors: Location, device, network, time patterns combined - Policy actions: Block, require MFA, allow + monitoring - Session controls: Can require device compliance after risky sign-in - Assumption trap: "Sign-in risk policy = blocks all high-risk logins" — can be configured for MFA instead of block

Examples

Example 1 — [Success] Sign-in risk policy blocks brute-force attack Attacker attempts 100 sign-in attempts from same IP. Each attempt evaluated for risk. After 10 failed attempts, sign-in risk increases. Policy blocks. Attacker cannot proceed without MFA that user doesn't approve.

Example 2 — [Blocked] No sign-in risk policy, account takeover succeeds Legitimate employee on business trip signs in from new country (high risk). No policy configured to challenge them. Attacker also learns password, signs in from same new country. Attacker assumed legitimate due to same risk profile. Root cause: Sign-in risk policy should require MFA for new locations (catches attacker using known credentials).

Key Mechanisms

- Core function: Sign-in risk policies evaluate each authentication attempt in real-time and enforce controls based on risk assessment. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Sign-in risk policy blocks brute-force attack - Decision clue: Industry: E-commerce (Account Security)

Review Path

Steps — Entra Admin Center: Sign-in Risk Policy

1. Navigate to entra.microsoft.com → Security → Identity Protection → Sign-in risk policy 2. Configure conditions: - Risk level: High / High and medium (choose strictness) - Users: All users (exclude emergency access) - Apps: All cloud apps (or specific apps) 3. Configure controls: - Access: Allow or Block - If Allow: Require MFA (recommended) - If Allow: Require device compliance (optional) 4. Set to "Report-only" initially (test before enforcement) 5. Monitor: Sign-in logs show blocked attempts, MFA challenges

Fine-tune Policy: 1. Go to Security → Conditional Access → Create policy 2. Conditions: Sign-in risk = High 3. Controls: Require MFA + compliant device 4. Gradual enforcement: Start Report-only → Enable after 2 weeks

Docs: https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies

Explanation

Entitlement management automates access request workflows, provisioning, access reviews, and expiration for groups, applications, and SharePoint sites. Access packages bundle resources with policies (who can request, approval workflow, duration, review schedule). Organizations reduce manual access management while enforcing governance and compliance.

Think of it as: Automated hiring onboarding — instead of manually granting each new hire access to email, Teams, SharePoint, create an "onboarding access package" that auto-grants everything with one click.

Key Mechanics: - Catalogs: Collections of resources (groups, apps, sites) grouped by department or project - Access packages: Bundle of resources with policies (approval, duration, reviews) - Policies: Who can request, who approves, how long access lasts, review frequency - Lifecycle: Request → Approval → Provision → Review → Expiration - Assumption trap: "Entitlement = grant and forget" — access requires periodic reviews and expiration

Examples

Example 1 — [Success] Onboarding package auto-provisions new hire HR creates "New Employee Onboarding" access package including: Teams, SharePoint, Distribution list. New hire requests access day 1. Manager approves. Access auto-provisioned within 1 hour. No IT manual work.

Example 2 — [Blocked] Manual access, employee retains access after leaving New employee manually added to 10 groups by IT. Employee leaves company. Manager forgets to notify IT. Employee still has Teams/SharePoint access 6 months later. Root cause: Entitlement management with expiration would have auto-removed access.

Key Mechanisms

- Core function: Entitlement management automates access request workflows, provisioning, access reviews, and expiration for groups, applications, and SharePoint sites. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Onboarding package auto-provisions new hire - Decision clue: Industry: Consulting (Rapid Staffing)

Review Path

Steps — Entra Admin Center: Entitlement Management

1. Navigate to entra.microsoft.com → Identity governance → Entitlement management 2. Create Catalog: - Catalogs → New catalog - Name: "Onboarding Resources" - Add resources (groups, apps, sites) 3. Create Access Package: - Access packages → New access package - Name: "Employee Onboarding" - Select catalog - Add resource roles (Teams, SharePoint, etc.) 4. Configure Policy: - Edit policy → "For users not in your directory" or "For users already in your directory" - Requesters: Specify who can request (all employees, specific group, etc.) - Approvers: Specify approval chain - Duration: Set access period (days) - Reviews: Enable periodic access reviews (quarterly, annually) 5. Test: Request access as test user, approve, verify provisioning

Docs: https://learn.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-overview

Explanation

Microsoft Defender for Cloud Apps (CASB - Cloud Access Security Broker) provides visibility and control over cloud app usage. It detects shadow IT (unauthorized SaaS apps), enforces data loss prevention (DLP) policies, identifies anomalous user behavior, and integrates with Conditional Access for session-level control. Organizations monitor and secure all cloud apps, not just Microsoft services.

Think of it as: Internet traffic cop — monitors all outbound web traffic to cloud apps, blocks risky activities, alerts on data exfiltration attempts.

Key Mechanics: - Discovery: Identify all cloud apps users access (may be 1000+) - Monitoring: Activity logging on all cloud apps - DLP: Prevent sensitive data (credit cards, PII) from leaving org - Session control: Real-time block/monitor at session level - Risk assessment: Rate apps by risk (security, compliance, legal)

Examples

Example 1 — [Success] CASB detects shadow IT, blocks risky app Finance analyst discovers Google Sheets alternative for budgeting (unauthorized). CASB detects upload of proprietary financial data. Policy blocks upload, alerts admin. Admin confirms app is unapproved, disables access. Data protected.

Example 2 — [Blocked] No CASB, employee uploads to consumer app Sales rep uploads customer contact list to personal Dropbox account. No CASB deployed. Customer data compromised for weeks. Root cause: CASB would have detected and blocked upload to unmanaged cloud storage.

Key Mechanisms

- Core function: Microsoft Defender for Cloud Apps (CASB - Cloud Access Security Broker) provides visibility and control over cloud app usage. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] CASB detects shadow IT, blocks risky app - Decision clue: Industry: Healthcare (HIPAA Data Protection)

Review Path

Steps — Microsoft Defender Portal: Defender for Cloud Apps

1. Navigate to https://security.microsoft.com → Cloud apps → Cloud discovery 2. Enable App Governance: - Configure automatic log collection from proxies/firewalls - Or upload traffic logs for analysis 3. Review Discovered Apps: - Filter by risk score (block high-risk) - Create policies to allow/restrict apps 4. Configure DLP Policies: - Cloud apps → Policies → File policy - Set rule: If file contains credit card → Block/Alert 5. Enable Session Control (Conditional Access integration): - Conditional Access → Create policy - App: Conditional Access App Control - Session controls: Block/Monitor downloads 6. Monitor Alerts: - Cloud apps → Alerts - Review and respond to suspicious activities

Docs: https://learn.microsoft.com/en-us/defender-cloud-apps/what-is-defender-for-cloud-apps

Explanation

Microsoft Entra Internet Access is part of Global Secure Access providing Zero Trust Network Access (ZTNA) and Security Service Edge (SSE) capabilities. It secures access to internet and SaaS applications through Microsoft's global network instead of traditional VPN. Traffic is inspected for threats and DLP, policies enforced per-user/device/application.

Think of it as: Modern VPN — instead of a tunnel to your datacenter, traffic goes through Microsoft's secure network with integrated threat protection.

Key Mechanics: - Global Secure Access client: Lightweight agent installed on devices - Traffic routing: Internet traffic routed through Microsoft edge servers - Policy enforcement: Conditional Access + data protection applied to internet traffic - Zero Trust: Every destination evaluated; no implicit trust - Assumption trap: "VPN = secure" — traditional VPN encrypts but doesn't inspect; Entra Internet Access encrypts AND inspects for threats/DLP

Examples

Example 1 — [Success] Global Secure Access blocks risky SaaS Employee connects from home, accesses Salesforce through Global Secure Access. Access policy checks: device compliant + location + risk. Employee downloads report; DLP policy checks for customer PII. No PII found, download allowed. Same employee tries to access non-approved SaaS (Slack); traffic blocked by policy.

Example 2 — [Blocked] Traditional VPN, no inspection Employee connects via traditional VPN, downloads customer data to personal Dropbox. VPN encrypts traffic but doesn't inspect. Data exfiltrated. Root cause: VPN has no DLP; Global Secure Access would have prevented unauthorized data transfer.

Key Mechanisms

- Core function: Microsoft Entra Internet Access is part of Global Secure Access providing Zero Trust Network Access (ZTNA) and Security Service Edge (SSE) capabilities. - Category fit: This concept belongs to identity strategy and governance and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Global Secure Access blocks risky SaaS - Decision clue: Industry: Distributed Workforce (Hybrid Work)

Review Path

Steps — Entra Admin Center: Global Secure Access

1. Navigate to entra.microsoft.com → Global Secure Access → Get started 2. Check prerequisites: - Entra ID Premium P1 or Microsoft Entra Suite - Supported device OS (Windows 11, macOS, iOS, Android) 3. Download Global Secure Access client: - Download from Entra admin center - Deploy via Intune or manual installation 4. Configure Internet Access: - Global Secure Access → Internet access → Create profile - Set traffic forwarding: Microsoft 365 only, or all internet - Add approved SaaS apps (Salesforce, Okta, etc.) 5. Configure Conditional Access: - Security → Conditional Access → Create policy - App: All cloud apps - Session controls: Cloud App Security (GSA integration) 6. Configure DLP: - Defender for Cloud Apps → Policies → File policy - Block downloads of sensitive data over Global Secure Access 7. Monitor: - Global Secure Access → Monitoring → Traffic logs - Review blocked attempts, policy violations

Docs: https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access

Explanation

Microsoft Entra provides comprehensive logging and reporting capabilities including sign-in logs, audit logs, provisioning logs, and risk detection reports. These logs contain detailed information about authentication events, administrative changes, and security incidents. Logs can be queried using KQL (Kusto Query Language) in Azure Monitor and exported to SIEM solutions.

Think of it as: Entra logs are your organization's security DVR — recording every authentication attempt, admin action, and suspicious activity so you can investigate incidents and prove compliance.

Key Mechanics: - Sign-in logs capture success/failure, device, location, risk signals per auth attempt - Audit logs track administrative changes (user creation, role assignments, policy mods) - Provisioning logs record synchronization events from HR or on-premises AD - Risk detection logs identify compromised users and suspicious activities - Failure condition: If logs are not exported to Log Analytics or SIEM, you cannot query them with KQL or set up alerts

Examples

Example 1 — [Success] A SOC analyst navigates to Entra admin center → Monitoring and health → Sign-in logs, filters for failed attempts in the last 24 hours, exports to CSV, and opens it in Excel to investigate suspicious authentication patterns. Audit logs show who created the suspicious account.

Example 2 — [Blocked] An organization has sign-in logs enabled in Entra but never configured log streaming to Log Analytics. When a security incident occurs, the SOC cannot run KQL queries or historical analysis — only the last 30 days of raw logs are viewable in the portal. Advanced threat hunting is blocked until Log Analytics is configured.

Key Mechanisms

- Core function: Microsoft Entra provides comprehensive logging and reporting capabilities including sign-in logs, audit logs, provisioning logs, and risk detection reports. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Access Entra Logs - Navigate to Entra admin center (https://entra.microsoft.com) - Go to Monitoring and health → Sign-in logs, Audit logs, Provisioning logs, Risk detections - Apply filters for time range, users, applications, status - Export logs to CSV for offline analysis

2. Configure Log Analytics Workspace - Navigate to Azure portal → Log Analytics workspaces → Create new or select existing - In Entra admin center → Monitoring → Diagnostic settings - Select "Add diagnostic setting" → route to Log Analytics workspace - Enable SigninLogs, AuditLogs, ProvisioningLogs, RiskyUsers, RiskySignins - Save configuration

3. Query Logs with KQL - Navigate to Azure portal → Log Analytics workspace → Logs - Use KQL to query: SigninLogs | where ResultType != 0 | summarize count() by UserPrincipalName - Save frequently used queries - Create custom workbooks for visualization

Docs: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-health https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

Explanation

KQL (Kusto Query Language) is a read-only query language used to analyze data in Azure Monitor, Microsoft Sentinel, and Microsoft Defender. KQL uses a tabular query model with operators like where, summarize, join, and extend to filter, aggregate, and transform data. It's essential for log analysis, threat hunting, and security investigations.

Think of it as: KQL is SQL for security data — it lets you ask "show me all failed logins from France in the last hour" and get results instantly.

Key Mechanics: - Pipe operator (|) chains operations: TableName | where condition | summarize count() - where clause filters rows based on conditions - summarize groups and counts data (count(), sum(), dcount(), make_set()) - extend adds calculated columns - join combines two tables on a common key - Failure condition: Using slow filters early (e.g., join before where) causes timeouts and blocks results

Examples

Example 1 — [Success] Analyst writes KQL query: SigninLogs | where TimeGenerated > ago(24h) | where ResultType != 0 | summarize FailedCount=count() by UserPrincipalName | sort by FailedCount desc. Results show the top 10 users with failed logins, enabling them to investigate potential brute force attacks.

Example 2 — [Blocked] Analyst writes KQL query: SigninLogs | join kind=inner (AuditLogs) on UserPrincipalName | where TimeGenerated > ago(30d). The join happens before the time filter, so it scans 30+ days of data from both tables first. Query times out. After analyst rewrites with where filter first, query completes in seconds.

Key Mechanisms

- Core function: KQL (Kusto Query Language) is a read-only query language used to analyze data in Azure Monitor, Microsoft Sentinel, and Microsoft Defender. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Access KQL Query Environment - Navigate to Azure portal → Log Analytics workspaces → select workspace → Logs - Or: Microsoft Sentinel → Logs or Microsoft Defender → Advanced hunting - Use schema explorer on left to discover available tables

2. Write Basic KQL Queries - Start with table name: SigninLogs - Chain operations with pipe: | where TimeGenerated > ago(1h) - Add filters: | where ResultType != 0 - Aggregate: | summarize FailedCount=count() by UserPrincipalName

3. Common Query Patterns - Failed logins: SigninLogs | where ResultType != 0 | summarize count() by UserPrincipalName - High-risk users: RiskyUsers | where RiskLevel == "high" - Lateral movement: IdentityLogonEvents | where IsLocalLogon == false | summarize count() by DeviceName

Docs: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/ https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/tutorials/learn-common-operators

Explanation

Microsoft Sentinel is a cloud-native SIEM and SOAR solution that ingests Entra ID logs for advanced threat detection and response. It provides analytics rules, hunting queries, workbooks, and automated response capabilities. Sentinel analyzes authentication patterns, detects anomalies, and correlates Entra ID events with other security data sources.

Think of it as: Sentinel is your 24/7 security operations center in the cloud — it watches all your logs, spots suspicious patterns automatically, and can kick off remediation playbooks without human intervention.

Key Mechanics: - Data connectors ingest logs from Entra ID, Azure, endpoints, and third-party sources - Analytics rules run scheduled or real-time queries to detect threats - UEBA (User and Entity Behavior Analytics) creates baselines and detects anomalies - Playbooks use Logic Apps to automate response (disable user, reset password, notify) - Failure condition: If analytics rules are not tuned correctly, false positives overwhelm SOC or real attacks are missed

Examples

Example 1 — [Success] Sentinel ingests sign-in logs, detects 50 failed logins from a single IP in 5 minutes (exceeds threshold). An analytics rule automatically triggers, a playbook disables the attacking user, and the SOC is notified. Investigation shows a brute force attack was contained within minutes.

Example 2 — [Blocked] Sentinel is deployed but no analytics rules are created. Sign-in logs flow in but nothing alerts the SOC — raw data sits in Log Analytics with no detections running. A real attack occurs (legitimate high-risk sign-in from impossible travel) but goes unnoticed for hours because Sentinel has no rule to detect impossible travel.

Key Mechanisms

- Core function: Microsoft Sentinel is a cloud-native SIEM and SOAR solution that ingests Entra ID logs for advanced threat detection and response. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Technology/SaaS

Review Path

Steps:

1. Deploy Microsoft Sentinel - Navigate to Azure portal → Create a resource → Microsoft Sentinel - Select existing Log Analytics workspace or create new - Click "Add Microsoft Sentinel" - Configure pricing (Pay-As-You-Go or Commitment tier)

2. Connect Entra ID Data Sources - In Sentinel → Data connectors - Search "Microsoft Entra ID" → Open - Click "Connect" for Sign-in logs, Audit logs, Risk detection logs - Enable data collection

3. Enable Analytics Rules - Go to Sentinel → Analytics → Rule templates - Filter for "identity" or "authentication" - Review built-in rules (Brute force detection, Impossible travel, etc.) - Click "Create rule" to enable

4. Configure Automated Response - Go to Automation → Create playbook or use existing - Set trigger: "When Microsoft Sentinel incident is created" - Add action: "Disable user" (requires managed identity with User Admin role) - Add action: "Send email to SOC" - Attach playbook to analytics rule

Docs: https://learn.microsoft.com/en-us/azure/sentinel/overview https://learn.microsoft.com/en-us/azure/sentinel/connect-microsoft-entra-id

Explanation

Microsoft Entra Permissions Management (EPM) is a Cloud Infrastructure Entitlement Management (CIEM) solution that provides visibility and control over permissions across multi-cloud environments. EPM discovers, analyzes, and manages permissions in Azure, AWS, and GCP, helping organizations implement least privilege access and reduce the attack surface.

Think of it as: EPM is a permission auditor that crawls your cloud accounts, finds every overly-privileged identity, and tells you exactly which permissions are unused and which are risky.

Key Mechanics: - Discovers all identities and their permissions across Azure/AWS/GCP - Analyzes permission usage to identify over-privilege and unused permissions - Generates risk scores based on permission scope and historical usage - Recommends rightsizing (removing unused/excessive permissions) - Failure condition: If EPM is not integrated with all three cloud platforms, you have blind spots and cannot enforce zero trust across multi-cloud

Examples

Example 1 — [Success] EPM scans Azure subscription and identifies a service account with "Contributor" role (full access) that has not been used in 90 days. It recommends removing the role. Admin tests in staging, verifies nothing breaks, then removes the role in production. Attack surface is reduced.

Example 2 — [Blocked] Service account is discovered with "Owner" role (can delete subscriptions, change billing). EPM flags as "high risk" but the account is running a production workload. Admin must reduce permissions carefully: change to "Storage Blob Data Reader" for only the storage account it actually uses. If admin removes permissions too aggressively without analysis, the service breaks.

Key Mechanisms

- Core function: Microsoft Entra Permissions Management (EPM) is a Cloud Infrastructure Entitlement Management (CIEM) solution that provides visibility and control over permissions across multi-cloud environments. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Financial/Banking

Review Path

Steps:

1. Enable Entra Permissions Management - Navigate to Entra admin center (https://entra.microsoft.com) - Go to Permissions Management - Verify licensing (EPM license required) - Complete setup wizard

2. Connect Cloud Environments - Click Settings → Data collectors - For Azure: Select subscriptions to monitor - For AWS: Create cross-account IAM role, provide ARN to EPM - For GCP: Upload service account key file - Authorize EPM to scan each platform

3. Review Permission Analytics - Go to Analytics → Permission risk - Review risk scoring dashboard - Identify high-risk identities (Owner, Admin roles) - Find unused permissions (no usage in 90+ days)

4. Implement Rightsizing - Select high-risk identity - Review recommended permission reductions - Test in staging environment first - Apply changes in production with approval workflow

Docs: https://learn.microsoft.com/en-us/entra/permissions-management/overview

Explanation

Microsoft Entra Global Secure Access provides advanced network security capabilities including Internet Access (secure web browsing with malware/content filtering), Private Access (zero-trust network access to internal resources without VPN), and integration with Conditional Access policies. It replaces traditional VPN with modern identity-centric security.

Think of it as: Global Secure Access is your replacement for traditional VPN — instead of "connect to VPN, get access to everything," it's "prove your device and identity are trusted, then access exactly the resources you need."

Key Mechanics: - Internet Access routes web traffic through Global Secure Access gateway, blocking malicious sites and enforcing content policies - Private Access provides zero-trust tunneling to on-premises apps without VPN complexity - Traffic forwarding profiles route specific traffic based on policies - Conditional Access integration enforces device compliance and MFA before access is granted - Failure condition: If Global Secure Access is not properly scoped with Conditional Access, VPN-like behavior persists — users get broad access after one authentication

Examples

Example 1 — [Success] Company enables Internet Access. Marketing user browses web and tries to visit a known phishing site. Global Secure Access gateway blocks it (checked against threat intelligence). Same user tries to download malware-infected file — blocked by Safe Browsing. User productivity improves (no wasted time on malicious sites) and security risk decreases.

Example 2 — [Blocked] Company enables Private Access to on-premises file server but does not configure Conditional Access policy. A user with outdated, non-compliant device can still connect to the file server — Global Secure Access did not enforce the device compliance check. Admin must add Conditional Access rule: "Grant access only if device is Entra-joined AND compliant."

Key Mechanisms

- Core function: Microsoft Entra Global Secure Access provides advanced network security capabilities including Internet Access (secure web browsing with malware/content filtering), Private Access (zero-trust network access to internal resources without VPN), and integration with Conditional Access policies. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Remote-First Tech Company

Review Path

Steps:

1. Enable Global Secure Access - Navigate to Entra admin center - Go to Global Secure Access - Verify licensing requirements - Complete initial setup

2. Deploy Client Software - Download Global Secure Access client for Windows/Mac - Deploy via Intune or manual distribution - Configure client with tenant settings

3. Configure Internet Access - Go to Connect → Internet Access - Enable Internet Access service - Set up web content filtering policies (block malware, adult, gambling, etc.) - Configure SafeSearch enforcement for browsers

4. Set up Private Access - Go to Connect → Private Access - Download and install Private Access Connector on-premises - Create application segments for internal resources (file server, ERP, etc.) - Configure access policies

5. Create Conditional Access Integration - Navigate to Entra admin center → Protection → Conditional Access → New policy - Set Condition: Cloud apps = "Global Secure Access" - Set Grant: Require device to be Entra-joined - Set Grant: Require MFA (if not already required) - Enable policy

Docs: https://learn.microsoft.com/en-us/entra/global-secure-access/overview

Explanation

Microsoft Defender for Identity is a cloud-based security solution that identifies, detects, and investigates advanced threats, compromised identities, and malicious insider actions directed at your organization. It monitors on-premises Active Directory signals and provides insights into identity-based attacks using behavioral analytics and machine learning.

Think of it as: Defender for Identity is a security guard stationed inside your on-premises Active Directory — it watches every Kerberos handshake, NTLM authentication, and admin action, then alerts you to suspicious patterns.

Key Mechanics: - Sensors installed on domain controllers capture authentication traffic and directory queries - Machine learning analyzes patterns to detect Pass-the-Hash, Pass-the-Ticket, Kerberoasting, Golden Tickets, DCSync attacks - Behavioral analytics identify abnormal authentication patterns (impossible travel, brute force, privilege escalation) - Integrates with Microsoft Defender XDR for correlated incident investigation - Failure condition: If sensors are not installed on all domain controllers, attackers can operate on unmonitored DCs

Examples

Example 1 — [Success] Defender for Identity sensor detects a service account requesting 500 Kerberos service tickets from a single workstation in 2 hours (Kerberoasting). Alert fires immediately, SOC investigates, finds attacker has compromised workstation, isolates it, and forces password reset on all service accounts.

Example 2 — [Blocked] Company installs Defender for Identity sensor on DC01 but not DC02. Attacker compromises DC02 and performs a DCSync attack (replicates entire AD database) over 8 hours. Defender for Identity only sees DC01 traffic, misses the attack entirely because the attacker's traffic went through unmonitored DC02.

Key Mechanisms

- Core function: Microsoft Defender for Identity is a cloud-based security solution that identifies, detects, and investigates advanced threats, compromised identities, and malicious insider actions directed at your organization. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise/Government

Review Path

Steps:

1. Install Defender for Identity Sensors - Navigate to Microsoft Defender portal (security.microsoft.com) - Go to Settings → Identities → Sensors - Download Defender for Identity sensor installer - Install on all domain controllers (or dedicated servers if DCs not supported) - Provide workspace key during installation - Verify connectivity in portal

2. Configure Sensor Settings - In Defender portal → Settings → Identities → Sensors - Select each sensor → Configure - Choose network adapter for traffic monitoring - Set directory service account (read-only AD access) - Configure certificate authentication if needed - Save settings

3. Enable Detection Rules - Go to Settings → Identities → Detection rules - Review available rules (Pass-the-Hash, Kerberoasting, etc.) - Enable all critical detection rules - Adjust sensitivity levels for your environment (reduce false positives)

4. Configure Automated Response - Go to Settings → Automated investigation and response - Enable AIR for identity threats - Configure actions: disable user, reset password, notify - Require approval for high-impact actions

Docs: https://learn.microsoft.com/en-us/defender-for-identity/what-is

Explanation

Common identity-based attack techniques include NTLM relay attacks, Kerberos vulnerabilities (Kerberoasting, Golden/Silver tickets), credential-based attacks (Pass-the-Hash, Pass-the-Ticket), remote code execution (RCE), and brute force attacks. Understanding these techniques is crucial for implementing proper defenses and detection capabilities.

Think of it as: Knowing attack techniques is like knowing how criminals break into houses — understanding lock picking helps you understand why deadbolts matter.

Key Mechanics: - Pass-the-Hash: Attacker uses NTLM hash (does not need plaintext password) to impersonate user - Kerberoasting: Attacker requests service tickets offline, cracks weak passwords - Golden Ticket: Attacker with domain admin creates forged Kerberos ticket valid for 10 years - DCSync: Attacker requests AD replication to exfiltrate password hashes - Brute Force: Automated password guessing against accounts or services - Failure condition: If mitigations are not in place (e.g., strong passwords, MFA), attackers succeed easily

Examples

Example 1 — [Success] Attacker gains local admin on a workstation and runs Mimikatz to dump NTLM hashes of cached credentials. They attempt Pass-the-Hash attack but the target server has Extended Protection for Authentication (EPA) enabled. Attack blocked because hash alone is insufficient — attackers must also prove they control the original client.

Example 2 — [Blocked] Attacker enumerates service accounts and requests service tickets (Kerberoasting). If the service account password is weak (12 characters, dictionary word), attacker cracks it offline within hours. If password is strong (20+ random characters), cracking fails. IT enabled MFA on service accounts, making attack much harder.

Key Mechanisms

- Core function: Common identity-based attack techniques include NTLM relay attacks, Kerberos vulnerabilities (Kerberoasting, Golden/Silver tickets), credential-based attacks (Pass-the-Hash, Pass-the-Ticket), remote code execution (RCE), and brute force attacks. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Security Operations / Incident Response

Review Path

Steps:

1. Understand Attack Techniques - Study Microsoft security intelligence (MSIT.powerbi.com) - Review MITRE ATT&CK framework (attack.mitre.org) - Read Microsoft Defender research reports on identity attacks - Understand attack chain: Reconnaissance → Compromise → Privilege Escalation → Persistence

2. Implement Detection Controls - Enable Defender for Identity for on-premises AD monitoring - Configure KQL queries in Sentinel/Azure Monitor for suspicious patterns - Monitor for: Failed logon attempts (EventID 4625), service ticket requests, lateral movement - Example query: SecurityEvent | where EventID == 4625 | summarize count() by Computer

3. Implement Prevention Controls - Enforce strong password policies (20+ characters, complexity) - Enable MFA for all accounts (especially admin and service accounts) - Enable Extended Protection for Authentication (EPA) on servers - Disable weak authentication protocols (NTLM, if possible; enforce Kerberos) - Monitor and limit AD replication (DCSync) permissions

4. Test Detection Capabilities - Run authorized red team exercises to test detection - Simulate Pass-the-Hash, Kerberoasting in lab environment - Verify alerts fire and SOC responds correctly - Refine detection rules based on results

Docs: https://attack.mitre.org/tactics/TA0006/ https://learn.microsoft.com/en-us/windows/security/threat-protection/](https://learn.microsoft.com/en-us/windows/security/threat-protection/

Explanation

Microsoft Defender XDR (Extended Detection and Response) provides unified security operations across endpoints, email, applications, and identity. The XDR platform correlates signals from Defender for Identity, Defender for Cloud Apps, Defender for Endpoint, and other security tools to provide comprehensive threat detection and automated response capabilities.

Think of it as: XDR is like having security cameras on every floor of your building that all feed into one central control room where AI spots suspicious behavior patterns across floors.

Key Mechanics: - Ingests logs from Defender for Identity, Endpoint, Cloud Apps, Office 365 - Correlates events across products to detect multi-stage attacks - Automated Investigation and Response (AIR) runs playbooks (disable user, isolate device, block IP) - Advanced hunting uses KQL to query all Defender data at once - Failure condition: If only one Defender product is deployed, you miss attacks that span endpoint + identity + cloud

Examples

Example 1 — [Success] Defender for Identity detects impossible travel (user in France, then US within 1 hour). Simultaneously, Defender for Endpoint detects suspicious PowerShell execution on US-based device. XDR correlates both signals, determines they are the same attack, escalates to Critical, and runs playbook to disable user and isolate device. What would take hours for SOC to manually correlate, XDR detects in seconds.

Example 2 — [Blocked] Organization deployed Defender for Endpoint only (not Defender for Identity or Cloud Apps). Attacker steals credentials and accesses on-premises file server (identity attack) — undetected by Defender for Endpoint. Attacker then executes code on workstation (detected by Endpoint) but lacks context from identity attack. SOC sees only endpoint alert, misses that this is credential theft incident.

Key Mechanisms

- Core function: Microsoft Defender XDR (Extended Detection and Response) provides unified security operations across endpoints, email, applications, and identity. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise with Microsoft 365 E5 Licensing

Review Path

Steps:

1. Access Microsoft Defender XDR - Navigate to Microsoft 365 Defender portal (security.microsoft.com) - Verify licensing (M365 E5 or Defender XDR license required) - Check that all Defender products are deployed: • Defender for Identity • Defender for Endpoint • Defender for Cloud Apps • Defender for Office 365

2. Configure Cross-Product Integration - In portal → Settings → Endpoints → Advanced features - Enable "Microsoft Defender for Office 365 integration" - Enable "Microsoft Defender for Cloud Apps integration" - Enable "Microsoft Defender for Identity integration" - Ensure all integrations show "Connected"

3. Set up Advanced Hunting - Go to Advanced hunting in the portal - Use queries that span multiple tables: IdentityInfo | where TimeGenerated > ago(24h) | where ThreatIntelligenceIndicator contains "credential" | join kind=inner (DeviceProcessEvents | where TimeGenerated > ago(24h)) on $left.DeviceName == $right.DeviceName - Save frequently used queries

4. Configure Automated Response - Go to Settings → Automation → Playbooks - Create or enable playbook for identity compromise: • Disable user • Reset password • Revoke sessions • Notify SOC - Attach playbook to analytics rules

Docs: https://learn.microsoft.com/en-us/microsoft-365-defender/mtp-evaluation https://learn.microsoft.com/en-us/microsoft-365-defender/advanced-hunting-overview

Explanation

Microsoft Entra roles define permissions and access rights within the tenant. Built-in roles provide predefined permission sets for common administrative tasks, while custom roles allow organizations to create specific permission combinations. Role management includes assignment, delegation, and Privileged Identity Management (PIM) integration.

Think of it as: Entra roles are like job titles in a company — each title comes with specific responsibilities (permissions). Custom roles let you create new job titles when standard ones don't fit your needs.

Key Mechanics: - Built-in roles: Global Administrator, User Administrator, Security Administrator, Application Administrator - Custom roles: Granular permission selection, assignable scope (tenant-wide or Administrative Unit scoped) - PIM integration: Role activation, approval workflows, time-bound eligibility - Failure condition: If admins are all Global Administrators, any account breach gives attacker full tenant access

Examples

Example 1 — [Success] IT creates custom role "Helpdesk Administrator" with permissions to reset passwords and unlock accounts only. Assigns to 5 helpdesk staff. Each can reset passwords for non-admin users but cannot create new users or change security policies. When one helpdesk account is compromised, attacker's damage is limited to password resets.

Example 2 — [Blocked] Company delegates User Administrator role to regional manager. Manager can create/delete users globally (not scoped to their region). Manager accidentally bulk-deletes wrong user group, taking down production. Admin should have used Administrative Units to scope the role to only North America users.

Key Mechanisms

- Core function: Microsoft Entra roles define permissions and access rights within the tenant. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise with Multiple Departments

Review Path

Steps:

1. Assign Built-in Roles - Navigate to Entra admin center → Identity → Roles and admins - Click role (e.g., User Administrator) - Click "+ Add assignments" - Select user or group - Save assignment

2. Create Custom Role - Go to Roles and admins → Custom roles → Create custom role - Name: "Department User Manager" - Select permissions: create users, manage passwords, manage licenses (within scope) - Set assignable scope: Entire tenant or specific Administrative Unit - Click Create

3. Assign via PIM (Privileged Roles) - Navigate to Privileged Identity Management → Roles → Assign eligibility - Click role → "+ Add assignments" - Select user/group - Choose "Eligible" (requires activation) or "Active" (permanent) - Set expiration date (time-bound) - Enable approval requirement if needed - Confirm assignment

4. Monitor Role Assignments - Go to Roles and admins → [role name] - View assignments and activation history - Export reports for compliance

Docs: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-create https://learn.microsoft.com/en-us/entra/identity/privileged-identity-management/pim-how-to-add-role-to-user

Explanation

Administrative Units (AUs) provide a way to subdivide an Entra ID tenant to delegate administrative permissions over a subset of users, groups, or devices. They create logical containers that allow scoped administration, enabling organizations to implement delegated management while maintaining security boundaries.

Think of it as: Administrative Units are regional offices in a company — each region can have its own office manager who hires and fires regional staff without touching other regions.

Key Mechanics: - Logical subdivision of tenant (geographic, departmental, organizational) - Scoped admin roles: User Administrator limited to AU members only - Membership can be static (manual) or dynamic (rule-based) - Prevents cross-AU actions — admin in North America AU cannot touch Europe AU - Failure condition: If role is not scoped to AU, admin can operate across entire tenant

Examples

Example 1 — [Success] Company creates "North America AU" with 1,200 users and assigns "North America IT Manager" role scoped to AU. Manager can create users, reset passwords within AU only. Cannot view Europe AU users. When manager account is compromised, attacker's damage is limited to North America.

Example 2 — [Blocked] Company tries to assign role scoped to AU but role definition does not support scoping. Admin can only be assigned to entire tenant. Company must choose different role or create custom scoped role.

Key Mechanisms

- Core function: Administrative Units (AUs) provide a way to subdivide an Entra ID tenant to delegate administrative permissions over a subset of users, groups, or devices. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Multi-National Manufacturing

Review Path

Steps:

1. Create Administrative Unit - Navigate to Entra admin center → Identity → Administrative units - Click "+ New administrative unit" - Name: "North America AU" - Membership type: Assigned (manual) or Dynamic (rules-based) - Click Create

2. Add Members to AU - Click AU → Members → Add members - Search and select users, groups, or devices - Click Add - For dynamic: Create rule (e.g., user.country -eq "US" -or user.country -eq "CA")

3. Assign AU-Scoped Roles - Click AU → Roles and admins - Click "+ Add assignments" - Select role (User Administrator, Helpdesk Administrator, etc.) - Select user/group for assignment - Click Assign - Verify role scope shows AU name, not entire tenant

4. Monitor AU Membership - Go to Administrative units - Click AU → Members - View and manage membership changes

Docs: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/administrative-units

Explanation

Custom Security Attributes provide extensible metadata for Entra ID objects (users, applications, service principals) beyond standard properties. They enable fine-grained access control, conditional access decisions, and integration with external systems without schema modifications.

Think of it as: Custom Security Attributes are colored badges you can stick on people/apps to create granular access rules. Instead of "Manager" role, you can have "Department=Finance" badge and create rules like "if Department != Finance, block this app."

Key Mechanics: - Attribute sets group related attributes (e.g., EmployeeData, ApplicationSecurity) - Attributes support strings, integers, booleans with predefined values or patterns - Single-valued (one value per attribute) or multi-valued (multiple values) - Integrated into Conditional Access: conditions based on user attributes - Failure condition: If Conditional Access policy uses undefined or inconsistently assigned attributes, policy may block all users or apply incorrectly

Examples

Example 1 — [Success] Company creates custom attribute "ClearanceLevel" with values [Public, Confidential, Secret]. Assigns to users. Creates Conditional Access policy: "If ClearanceLevel != Secret, block access to classified app." Employee with Confidential clearance tries to access classified app — blocked. No manual role management needed.

Example 2 — [Blocked] Company creates Conditional Access policy: "If Department == Finance, allow access." But forgets to assign Department attribute to 50% of finance users. Those users get blocked even though they are finance staff. Policy logic is correct, but data consistency failed.

Key Mechanisms

- Core function: Custom Security Attributes provide extensible metadata for Entra ID objects (users, applications, service principals) beyond standard properties. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Consulting with Classified Contracts

Review Path

Steps:

1. Create Custom Security Attribute Set - Navigate to Entra admin center → Identity → Custom security attributes - Click "+ Add attribute set" - Name: "SecurityClearance" - Click Create

2. Define Attributes - Click attribute set → "+ Add attribute" - Name: "ClearanceLevel" - Data type: String - Predefined values: [TopSecret, Secret, Confidential, Unclassified] - Assign permissions (who can set this attribute) - Click Create

3. Assign Attributes to Users - Go to Users → All users → Select user - Click "Custom security attributes" - Click "+ Add attribute set" - Select "SecurityClearance" → Set "ClearanceLevel" = "Secret" - Click Save

4. Use in Conditional Access - Create new Conditional Access policy - Go to Assignments → Users → Custom security attributes - Condition: SecurityClearance ClearanceLevel -eq "TopSecret" - Grant: Block - Click Create

Docs: https://learn.microsoft.com/en-us/entra/fundamentals/custom-security-attributes-overview

Explanation

Device registration and join processes connect devices to Entra ID, enabling device-based conditional access, SSO, and management policies. Microsoft Entra registered adds personal devices (BYOD), Microsoft Entra joined connects corporate devices, and Hybrid Microsoft Entra joined bridges on-premises domain-joined devices with cloud identity.

Think of it as: Device join is like putting a badge on a computer so Entra ID recognizes it and knows whether to trust it for access.

Key Mechanics: - Microsoft Entra Registered: Personal devices with basic management (iOS, Android, Mac, Windows) - Microsoft Entra Joined: Cloud-only corporate devices with full management - Hybrid Microsoft Entra Joined: Domain-joined devices that are also cloud-registered for SSO - All three types can be controlled via Conditional Access (device compliance, encryption, etc.) - Failure condition: Exam trap — Hybrid Join ≠ Entra Join. Different join types, different management paths. Hybrid Join requires on-premises AD + Entra Connect.

Examples

Example 1 — [Success] Employee brings personal iPhone and uses "Work apps" feature to register it. Device is added to Entra ID with limited management (no app installation policies). Employee can access email but cannot sync OneDrive unless device passes compliance check (screen lock, encryption). Conditional Access: "If device not registered OR not compliant, block."

Example 2 — [Blocked] Admin enables device join restriction: "Only IT-owned devices can be joined." New employee with personal laptop tries to join Entra ID at OOBE. Join is blocked because their device does not match the restriction rule. Employee must use registered personal device or wait for corporate laptop.

Key Mechanisms

- Core function: Device registration and join processes connect devices to Entra ID, enabling device-based conditional access, SSO, and management policies. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Hybrid Workplace (Office + Remote)

Review Path

Steps:

1. Configure Device Settings - Navigate to Entra admin center → Devices → Device settings - Set "Users may join devices to Microsoft Entra ID": All / Selected / None - Set "Users may register their devices": All / Selected / None - Optionally require MFA for device join - Set max devices per user (default 50)

2. Microsoft Entra Register (BYOD) - User: Settings → Accounts → Access work or school - Click "Connect" and enter work email - Authenticate (MFA if required) - Accept device management terms - Device registered in Entra ID

3. Microsoft Entra Join (Corporate) - At OOBE: "Set up for an organization" - Enter corporate credentials - Complete MFA if required - Device joins tenant automatically - Corporate policies apply immediately

4. Hybrid Microsoft Entra Join - Prerequisites: Entra Connect with device sync enabled, SCP configured in on-premises AD - On domain-joined Windows device: Settings → Accounts → Access work or school - Click "+ Connect" and select "Join this device to Entra ID" - Device appears in Entra ID AND stays domain-joined

5. Monitor Devices - Go to Entra admin center → Devices → All devices - Filter by join type, OS, compliance status - View device sign-in activity - Disable or delete devices as needed

Docs: https://learn.microsoft.com/en-us/entra/identity/devices/device-join-plan

Explanation

External identity providers enable users from partner organizations to authenticate using their home organization's credentials. Entra ID supports federation with SAML 2.0, WS-Federation, and OpenID Connect providers, allowing seamless B2B collaboration without requiring guest accounts for every external user. Direct federation and social identity providers expand authentication options.

Think of it as: External IdP is like accepting a passport from another country instead of requiring your own ID. Users sign in with their home organization credentials.

Key Mechanics: - Direct federation: Partner's Entra ID or SAML provider authenticates users - SAML 2.0 federation: Metadata exchange, metadata URL or upload, claims mapping - Social providers: Google, Facebook, Microsoft Account, LinkedIn for consumer apps - No guest account creation needed for federated users (they sign in directly) - Failure condition: If federation is not tested with sample user, users may be blocked at sign-in

Examples

Example 1 — [Success] Company configures direct federation with "partner.com" SAML provider. Partner employee uses email "john@partner.com" to sign in to app. SAML provider authenticates, user is granted access. No guest account was created — federation handled authentication.

Example 2 — [Blocked] Exam trap — Company sets up Google federation but does not map email claim correctly. User tries to sign in but their Google email does not map to Entra ID email field. Sign-in fails with "unrecognized user." Admin must fix claim mapping for federation to work.

Key Mechanisms

- Core function: External identity providers enable users from partner organizations to authenticate using their home organization's credentials. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Multi-Company Consortium

Review Path

Steps:

1. Configure Direct Federation - Navigate to Entra admin center → External Identities → All identity providers - Click "+ New SAML/WS-Fed IdP" - Enter partner organization name - Paste or upload SAML metadata from partner - Configure claims mapping (email is required) - Test federation with sample partner user - Save configuration

2. Add Social Identity Providers - Go to External Identities → All identity providers - Click "+ New" and select provider (Google, Facebook, etc.) - Register app with social provider (get Client ID, Client Secret) - Enter credentials in Entra ID - Configure attribute mapping - Save configuration

3. Test Federation - Create test guest account with partner email - Redeem invitation - Verify authentication redirects to partner IdP - Check that user is provisioned and has correct attributes

Docs: https://learn.microsoft.com/en-us/entra/external-id/direct-federation

Explanation

External user invitation and management enables B2B collaboration by bringing partner users into your tenant as guests. The invitation process creates guest accounts with limited permissions, while management includes lifecycle operations, access reviews, and integration with entitlement management for self-service access packages.

Think of it as: Inviting external users is like giving temporary VIP badges to visitors — they have limited access (guest permissions), an expiration date, and their activities are monitored.

Key Mechanics: - Invitation: Admin or self-service sends invitation to external email - Guest user creation: Account created with UserType="Guest" and limited permissions - Acceptance: External user redeems invitation link, optionally links to existing account - Conditional Access: Guest users subject to same policies as members - Lifecycle: Access reviews can auto-remove unused guest accounts - Failure condition: If guest permissions are not properly restricted, external users may access internal resources beyond their intended scope

Examples

Example 1 — [Success] Admin invites contractor "jane@contractor.com" with Guest Inviter role. Jane receives invitation, redeems it, and is added as guest. Jane can access only the project team SharePoint site (not entire tenant). Conditional Access: Require MFA. After 6 months, access review flags Jane as unused, admin removes her account.

Example 2 — [Blocked] Admin invites external user but accidentally assigns Member role with Global Admin permissions. External user is now able to modify tenant settings and access all data (massive security breach). Guest accounts must have limited permissions by default.

Key Mechanisms

- Core function: External user invitation and management enables B2B collaboration by bringing partner users into your tenant as guests. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Invite External User - Navigate to Entra admin center → Users → All users - Click "+ New guest user" - Enter guest's email address - Optionally add to group - Write personalized message - Click Invite

2. Guest Redeems Invitation - Guest receives email with redemption link - Guest clicks link and authenticates (with home org or MSA if not federated) - Guest account provisioned in your tenant - Guest added to any assigned groups

3. Configure Guest Permissions - Go to Entra admin center → External Identities → External collaboration settings - Restrict what guests can do: View profiles, Create groups, Invite other guests - Set expiration on guest access (if enabled) - Configure Conditional Access: Require MFA for guests

4. Manage Guest Lifecycle - Go to Users → All users → Filter by UserType=Guest - Review guest accounts and their activity - Create access review: Settings → Access reviews → Create review - Set periodic reviews (quarterly) to remove inactive guests

5. Remove Guest Users - Select guest user → Delete - Or use access review to auto-remove based on inactivity

Docs: https://learn.microsoft.com/en-us/entra/external-id/what-is-b2b

Explanation

Microsoft Entra Connect synchronizes on-premises Active Directory with Entra ID, enabling hybrid identity scenarios. It supports password hash synchronization, pass-through authentication, and federation, providing seamless SSO between on-premises and cloud resources. Configuration includes sync scope, attribute mapping, and filtering rules.

Think of it as: Entra Connect is a one-way sync bridge — it copies your on-premises users to the cloud so they can sign into Microsoft 365, but changes happen on-premises first, then sync up.

Key Mechanics: - Password Hash Sync (PHS): Hash of password hash synced, users sign in cloud and on-premises with same password - Pass-Through Authentication (PTA): Cloud sign-in validated against on-premises AD in real-time - Federation (ADFS): On-premises ADFS handles authentication, Entra ID trusts ADFS - Exam trap — PTA no fallback: Pass-Through Auth has no offline fallback — if agents are down, cloud auth fails. PHS has offline fallback. - Sync scope: Filter which OUs, groups, or users sync to cloud

Examples

Example 1 — [Success] Company installs Entra Connect with PHS. On-premises users sync to cloud with password hashes. Users sign in to Office 365 with same password as on-premises AD. ADFS not required — cloud authentication is handled directly. If DC is down, users can still sign into cloud.

Example 2 — [Blocked] Company uses PTA (Pass-Through Authentication) and all PTA agents go offline (network issue). User tries to sign into Office 365 — blocked because cloud must validate password against on-premises AD in real-time and agents are down. No fallback available. Company should have deployed PHS alongside PTA or redundant agents.

Key Mechanisms

- Core function: Microsoft Entra Connect synchronizes on-premises Active Directory with Entra ID, enabling hybrid identity scenarios. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise Hybrid Migration

Review Path

Steps:

1. Install Entra Connect - Download Entra Connect from Microsoft Download Center - Run on domain-joined server with Local Admin rights - During setup, sign in as Global Admin and Domain Admin - Choose Express Settings or Custom - Select authentication method (PHS recommended for most) - Complete and start initial sync

2. Monitor Initial Sync - Wait for initial sync to complete (30 min to several hours) - Open "Synchronization Service Manager" from Start menu - Check Operations tab for sync status - Verify users appear in Entra ID (Users → All users)

3. Configure Sync Filtering (Optional) - In Entra Connect → Synchronization Service Manager - Select connector → Configure partitions - Filter by OU to sync specific users only - Or use group-based filtering

4. Enable Optional Features - Go back to Entra Connect wizard → Configure optional features - Enable Device Sync (for Hybrid Microsoft Entra Join) - Enable Password Writeback (for SSPR) - Configure attribute mapping if needed

5. Verify Sync Health - Navigate to Entra admin center → Entra Connect → Connect Health - Monitor sync errors and sync time - Resolve any connector errors

Docs: https://learn.microsoft.com/en-us/entra/identity/hybrid/whatis-hybrid-identity

Explanation

Seamless SSO provides automatic sign-in to cloud applications for domain-joined devices without requiring users to enter passwords. It works by leveraging Kerberos tickets from on-premises domain authentication to automatically authenticate to Entra ID, eliminating password prompts while maintaining security.

Think of it as: Seamless SSO is showing your domain logon ticket to cloud apps — you are already logged in on-premises, so cloud knows you and grants access instantly.

Key Mechanics: - Requires domain-joined device with valid Kerberos TGT - Works with PHS or PTA (not Federation/ADFS) - Browser must support Integrated Windows Auth - AZUREADSSOACCT computer account created in on-premises AD - Failure condition: If browser is not configured to allow SSO (not in Intranet zone), Kerberos ticket is not sent

Examples

Example 1 — [Success] Employee logs in to domain-joined laptop with domain credentials (gets Kerberos ticket). Employee opens Edge browser and navigates to portal.azure.com. Entra ID detects domain-joined device, requests Kerberos ticket, browser sends it. Entra ID validates ticket and logs user in without password prompt. Full SSO experience.

Example 2 — [Blocked] Employee opens Google Chrome (not configured for Windows Integrated Auth). Navigates to portal.azure.com. Browser cannot send Kerberos ticket because it is not in trusted zone. User gets password prompt. Admin must add https://login.microsoftonline.com to Intranet zone via Group Policy for Seamless SSO to work in Chrome.

Key Mechanisms

- Core function: Seamless SSO provides automatic sign-in to cloud applications for domain-joined devices without requiring users to enter passwords. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Large Enterprise with Domain-Joined Workstations

Review Path

Steps:

1. Enable Seamless SSO in Entra Connect - Run Entra Connect configuration wizard - Go to "User sign-in" page - Check "Enable Seamless single sign-on" - Provide Domain Administrator credentials - Complete — AZUREADSSOACCT computer account created automatically

2. Configure Group Policy for SSO - Open Group Policy Management Console (gpmc.msc) - Create or edit policy for domain computers - Go to Computer Configuration → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page - Add Microsoft Entra ID URLs to Intranet zone

3. Verify AZUREADSSOACCT - In on-premises AD, find computer: CN=AZUREADSSOACCT, CN=Computers, DC=domain, DC=com - Verify account exists and is enabled - Check Service Principal Names (SPNs) are configured - Run: setspn -L AZUREADSSOACCT

4. Test Seamless SSO - Join test device to domain - Log in with domain credentials - Open Edge or Chrome browser - Navigate to portal.azure.com - Should automatically sign in without password

5. Monitor SSO Health - Navigate to Entra admin center → Entra Connect → Connect Health - Review SSO sign-in activity - Monitor Kerberos ticket validation failures

Docs: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso

Explanation

Deploying Azure resources for hybrid identity involves setting up infrastructure components needed to connect on-premises AD with Entra ID. This includes provisioning VMs for Entra Connect, configuring network connectivity, setting up monitoring via Connect Health, and ensuring security for hybrid scenarios.

Think of it as: Deploying hybrid identity infrastructure is building a bridge between your on-premises castle and cloud kingdom — you need secure tunnels, monitoring, and redundancy.

Key Mechanics: - Entra Connect runs on Windows Server (2016+ recommended) - Requires 4GB+ RAM, 2+ CPU cores - Network: Site-to-site VPN or ExpressRoute for connectivity - Connect Health: Azure service for monitoring sync health - Multiple Entra Connect servers for HA (staging mode or separate servers) - Failure condition: If only one Entra Connect server and it goes down, synchronization stops

Examples

Example 1 — [Success] Company deploys Entra Connect in HA setup: primary server in datacenter, secondary in staging mode in Azure VM. If primary fails, admin promotes secondary to active. Synchronization continues. No user downtime.

Example 2 — [Blocked] Company deploys single Entra Connect server in Azure VM but network connectivity is unstable (poor ExpressRoute). Sync fails intermittently, users are not created in cloud, access fails. Company needs redundant Entra Connect servers and proper network connectivity.

Key Mechanisms

- Core function: Deploying Azure resources for hybrid identity involves setting up infrastructure components needed to connect on-premises AD with Entra ID. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise with Multiple Datacenters

Review Path

Steps:

1. Deploy Entra Connect Server - Provision Windows Server 2016+ VM (on-premises or Azure) - Join to domain - Allocate 4GB+ RAM, 2+ CPU cores - Install Entra Connect - Configure with PHS or PTA authentication

2. Set up Network Connectivity - For Azure VM: Configure Site-to-Site VPN or ExpressRoute - Ensure outbound HTTPS (443) connectivity to Azure - Configure firewall rules to allow Entra Connect to Azure endpoints - Verify DNS resolution to on-premises domain controllers

3. Install Connect Health Monitoring - Download Microsoft Entra Connect Health agent - Install on Entra Connect servers - Register with Azure portal - Configure email alerts for sync errors

4. Deploy HA Setup (Optional) - Deploy second Entra Connect server in staging mode - Configure firewall and network for second server - Test failover procedures - Document failover runbook

5. Monitor Deployment - Navigate to Entra admin center → Entra Connect → Sync errors - Configure Azure Monitor alerts for critical errors - Monitor agent health status - Test disaster recovery procedures quarterly

Docs: https://learn.microsoft.com/en-us/entra/identity/hybrid/whatis-hybrid-identity

Explanation

Configuring SSO for on-premises applications extends Entra ID authentication to legacy and internal applications using Application Proxy, SAML federation, or header-based authentication. This allows users to authenticate once in Entra ID and access on-premises apps securely without separate credentials.

Think of it as: Application Proxy is a reverse proxy that sits in the cloud — it checks Entra ID authentication, then securely relays requests to your on-premises app.

Key Mechanics: - Application Proxy: Connector on-premises, gateway in Azure, HTTPS tunnel - SAML: Entra ID as IdP, on-premises app as Service Provider - Header-based: Connector injects user identity in HTTP headers - Conditional Access: Applied to all SSO methods (device compliance, MFA, etc.) - Failure condition: If Application Proxy connector is offline, users cannot access on-premises app

Examples

Example 1 — [Success] Company publishes internal SharePoint site via Application Proxy. User signs in to Entra ID at portal, Connector verifies auth, tunnels request to on-premises SharePoint. User gets SSO without password. If device is non-compliant, Conditional Access blocks even authenticated users.

Example 2 — [Blocked] Company configures SAML SSO for legacy HR app but forgets to create app registration in Entra ID. App is not listed in Enterprise apps. Users cannot access SSO — they see "Application not found" error. Admin must create app registration first.

Key Mechanisms

- Core function: Configuring SSO for on-premises applications extends Entra ID authentication to legacy and internal applications using Application Proxy, SAML federation, or header-based authentication. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Hybrid Enterprise with Legacy Apps

Review Path

Steps:

1. Deploy Application Proxy Connector - Download connector from Entra admin center - Install on domain-joined server on-premises - Authenticate with Global Admin credentials - Verify connectivity to Azure

2. Publish On-Premises App - Navigate to Entra admin center → Enterprise applications - Click "+ New application → Application Proxy" - Configure: App name, internal URL (http://sharepoint.contoso.local) - External URL: sharepoint-proxy.contoso.com - Pre-authentication: Entra ID (Conditional Access applied) - Click Create

3. Configure SAML SSO (If Applicable) - Go to Enterprise applications → [app] → Single sign-on - Select SAML - Upload SP metadata from app or manually configure - Map claims (email, user ID, etc.) - Save configuration

4. Test SSO - Access published app via external URL - Should redirect to Entra ID login - After authentication, should access on-premises app seamlessly - Test with compliant and non-compliant devices

5. Monitor & Troubleshoot - Check connector health in portal - Review sign-in logs for failures - Verify certificates and SSL configuration

Docs: https://learn.microsoft.com/en-us/entra/identity/app-proxy/what-is-application-proxy

Explanation

Entra Connect Health is an Azure service that monitors the health and synchronization status of Entra Connect servers, Pass-Through Authentication agents, and Active Directory Federation Services (ADFS) infrastructure. It provides alerts for sync failures, agent health issues, and performance metrics to ensure hybrid identity infrastructure remains operational.

Think of it as: Connect Health is a dashboard showing if your hybrid identity bridge is working — is sync running? Are agents responding? What errors happened?

Key Mechanics: - Agent installed on Entra Connect and PTA servers - Reports sync cycle health, connector errors, password sync status - Monitors on-premises infrastructure without direct access - Alerts on high-risk sign-ins and sync failures - Failure condition: If Connect Health agent is not installed, admins are blind to infrastructure failures

Examples

Example 1 — [Success] Connect Health reports sync error: "Connector out of space." Admin installs Connect Health agent, sees alert immediately, frees up disk space on server, sync resumes. Connect Health prevented user creation failures.

Example 2 — [Blocked] Company does not install Connect Health agent. Entra Connect server fails silently for 3 days before anyone notices — no users were created or updated in cloud during that time. Users cannot sign into Office 365. Alert would have fired in minutes if agent was installed.

Key Mechanisms

- Core function: Entra Connect Health is an Azure service that monitors the health and synchronization status of Entra Connect servers, Pass-Through Authentication agents, and Active Directory Federation Services (ADFS) infrastructure. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise with Distributed Entra Connect

Review Path

Steps:

1. Install Connect Health Agent - Download agent from Azure portal (Entra admin center → Entra Connect) - Install on each Entra Connect server - Run installer with Local Administrator rights - Provide credentials to register with Entra ID

2. Configure Alerts - Navigate to Entra admin center → Entra Connect → Connect Health - Click "Alert Settings" - Enable alerts for: Sync failures, Agent issues, Unhealthy servers - Configure email recipients

3. Monitor Sync Health - Go to Connect Health → Synchronization tab - View recent sync cycles and errors - Check connector status and performance - Click error to see details and remediation steps

4. Monitor Agent Health - Go to Connect Health → PTA Agents tab (if using PTA) - View agent connectivity status - Verify all agents are reporting - Check agent version and updates

5. Review Usage Analytics - Go to Connect Health → Usage Analytics - View sync frequency and duration trends - Identify performance issues - Plan capacity upgrades if needed

Docs: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-health-operations

Explanation

Pass-Through Authentication (PTA) is a hybrid identity authentication method where cloud sign-in is validated in real-time against on-premises Active Directory. Unlike Password Hash Sync, passwords are never synchronized to cloud — only authentication requests are validated against on-premises AD.

Think of it as: PTA is like calling on-premises AD to ask "is this password correct?" for every cloud sign-in. High security, but requires network connectivity.

Key Mechanics: - No password hashes synced to cloud (passwords stay on-premises) - Real-time validation against on-premises AD - Requires PTA agents (lightweight) on-premises - Requires connectivity between Azure and on-premises - Exam trap — PTA no fallback: If all PTA agents are down, cloud sign-in fails completely (no offline cache) - Supports Conditional Access and MFA

Examples

Example 1 — [Success] Company deploys PTA with 3 agents for redundancy. User signs into cloud app, request routed to PTA agent, agent validates password against on-premises AD, returns result. If one agent fails, others handle requests. All sign-ins succeed.

Example 2 — [Blocked] Company deploys single PTA agent. Agent goes offline (server reboot). User tries to sign into cloud but PTA agent is unavailable. Sign-in fails with no fallback. Company should have deployed multiple agents or used PHS alongside PTA.

Key Mechanisms

- Core function: Pass-Through Authentication (PTA) is a hybrid identity authentication method where cloud sign-in is validated in real-time against on-premises Active Directory. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Financial Services with Password Security Requirements

Review Path

Steps:

1. Deploy PTA Agents - Download PTA agent from Entra admin center - Install on 2+ domain-joined servers on-premises - Provide Global Admin credentials during installation - Verify agent registered in portal (should show "Active")

2. Enable Pass-Through Authentication - Navigate to Entra admin center → Entra Connect - Click "Change user sign-in method" - Select "Pass-through authentication" - Confirm PTA agents are deployed and active - Click "Enable"

3. Configure For HA - Deploy agents across different servers/networks - Monitor agent connectivity status - Set up alerts for agent disconnection - Document failover procedures

4. Test PTA Authentication - Log out of cloud apps - Sign in again using cloud credentials - Should authenticate against on-premises AD in real-time - Check auth requests reach on-premises without latency

5. Monitor Agent Health - Go to Entra admin center → Entra Connect → Pass-through Authentication - View all agent statuses (should show "Active") - Monitor connectivity and performance - Install Connect Health agent for detailed monitoring

Docs: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta

Explanation

Password Hash Synchronization (PHS) synchronizes hashes of user passwords from on-premises AD to Entra ID, enabling cloud sign-in with the same credentials. Unlike PTA, PHS caches password hashes in cloud, providing offline authentication fallback when on-premises AD is unreachable.

Think of it as: PHS is like photocopying your password hash and keeping it in the cloud for emergencies — if on-premises is down, cloud can still authenticate you.

Key Mechanics: - Hash of password hash synced (not plaintext password) — extra security layer - Default sync every 2 minutes for delta changes - One-way sync (from on-premises to cloud only) - Works with Seamless SSO and MFA - Provides cloud authentication fallback (unlike PTA) - Exam trap — Hash of hash: It is a hash of a hash, not plaintext. Cloud cannot recover password even if breached.

Examples

Example 1 — [Success] Company deploys PHS with Entra Connect. On-premises user changes password. Within 2 minutes, hash is synced to cloud. User signs into Office 365 with new password. If on-premises AD goes down, user can still sign into cloud (hash is cached).

Example 2 — [Blocked] Company configures PHS but syncing is disabled due to compatibility setting. Users cannot sign into cloud even though they are synced to Entra ID. Admin enables "Password sync" in Entra Connect configuration, sync resumes in 2 minutes.

Key Mechanisms

- Core function: Password Hash Synchronization (PHS) synchronizes hashes of user passwords from on-premises AD to Entra ID, enabling cloud sign-in with the same credentials. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise Hybrid with High Availability Requirements

Review Path

Steps:

1. Enable Password Hash Sync in Entra Connect - Run Entra Connect → Change user sign-in method - Select "Password Hash Synchronization" - Review optional features (Password writeback, etc.) - Click "Enable" - Initial sync begins (may take hours for large directories)

2. Monitor Initial Sync - Open Synchronization Service Manager - Check Operations tab for "Directory Import" and "Synchronization" status - Verify users appear in Entra ID (Users → All users) - Check for any connector errors

3. Verify Sync is Working - Change password for test user on-premises - Wait 2-5 minutes - Try signing into Office 365 with new password - Should succeed (proves hash was synced)

4. Configure Sync Settings (Optional) - In Entra Connect → Synchronization Service Manager - Review connector schedule (default 30 min for delta sync) - Configure attribute mapping if needed - Set up filtering for specific users/OUs

5. Monitor Ongoing Sync - Install Connect Health agent - Monitor password sync health in Connect Health - Review error logs if users report password sync issues - Verify leaked password detection (if P2 license)

Docs: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-password-hash-synchronization

Explanation

Managing Entra Connect Synchronization involves monitoring sync cycles, resolving sync errors, managing connector performance, and tuning synchronization rules. This includes monitoring directories for changes, handling object conflicts, managing attribute flow, and troubleshooting synchronization failures.

Think of it as: Managing sync is like managing a factory's production line — you monitor for errors, remove blockages, optimize flow, and ensure quality.

Key Mechanics: - Delta sync: Every 30 minutes (default), only changed objects - Full sync: Periodic, all objects (initial and periodic) - Connector errors: Objects that failed to sync (must be resolved) - Sync rule: Defines which attributes flow from on-premises to cloud - Metaverse: Internal store where on-premises and cloud objects matched - Failure condition: If sync errors accumulate, users may not sync or updates fail

Examples

Example 1 — [Success] Admin detects sync error: "John Doe already exists in cloud with different source anchor." Admin investigates: User was manually created in cloud, then imported from on-premises (conflicting source anchors). Admin removes manual cloud user, re-syncs. Sync succeeds.

Example 2 — [Blocked] Company created 1,000 test users in cloud, then imported on-premises with same UPNs. Massive sync conflict — 1,000 connector errors. No new users can sync until conflicts resolved. Admin must quarantine old test users, wait for next sync cycle, verify new users sync successfully.

Key Mechanisms

- Core function: Managing Entra Connect Synchronization involves monitoring sync cycles, resolving sync errors, managing connector performance, and tuning synchronization rules. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise Scaling to Cloud

Review Path

Steps:

1. Access Sync Service Manager - Start → "Synchronization Service Manager" (on Entra Connect server) - View Operations tab for sync cycle history - Click any cycle to see details (duration, objects processed, errors)

2. Monitor Sync Cycles - Review Operations tab regularly - Note sync duration (should be < 10 min for delta) - Look for connector errors (red X) - Click error to see details and resolution steps

3. Force Sync Cycle (If Needed) - PowerShell: Start-ADSyncSyncCycle -PolicyType Delta - Or: Right-click connector → Run → Full Import

4. Troubleshoot Sync Errors - Check connector error details - Common: "DN already exists" (objects with duplicate attributes) - Resolution: Rename on-premises object or delete duplicate in cloud - Retry sync after fixing root cause

5. View Sync Flowthrough (Detailed) - Navigate to Metaverse Search tab - Search for user - View on-premises and cloud attributes - Verify attribute mapping is correct

6. Optimize Sync Performance - Monitor CPU and memory on Entra Connect server - If delta sync taking >15 min, consider full sync cleanup - Check database size and defragment if needed

Docs: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis

Explanation

Microsoft Entra Password Protection prevents weak passwords by checking against a global banned password list (compromised passwords from breaches) and custom banned words. It works both on-premises (via Entra Connect) and in cloud, rejecting passwords that match known compromised passwords or organizational words.

Think of it as: Password Protection is a security guard checking every password against a list of "known bad passwords" — if your password is on the list, it is rejected.

Key Mechanics: - Global banned list: Passwords from known breaches (e.g., "password123", "MyCompany2024") - Custom banned words: Organization names, product names you specify - On-premises: Deployed as DC agent, works during password changes on-premises - Cloud: Checks passwords during new user creation and self-service password reset - Failure condition: If password policy is not enforced, weak passwords remain in directory

Examples

Example 1 — [Success] Employee tries to set password to "Contoso2024" (company name + year). Password Protection rejects it (custom banned word). Employee sets password to "C0nt0s0Tr@nsmission#2024" (mix of complexity). Accepted. Strong password without company-predictable words.

Example 2 — [Blocked] User tries to set password to "P@ssword!2024" — password rejected because "password" is on global banned list (compromised in past breaches). User must choose new password not in banned lists.

Key Mechanisms

- Core function: Microsoft Entra Password Protection prevents weak passwords by checking against a global banned password list (compromised passwords from breaches) and custom banned words. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise with Compliance Requirements

Review Path

Steps:

1. Deploy Password Protection On-Premises - Download Entra Password Protection DC agent - Install on all domain controllers (or at least in each site) - Requires domain admin rights - Agent begins monitoring password changes immediately

2. Configure Custom Banned Words - Navigate to Entra admin center → Security → Authentication methods - Go to Password protection - Click "Add banned password list" - Add: company name, divisions, product names, anything predictable - Save configuration

3. Set Enforcement Mode - In Password protection settings - Choose: Audit mode (log rejections) or Enforce (reject changes) - Recommend starting in Audit, transition to Enforce after 2 weeks - Monitor Event Viewer for rejections

4. Enforce in Cloud - Password protection automatically enforced for: • Self-service password reset (SSPR) • New user creation • User changing own password in cloud - No additional configuration needed

5. Monitor & Report - Check Event Viewer on DCs: Event ID 10000-10001 (password changes) - Review rejected passwords to refine custom list - Monitor in Entra portal → Reports → Authentication methods usage

Docs: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad

Explanation

Planning authentication methods and MFA strategy involves selecting and deploying appropriate authentication technologies for your organization. This includes choosing between MFA methods (Microsoft Authenticator, FIDO2, phone sign-in), planning for conditional access integration, and ensuring business continuity with fallback authentication options.

Think of it as: Authentication planning is like designing a security checkpoint — you decide what ID to accept, what verification to require, and what happens if systems fail.

Key Mechanics: - MFA methods: Authenticator app, phone call, SMS, FIDO2 hardware keys - Passwordless: Phone sign-in, Windows Hello, FIDO2 (no password needed) - Fallback: Phone, security questions for MFA recovery - Conditional Access integration: MFA required based on risk, location, device - Exam trap — break-glass excluded from CA: Emergency access accounts must be excluded from all CA policies

Examples

Example 1 — [Success] Company deploys Microsoft Authenticator as primary MFA. Users can use phone sign-in (passwordless) or MFA approval. If app is unavailable, users fall back to SMS. Admin ensures break-glass account is NOT subject to Conditional Access (can always sign in). All staff adopted within 2 weeks.

Example 2 — [Blocked] Company configures Conditional Access: Require MFA for all users. But break-glass account is also subject to MFA requirement. During outage, break-glass user cannot sign in (MFA blocked). Emergency access is impossible. Policy should exclude break-glass from CA.

Key Mechanisms

- Core function: Planning authentication methods and MFA strategy involves selecting and deploying appropriate authentication technologies for your organization. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise Transitioning to Passwordless

Review Path

Steps:

1. Plan Authentication Methods - Inventory users and their devices (mobile, laptop, etc.) - Decide on primary method (Authenticator app recommended) - Identify fallback (SMS for users without phones) - Plan rollout timeline (phased or all-at-once)

2. Deploy Authenticator App - Navigate to Entra admin center → Authentication methods - Click "Microsoft Authenticator" - Enable "Allow use of Authenticator app" - Choose push notifications OR phone sign-in (or both) - Configure app registration: Users can register during MFA setup

3. Enable Passwordless Phone Sign-In - Go to Authentication methods → Phone sign-in - Enable for users - Users download Authenticator app - Add work account → Enable phone sign-in - User can now sign in without password (approve notification on phone)

4. Configure Windows Hello for Business - Go to Authentication methods → Windows Hello for Business - Enable for users - Settings → Accounts → Sign-in options → Windows Hello Face/PIN - User enrolls biometric/PIN - Can sign into device without password

5. Set Conditional Access for MFA - Create Conditional Access policy - Condition: All users or specific groups - Grant: Require MFA (Authenticator, FIDO2, etc.) - Exclude: Break-glass account (critical!) - Enable policy

6. Configure Fallback Methods - Allow SMS as fallback if app unavailable - Provide voice call option for older users - Test fallback scenarios

Docs: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods

Explanation

Windows Hello for Business enables passwordless sign-in using biometric (face, fingerprint) or PIN authentication on Windows devices. It provides strong multi-factor authentication without requiring a password, leveraging device hardware (TPM, camera) to protect credentials.

Think of it as: Windows Hello is your fingerprint or face scan — proves who you are without needing to type a password.

Key Mechanics: - Biometric or PIN-based authentication - Private key stored in device TPM (Trusted Platform Module) — never leaves device - Strong multi-factor: Something you have (device) + something you are (biometric/PIN) - Works with Entra ID and on-premises AD (Hybrid Microsoft Entra joined devices) - Failure condition: If TPM is not properly provisioned, Windows Hello enrollment fails

Examples

Example 1 — [Success] Employee logs into domain-joined laptop using Windows Hello face recognition. Face scan matched to enrolled biometric. Device uses private key in TPM to create auth token. User signs into Windows and Office 365 without typing password. Seamless, secure authentication.

Example 2 — [Blocked] Company tries to deploy Windows Hello to legacy laptops without TPM. Enrollment fails — TPM is required for secure key storage. Company must either upgrade devices with TPM or use PIN-only (less secure) mode.

Key Mechanisms

- Core function: Windows Hello for Business enables passwordless sign-in using biometric (face, fingerprint) or PIN authentication on Windows devices. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise with Modern Devices

Review Path

Steps:

1. Check Device Requirements - Verify TPM 2.0 installed: tpm.msc - Check for biometric hardware: Device Manager → Biometric devices - Windows 10/11 required - Devices must be domain-joined or Entra-joined

2. Deploy via Group Policy (Hybrid) - Open Group Policy Management Console - Create/edit policy for domain computers - Navigate to Computer Configuration → Administrative Templates → Windows Components → Biometrics → Facial Features - Enable "Allow Facial Recognition Sign-in" and "Require PIN on first use"

3. Enroll Users Manually - Settings → Accounts → Sign-in options → Windows Hello Face/Fingerprint - Click "Set up" for facial recognition or fingerprint - Complete enrollment wizard - Set PIN as backup - Test sign-in

4. Integrate with Entra ID - User signs into device with Windows Hello - Seamless SSO to cloud apps (Entra ID recognizes device) - User does not need to enter credentials again

5. Manage Enrollment - Monitor enrollment via Intune (if using Intune management) - Reset Hello for user if biometric fails: Settings → Reset this device - Ensure all users have PIN fallback

Docs: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/

Explanation

Conditional Access policies enforce security controls based on user, location, device, and sign-in risk signals. They allow organizations to make dynamic access decisions — require MFA for risky sign-ins, block non-compliant devices, restrict access by location. Conditional Access is the primary tool for identity-based security in Entra ID.

Think of it as: Conditional Access is a smart security guard that asks different questions based on who you are and where you are signing in from.

Key Mechanics: - Conditions: User, device, location, application, sign-in risk - Grant controls: Block, Require MFA, Require compliant device, Require approved app - Session controls: Sign-in frequency, browser-only, disabled features - Exclude: Emergency break-glass accounts and service accounts (must exclude) - Exam trap — Block CA wins: Block grant overrides all other grants (most restrictive wins) - Exam trap — break-glass excluded from CA: Emergency access must be excluded

Examples

Example 1 — [Success] Policy: "Block access from outside US." User in France signs in — request blocked (location outside policy). User uses VPN to appear in US — request allowed. Policy working as designed.

Example 2 — [Blocked] Exam trap — Admin creates policy requiring MFA AND block user (contradictory). CA uses most restrictive control (Block) — user blocked, MFA requirement irrelevant. Admin should use OR logic: Require MFA for internal users OR block external users.

Key Mechanisms

- Core function: Conditional Access policies enforce security controls based on user, location, device, and sign-in risk signals. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Enterprise with Strict Security Requirements

Review Path

Steps:

1. Create Basic MFA Policy - Navigate to Entra admin center → Protection → Conditional Access - Click "+ New policy" - Name: "Require MFA for all users" - Assignments → Users: All users (exclude break-glass) - Assignments → Cloud apps: All cloud apps - Grant: Require MFA - Enable policy

2. Block Non-Compliant Devices - New policy: "Block non-compliant devices" - Assignments → Users: All users - Assignments → Conditions → Device state: Any device - Grant: Require device to be Entra-joined AND compliant - Enable policy

3. Require MFA for High-Risk Sign-ins - New policy: "Require MFA for risky sign-ins" - Assignments → Users: All users - Conditions → Sign-in risk: High, Medium - Grant: Require MFA - Enable policy

4. Block Legacy Authentication - New policy: "Block legacy auth" - Assignments → Users: All users - Conditions → Client apps: Exchange ActiveSync, Other clients - Grant: Block - Enable policy

5. TEST BEFORE ENABLING - Create policy in Report-only mode first - Monitor impact for 2-3 days - Switch to Enabled mode after validation

6. Exclude Break-Glass - CRITICAL: All policies must exclude break-glass account - Use group or named users list - Document which accounts are break-glass - Test break-glass can sign in even if CA policies are strict

Docs: https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview

Explanation

Conditional Access session controls restrict what users can do with cloud applications after authentication. They include controls like requiring re-authentication after a period, disabling downloads/copy-paste, enforcing browser-only access, and using app-enforced restrictions to prevent data leakage.

Think of it as: Session controls are rules about what users can do AFTER they sign in — can they download files? Can they copy data? How often must they re-authenticate?

Key Mechanics: - Sign-in frequency: Re-authenticate every N minutes or hours - Browser-only: Force browser access, block desktop apps - App-enforced restrictions: Intune-managed apps apply additional controls (prevents save-as, screenshot, etc.) - Persistent browser session: Keep user signed in on shared devices - Failure condition: If session controls are too restrictive, users cannot work; if too permissive, data leaks

Examples

Example 1 — [Success] Policy: "For SharePoint Online, require re-auth every 1 hour." User signs in, works for 1 hour, attempts to access file. Conditional Access re-auth prompt appears. User enters password, re-authenticated. Works for another hour. Prevents session hijacking.

Example 2 — [Blocked] Policy: "Browser-only for Exchange Online." User tries to use Outlook desktop app — blocked at sign-in (not a browser). User must use Outlook Web Access only. Disruptive but more secure for shared environments.

Key Mechanisms

- Core function: Conditional Access session controls restrict what users can do with cloud applications after authentication. - Category fit: This concept belongs to authentication and sign-in and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: Financial Services Shared Workspace

Review Path

Steps:

1. Configure Sign-in Frequency - Create Conditional Access policy - Name: "Re-auth every 1 hour" - Assignments → Users: Target users/groups - Assignments → Cloud apps: Apps requiring frequent auth - Session → Sign-in frequency: 1 hour - Enable policy

2. Enforce Browser-Only Access - New policy: "Browser-only for sensitive apps" - Assignments → Cloud apps: Exchange, SharePoint - Session → Use app enforced restrictions (browser-only) - Enable policy

3. Set Up App-Enforced Restrictions - Requires Intune or Microsoft 365 Defender - Configure Intune policy: "Block save-as, copy-paste for Teams" - Users on unmanaged devices get restricted experience - Managed devices get normal experience

4. Persistent Browser Session (Shared Devices) - New policy: "Persistent session for shared devices" - Condition: Device marked as shared - Session → Persistent browser session: Enabled - Users stay signed in across browser sessions

5. Test Session Controls - Create policy in Report-only mode - Monitor impact on user workflows - Adjust sign-in frequency based on feedback - Switch to Enabled mode after validation

Docs: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-session

Explanation

Testing Conditional Access means validating that policies block the right users and allow the right ones before full enforcement. Microsoft Entra provides the What If tool to simulate policy evaluation without real user impact, and report-only mode to log what would happen without enforcing it.

Think of it as: A fire drill — you run the scenario to see what the policy would do, without any real consequences, so you can fix gaps before they block real users.

Key Mechanics: - What If tool simulates policy evaluation for any user, app, location, and device state - Report-only mode logs policy outcome (grant/block) but does NOT enforce — users still get access - Sign-in logs show the Conditional Access tab per sign-in with every policy that applied and its result - Failure mode: Enabling a policy without testing can lock out users or leave gaps in enforcement

Examples

Example 1 — [Success] What If confirms correct policy scope An admin runs What If for a finance user accessing Excel from the corporate network. The tool shows Policy A applies (trusted location, device compliant) and grants access with no MFA challenge. Admin confirms the policy is scoped correctly and switches it from report-only to enabled.

Example 2 — [Blocked] Report-only mode misread as enforcement A security team sets a new block policy to report-only and sees sign-in logs showing "Would block." They assume users are blocked. In fact, all users still have full access — report-only never enforces. The policy must be set to "On" before it blocks anything.

Key Mechanisms

- Core function: Testing Conditional Access means validating that policies block the right users and allow the right ones before full enforcement. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] What If confirms correct policy scope - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Entra admin center → Protection → Conditional Access → Policies 2. Open target policy → click What If (top toolbar) 3. Enter: User, Cloud app, IP/location, Device platform, Device compliance state 4. Click What If → review which policies apply and the final decision 5. For pre-rollout validation: set policy State to Report-only 6. After one week → Entra admin center → Sign-in logs → filter by user → Conditional Access tab 7. Verify no unexpected blocks → set policy State to On

Docs: https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access-what-if https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only

Explanation

User risk policies automatically respond when Microsoft Entra Identity Protection detects that a user account may be compromised — for example, when credentials appear in a leaked database. The policy can require a password change or block sign-in until the risk is remediated.

Think of it as: A bank fraud alert — the bank detects unusual account behavior and freezes the card until the customer verifies their identity and resets their PIN.

Key Mechanics: - User risk = cumulative score based on signals like leaked credentials, anomalous behavior patterns - Policy triggers on risk threshold (Low, Medium, High) and applies a grant control (require password change or block) - Remediation: user resets password → risk is dismissed → normal access restored - Failure mode: user risk = HIGH + policy set to block → user cannot sign in until admin dismisses or user remediates

Examples

Example 1 — [Success] Leaked credential detected and remediated Identity Protection flags a user account because credentials appeared in a dark-web dump. User risk policy (threshold: High → require password change) triggers at next sign-in. The user resets their password through SSPR, risk is dismissed, and access is restored without admin intervention.

Example 2 — [Blocked] User risk vs sign-in risk confusion An admin enables a sign-in risk policy thinking it will also catch compromised accounts. A user with leaked credentials (user risk = High) signs in from their usual trusted location — the sign-in risk is Low, so the sign-in policy doesn't trigger. The account remains exposed. User risk policy is the correct control for this scenario.

Key Mechanisms

- Core function: User risk policies automatically respond when Microsoft Entra Identity Protection detects that a user account may be compromised — for example, when credentials appear in a leaked database. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Leaked credential detected and remediated - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Entra admin center → Protection → Identity Protection → User risk policy 2. Assignments → Users: All users (or scoped group) 3. User risk: set threshold (High recommended for start) 4. Controls → Grant: Require password change 5. Enforce policy: On 6. Verify SSPR is enabled so users can self-remediate

Docs: https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks

Explanation

Sign-in risk policies evaluate each individual authentication attempt for suspicious signals — such as anonymous IP addresses, impossible travel, or atypical location — and apply controls like MFA or block in real time at the moment of sign-in.

Think of it as: A hotel front desk that checks every new guest's ID at check-in, regardless of whether they've stayed before, and escalates to the manager if something looks unusual.

Key Mechanics: - Sign-in risk is calculated per-login, not accumulated over time (unlike user risk) - Risk levels: Low / Medium / High — based on signals from Microsoft's threat intelligence - Policy can require MFA (user proves identity) or block entirely at the risky sign-in - Failure mode: Anonymous proxy IP triggers High risk → Block policy → legitimate VPN user also blocked if VPN IP matches threat feed

Examples

Example 1 — [Success] Atypical location triggers MFA and passes A user signs in from a new country while traveling for work. Identity Protection flags the sign-in as Medium risk (atypical location). The sign-in risk policy (threshold: Medium → require MFA) challenges the user. The user completes MFA via Authenticator app and access is granted.

Example 2 — [Blocked] Anonymous proxy blocked, but user on legitimate VPN A developer uses a corporate VPN whose exit node shares an IP address flagged in Microsoft's threat intelligence as an anonymous proxy. Sign-in risk policy (High → Block) fires. The developer cannot sign in. Admin must either add the VPN IP to the trusted location named location list or adjust the policy scope to exclude that group.

Key Mechanisms

- Core function: Sign-in risk policies evaluate each individual authentication attempt for suspicious signals — such as anonymous IP addresses, impossible travel, or atypical location — and apply controls like MFA or block in real time at the moment of sign-in. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Atypical location triggers MFA and passes - Decision clue: Industry: Retail

Review Path

Steps:

1. Entra admin center → Protection → Identity Protection → Sign-in risk policy 2. Assignments → Users: All users (exclude break-glass accounts) 3. Sign-in risk: Medium and above 4. Controls → Grant: Require multi-factor authentication 5. Enforce policy: On 6. Entra admin center → Monitoring → Sign-in logs → filter Conditional Access = Applied

Docs: https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks

Explanation

MFA registration policies in Identity Protection require users to register an MFA method within a defined window. They ensure that users have a second factor on file before a risk event forces an MFA challenge — so the remediation path is available when it's needed.

Think of it as: Requiring new employees to get a building access badge during their first week — so when a security event happens, they already have the credential they need.

Key Mechanics: - Registration policy controls WHO must register, not whether MFA is required at each sign-in - Users who haven't registered are prompted on their next sign-in (within the grace period) - Separate from the MFA requirement policy — a user can be registered but not yet required to use MFA every login - Failure mode: User risk triggers a "require password change + MFA" remediation but the user never registered MFA → remediation cannot complete

Examples

Example 1 — [Success] Staged registration before policy enforcement An admin scopes the MFA registration policy to a pilot group of 200 users two weeks before enabling a sign-in risk policy. All 200 users register Microsoft Authenticator. When the risk policy goes live, every affected user can complete MFA challenges and self-remediate risk events without admin involvement.

Example 2 — [Blocked] Risk event before registration complete A user risk policy (High → require MFA + password change) fires for a new hire who hasn't yet registered MFA. The user cannot complete the MFA step of remediation. Admin must dismiss the risk manually and force a temporary password reset out-of-band so the user can sign in and register.

Key Mechanisms

- Core function: MFA registration policies in Identity Protection require users to register an MFA method within a defined window. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Staged registration before policy enforcement - Decision clue: Industry: Education

Review Path

Steps:

1. Entra admin center → Protection → Identity Protection → MFA registration policy 2. Assignments → Users: All users (or scoped pilot group) 3. Controls: Require Microsoft Entra multifactor authentication registration 4. Enforce policy: On 5. Monitor: Identity Protection → Reports → Registration and reset events

Docs: https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-mfa-policy https://learn.microsoft.com/en-us/entra/identity/authentication/concept-registration-mfa-sspr-combined

Explanation

Investigating identity risks means reviewing flagged sign-ins and user risk events in Identity Protection to determine whether they represent real threats (confirm) or false positives (dismiss). Remediation involves forcing a password reset, revoking tokens, or blocking the user until the threat is resolved.

Think of it as: A security analyst triaging fraud alerts — each alert is either confirmed (act) or dismissed (false alarm), and the decision is logged for audit.

Key Mechanics: - Risky users report: shows accounts with elevated user risk and the detections that triggered it - Risky sign-ins report: shows individual sign-in events flagged as suspicious - Confirm compromise: marks the event as a real threat → user risk stays elevated until remediated - Dismiss risk: marks the event as a false positive → risk score cleared, no forced remediation - Failure mode: Dismissing a real compromise means the attacker retains access with no forced password change

Examples

Example 1 — [Success] Impossible travel confirmed as business travel Identity Protection flags impossible travel for a user (New York at 9 AM, London at 11 AM). Admin investigates sign-in logs: both logins show compliant device, same Authenticator approval. Admin confirms the London login used a personal VPN from a hotel in New York. Admin dismisses the risk as a false positive — no remediation needed.

Example 2 — [Blocked] Confirmed compromise, tokens not revoked A user's credentials appear in a breach dump. Admin confirms the risk and forces a password reset. However, the attacker already obtained a refresh token before the reset. Because token revocation wasn't performed, the attacker continues to access resources using the old token. Remediation must include both password reset and token revocation.

Key Mechanisms

- Core function: Investigating identity risks means reviewing flagged sign-ins and user risk events in Identity Protection to determine whether they represent real threats (confirm) or false positives (dismiss). - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Impossible travel confirmed as business travel - Decision clue: Industry: Legal Services

Review Path

Steps:

1. Entra admin center → Protection → Identity Protection → Risky users 2. Filter by risk level (High) → select user 3. Review: Detections tab (what triggered), Sign-in logs (where/when/device) 4. Decision — Confirm compromise: - Click Confirm user compromised - Block sign-in (user properties → Block sign-in) - Require password reset at next sign-in - Revoke sessions: user → Revoke sessions 5. Decision — Dismiss: click Dismiss user risk → add notes

Docs: https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-investigate-risk https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-remediate-unblock

Explanation

Azure RBAC role assignments grant a security principal (user, group, managed identity, or service principal) the ability to perform specific actions on Azure resources. Each assignment links a principal, a role definition (set of allowed actions), and a scope (subscription, resource group, or individual resource).

Think of it as: Assigning a key card to an employee — the card (role) grants access to specific rooms (scope), and the card holder (principal) can only enter those rooms, not the whole building.

Key Mechanics: - Role assignment = principal + role definition + scope - Scope is hierarchical and inherited downward: subscription → resource group → resource - A role at subscription scope applies to all resource groups and resources below it - Failure mode: Assigning a role at subscription scope instead of resource scope grants broader access than intended — violating least privilege

Examples

Example 1 — [Success] Scoped assignment limits blast radius A developer needs to manage VMs in a single resource group. Admin assigns "Virtual Machine Contributor" role scoped to that resource group only. The developer can create, stop, and delete VMs in that RG but cannot touch VMs in other RGs or modify the subscription itself.

Example 2 — [Blocked] Developer tries to delete resource group The same developer attempts to delete the resource group (requires Contributor or Owner at RG or subscription level). Their "Virtual Machine Contributor" role does not include the Microsoft.Resources/resourceGroups/delete action. Access denied — scope and role definition correctly limit the blast radius.

Key Mechanisms

- Core function: Azure RBAC role assignments grant a security principal (user, group, managed identity, or service principal) the ability to perform specific actions on Azure resources. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Scoped assignment limits blast radius - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. Azure portal → navigate to target scope (subscription / resource group / resource) 2. Access control (IAM) → Add role assignment 3. Role tab: search and select role (e.g., Virtual Machine Contributor) 4. Members tab: select User, group, or service principal → search and add 5. Review + assign 6. Verify: Access control (IAM) → Role assignments tab → confirm assignment appears

Docs: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal https://learn.microsoft.com/en-us/azure/role-based-access-control/overview

Explanation

Custom Azure roles let organizations define exactly which actions a principal can and cannot perform when no built-in role matches the required permission set. A custom role specifies allowed actions (Actions), denied actions (NotActions), and the scopes where it can be assigned.

Think of it as: Writing a custom job description — instead of giving someone a generic "Manager" title with broad authority, you define exactly which decisions they can make and which they cannot.

Key Mechanics: - Actions: list of allowed Microsoft resource provider operations (e.g., Microsoft.Compute/virtualMachines/read) - NotActions: operations excluded from the allowed set — NotActions override Actions (wildcards cannot bypass a NotAction) - AssignableScopes: which subscriptions or resource groups can use this role - Failure mode: Using a wildcard (Microsoft.Compute/*) while assuming a NotAction blocks a specific sub-action — the NotAction always wins, even against a wildcard

Examples

Example 1 — [Success] Backup team scoped to snapshot actions only A backup team needs to create and delete VM snapshots but must not be able to stop or delete VMs themselves. Admin creates a custom role "VM Snapshot Manager" with Actions: Microsoft.Compute/snapshots/* and Microsoft.Compute/virtualMachines/read. NotActions includes Microsoft.Compute/virtualMachines/delete and /deallocate. Team can manage snapshots; VM deletion is blocked.

Example 2 — [Blocked] Wildcard doesn't override NotAction An admin assigns a custom role with Actions: Microsoft.Compute/* (everything) and NotActions: Microsoft.Compute/virtualMachines/delete. A team member tries to delete a VM. Even though the wildcard allows all Compute actions, the NotAction for delete explicitly removes it. Access denied — NotActions always win over wildcards.

Key Mechanisms

- Core function: Custom Azure roles let organizations define exactly which actions a principal can and cannot perform when no built-in role matches the required permission set. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Backup team scoped to snapshot actions only - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Entra admin center or Azure portal → Subscriptions → Access control (IAM) → Add custom role 2. Start from scratch or clone a built-in role 3. Define Basics: name, description 4. Permissions tab: add Actions (search Microsoft resource operations), add NotActions 5. Assignable scopes: add subscription or resource group 6. Review + Create 7. Assign as normal via Access control (IAM) → Add role assignment → select custom role

Docs: https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles-portal

Explanation

Managed identities give Azure resources an identity in Microsoft Entra ID without requiring stored credentials. Azure manages the credential lifecycle automatically. System-assigned identities are tied to a single resource and deleted with it; user-assigned identities are standalone resources that can be shared across multiple services.

Think of it as: A corporate ID badge issued to a service, not a person — the badge is managed by IT (Azure), the employee (the app) just presents it at the door, and IT handles renewals automatically.

Key Mechanics: - System-assigned: one-to-one with the resource, deleted automatically when the resource is deleted - User-assigned: created independently, can be assigned to multiple resources, persists after resource deletion - Once assigned, the identity gets a principal ID used for RBAC role assignments - Failure mode: Assigning a managed identity does not grant it any permissions — a separate RBAC role assignment to the target service is always required

Examples

Example 1 — [Success] System-assigned identity on a function app An Azure Function needs to read secrets from Key Vault. Admin enables system-assigned managed identity on the function. Azure creates a service principal automatically. Admin assigns "Key Vault Secrets User" role to that principal at the Key Vault scope. The function's code uses DefaultAzureCredential() — no connection strings, no secrets in code.

Example 2 — [Blocked] Identity assigned but no role granted A team enables a user-assigned managed identity on an App Service and assigns it to the service. The app code calls the storage account API but gets a 403 Forbidden. The identity exists and is authenticated, but no RBAC role was assigned to it at the storage account. Authorization fails. The fix is a separate role assignment — "Storage Blob Data Reader" — on the storage account.

Key Mechanisms

- Core function: Managed identities give Azure resources an identity in Microsoft Entra ID without requiring stored credentials. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] System-assigned identity on a function app - Decision clue: Industry: Healthcare

Review Path

Steps — System-assigned:

1. Azure portal → target resource (App Service / VM / Function) 2. Identity → System assigned → Status: On → Save 3. Copy Object (principal) ID

Steps — User-assigned: 1. Create managed identity resource: Azure portal → Create resource → User Assigned Managed Identity 2. Name, subscription, resource group → Create 3. Assign to resource: target resource → Identity → User assigned → Add → select identity

Steps — Grant permissions: 4. Target service (Key Vault / Storage / SQL) → Access control (IAM) → Add role assignment 5. Select appropriate role → Managed identity → select the identity → Assign

Docs: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities

Explanation

Using a managed identity to access Azure resources means writing application code that requests an access token using the identity, then presenting that token to the target service (Key Vault, Storage, SQL, etc.) which validates the token and checks the associated RBAC role assignment.

Think of it as: An employee badging into a restricted area — the badge (managed identity token) proves who they are, and the door's access list (RBAC role) determines whether they get in.

Key Mechanics: - DefaultAzureCredential() in Azure SDKs automatically fetches a token from the local managed identity endpoint - The token is scoped to a specific resource — a Key Vault token cannot access Storage - Authorization is checked at the target service using RBAC — authentication and authorization are separate steps - Failure mode: Authentication succeeds (identity is valid) but authorization fails (no RBAC role assigned) → 403 Forbidden

Examples

Example 1 — [Success] Azure Function reads Key Vault secret with no credentials An Azure Function has a system-assigned managed identity with the "Key Vault Secrets User" role at the Key Vault scope. The function's code calls GetSecretAsync() using DefaultAzureCredential(). Azure fetches a token for the function's identity, presents it to Key Vault, and Key Vault returns the secret. No connection string or stored password is involved.

Example 2 — [Blocked] Token obtained but RBAC role missing An App Service with a user-assigned managed identity calls a storage account to read blobs. Authentication succeeds — Azure issues a valid token for the identity. The storage account returns 403 because the identity has no "Storage Blob Data Reader" role at that storage account scope. The fix is an RBAC assignment, not a code change.

Key Mechanisms

- Core function: Using a managed identity to access Azure resources means writing application code that requests an access token using the identity, then presenting that token to the target service (Key Vault, Storage, SQL, etc.) which validates the token and checks the associated RBAC role assignment. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Azure Function reads Key Vault secret with no credentials - Decision clue: Industry: Retail

Review Path

Steps:

1. Ensure managed identity is assigned to the resource (see managed-identities-create) 2. Target service → Access control (IAM) → Add role assignment - Key Vault: Key Vault Secrets User - Storage: Storage Blob Data Reader / Contributor - SQL Database: requires AAD admin + CREATE USER FROM EXTERNAL PROVIDER 3. In application code: use DefaultAzureCredential() (Azure SDK for .NET, Python, Java, JS) 4. Deploy and test — if 403, verify role assignment at correct scope

Docs: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication/

Explanation

Azure Key Vault stores secrets, keys, and certificates. Access is controlled by one of two authorization models: Azure RBAC (recommended for new vaults) assigns standard Azure roles at the Key Vault scope, or legacy Vault Access Policies grant per-principal permissions directly on the vault. The two models are mutually exclusive for data-plane operations.

Think of it as: Choosing between a modern key-card system (RBAC — centrally managed, audited, role-based) versus an old-fashioned physical key list pinned to the wall (access policies — per-person, manually maintained).

Key Mechanics: - RBAC: roles assigned via IAM (Key Vault Secrets User, Secrets Officer, Crypto User, etc.) — managed like any Azure RBAC - Access Policies: principal + permission set (Get, List, Set, Delete) configured directly on the vault - Control plane (managing the vault itself) always uses RBAC regardless of which data-plane model is chosen - Failure mode: App has managed identity but vault uses Access Policies — the identity has no policy entry → 403 even though identity is valid and a role was assigned via IAM

Examples

Example 1 — [Success] RBAC model with managed identity A new Key Vault is created with "Azure role-based access control" selected as the permission model. Admin assigns "Key Vault Secrets User" role to the App Service's managed identity at the vault scope via Access control (IAM). The app calls GetSecretAsync() and retrieves the secret — authorization flows through standard RBAC.

Example 2 — [Blocked] RBAC role assigned but vault uses Access Policies An admin assigns "Key Vault Secrets User" to a managed identity via IAM on an existing vault that is configured for Access Policies. The RBAC role has no effect on the data plane in this mode. The app still gets 403. The fix is either to add an Access Policy entry for the managed identity, or to migrate the vault to RBAC mode.

Key Mechanisms

- Core function: Azure Key Vault stores secrets, keys, and certificates. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] RBAC model with managed identity - Decision clue: Industry: Financial Services

Review Path

Steps — RBAC model (recommended):

1. Key Vault → Settings → Access configuration → Permission model: Azure role-based access control → Apply 2. Key Vault → Access control (IAM) → Add role assignment 3. Select role: Key Vault Secrets User (read) or Secrets Officer (write) 4. Assign to: Managed Identity or User or Service Principal 5. Review + assign 6. Application code: use DefaultAzureCredential() with no explicit credentials

Steps — Access Policy model (legacy): 1. Key Vault → Access policies → Add access policy 2. Secret permissions: Get, List (minimum) 3. Select principal: user, group, or managed identity 4. Add → Save

Docs: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide https://learn.microsoft.com/en-us/azure/key-vault/general/security-features

Explanation

Microsoft Entra Private Access provides Zero Trust, per-application access to private (on-premises or cloud-hosted) resources without a traditional VPN. Users connect through a cloud gateway using the Global Secure Access client, with Conditional Access enforcing identity and device posture at the tunnel level.

Think of it as: A doorman at a private club who checks your membership card and ID (Conditional Access) before letting you in — not a front gate key that opens the entire campus network.

Key Mechanics: - Per-app access: each application or resource is defined with its own access rule — users cannot reach anything not explicitly allowed - Replaces VPN "connect to the network" model with "connect to this specific app" model - Conditional Access policies evaluate at tunnel establishment, before the user reaches the private resource - Failure mode: Device fails compliance check → Conditional Access blocks tunnel → no private apps accessible, even if the user has valid credentials

Examples

Example 1 — [Success] Remote contractor gets access to one app only A contractor needs access to a single internal expense reporting tool. Admin creates a Private Access app segment for that tool's IP and port only. Contractor installs the GSA client, signs in, and accesses the expense tool. No other internal resources are reachable because no additional app segments are defined for that user group.

Example 2 — [Blocked] Non-compliant device blocked at tunnel A remote employee's laptop fails its Intune compliance check (OS update missing). The Conditional Access policy scoped to Private Access requires device compliance. When the employee tries to connect, the GSA client attempts tunnel establishment — CA evaluates device state → non-compliant → tunnel denied. The employee cannot reach any private app until the OS update is applied and compliance is reasserted.

Key Mechanisms

- Core function: Microsoft Entra Private Access provides Zero Trust, per-application access to private (on-premises or cloud-hosted) resources without a traditional VPN. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Remote contractor gets access to one app only - Decision clue: Industry: Legal Services

Review Path

Steps:

1. Entra admin center → Global Secure Access → Applications → Enterprise applications 2. New application → Private Access application 3. Add app segment: FQDN or IP, port, protocol 4. Assign users or groups 5. Create Conditional Access policy: Cloud apps → Global Secure Access → Conditions → Device compliance → Grant 6. Deploy GSA client to user devices via Intune (Apps → Add → Global Secure Access Client)

Docs: https://learn.microsoft.com/en-us/entra/global-secure-access/concept-private-access https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-private-access-app

Explanation

Traffic forwarding profiles in Global Secure Access define which network traffic is routed through Microsoft's cloud gateway for inspection and policy enforcement. Each profile type (Microsoft 365, Private Access, Internet Access) captures a specific traffic category and routes it through the GSA cloud fabric.

Think of it as: Traffic lanes on a highway — you designate certain lanes (profiles) for specific vehicle types (traffic categories), and only vehicles in those lanes are inspected at the toll booth (cloud gateway).

Key Mechanics: - Microsoft 365 profile: routes M365 traffic through the gateway for optimized, policy-enforced delivery - Private Access profile: routes traffic destined for defined private app segments - Internet Access profile: routes general internet traffic for threat inspection and web filtering - Forwarding profiles route traffic — blocking happens at Conditional Access or app-level policies, not in the profile itself - Failure mode: Traffic not matched by any profile goes direct — unprotected — if the policy requires gateway inspection for all traffic

Examples

Example 1 — [Success] Corporate app traffic routed, internet traffic direct Admin creates a forwarding profile for private corporate app IPs only. User browses YouTube (not in profile) — traffic goes direct to internet, no gateway overhead. User accesses the internal ERP system (IP in profile) — traffic routes through the cloud gateway, Conditional Access evaluates, and the connection is established.

Example 2 — [Blocked] Profile routes traffic but CA policy blocks the tunnel Admin adds the internal HR system to a forwarding profile. A CA policy requires MFA for Private Access. A contractor signs in but has no MFA method registered. Traffic matches the profile and is forwarded to the gateway. CA evaluates at tunnel establishment — MFA required but not available — tunnel blocked. The forwarding profile did its job; the block came from CA, not the profile.

Key Mechanisms

- Core function: Traffic forwarding profiles in Global Secure Access define which network traffic is routed through Microsoft's cloud gateway for inspection and policy enforcement. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Corporate app traffic routed, internet traffic direct - Decision clue: Industry: Technology

Review Path

Steps:

1. Entra admin center → Global Secure Access → Traffic forwarding 2. Select profile type: Microsoft 365 / Private Access / Internet Access 3. Enable the profile toggle 4. Private Access: add app segments (FQDN / IP range + port + protocol) 5. Internet Access: configure URL categories and exceptions 6. Assign to: connector policies or all GSA clients 7. Monitor: Global Secure Access → Monitor → Traffic logs

Docs: https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-traffic-profiles https://learn.microsoft.com/en-us/entra/global-secure-access/concept-traffic-forwarding

Explanation

Conditional Access policies targeting Global Secure Access evaluate identity, device, and risk signals at the moment a user's GSA client attempts to establish a tunnel. Passing CA grants tunnel access; failing CA blocks the tunnel, which blocks all private resources reachable through it.

Think of it as: Border control at an airport — your ticket (credentials) and passport (device) are both checked before you board the plane (tunnel). One failure = denied boarding, regardless of which destination you're flying to.

Key Mechanics: - CA policy cloud app target: "Global Secure Access" (a specific app in the CA app picker) - CA evaluates at tunnel establishment, not per-request inside the tunnel - Device compliance, sign-in risk, and MFA are the most common controls for GSA - Failure mode: A CA policy scoped to GSA with "block" grant will block ALL private apps for affected users — not just one app

Examples

Example 1 — [Success] Compliant device passes CA and gets tunnel A remote employee opens the GSA client on an Intune-enrolled, compliant Windows laptop. CA policy: "Require device compliance for Global Secure Access" — evaluates: device is compliant → tunnel allowed. All assigned private apps are accessible through the established tunnel.

Example 2 — [Blocked] CA blocks tunnel, all private apps unreachable An admin creates a CA policy blocking non-compliant devices from Global Secure Access. A contractor using a personal, non-enrolled device attempts to connect. CA evaluates: device is not managed/compliant → tunnel blocked. The contractor receives an error from the GSA client and cannot reach any private application — including apps they had explicit assignments for — because no tunnel was established.

Key Mechanisms

- Core function: Conditional Access policies targeting Global Secure Access evaluate identity, device, and risk signals at the moment a user's GSA client attempts to establish a tunnel. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Compliant device passes CA and gets tunnel - Decision clue: Industry: Government

Review Path

Steps:

1. Entra admin center → Protection → Conditional Access → New policy 2. Name: e.g., "Require compliant device for Private Access" 3. Assignments → Users: target group (exclude break-glass accounts) 4. Cloud apps: Global Secure Access 5. Conditions: - Device platforms: select Windows (and others as needed) - Filter for devices: Intune compliant = true (or use device compliance grant) 6. Grant: Require device to be marked as compliant 7. Enable policy (start with Report-only to validate)

Docs: https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-conditional-access-for-global-secure-access https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps

Explanation

The Global Secure Access client is a lightweight agent installed on user devices that intercepts network traffic matching configured forwarding profiles and routes it through Microsoft's cloud gateway. It is managed centrally via Intune and supports Windows, macOS, iOS, and Android.

Think of it as: A traffic routing app on a device — invisible to the user, automatically routing corporate traffic through the secure cloud lane while leaving personal traffic on the normal road.

Key Mechanics: - Client routes only traffic matching forwarding profiles — other traffic goes direct (not a full VPN) - Device must be Entra-registered or Entra-joined for the client to authenticate - Intune manages client deployment, updates, and policy delivery - Failure mode: Client installed but device is not Entra-registered → client cannot authenticate → no traffic routed through gateway

Examples

Example 1 — [Success] Client deployed via Intune, traffic automatically secured Admin deploys the GSA Windows client to all remote workers via Intune app deployment policy. Client installs silently, starts automatically at Windows login, authenticates using the device's Entra identity, and begins routing private app traffic through the cloud gateway per the configured forwarding profiles. Users notice no change in their workflow.

Example 2 — [Blocked] Client installed but device not Entra-registered A contractor installs the GSA client on a personal Windows laptop. The client starts but cannot authenticate because the device is not Entra-registered or Intune-enrolled. The client shows an authentication error and no traffic is forwarded. The fix requires the device to be Entra-registered (or the contractor to use a managed device).

Key Mechanisms

- Core function: The Global Secure Access client is a lightweight agent installed on user devices that intercepts network traffic matching configured forwarding profiles and routes it through Microsoft's cloud gateway. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Client deployed via Intune, traffic automatically secured - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Intune → Apps → All Apps → Add application 2. App type: Windows app (Win32) or search Microsoft Global Secure Access 3. Assign to device group → Deployment: Required 4. Configure app settings: forwarding profiles, CA policies 5. Monitor deployment: Intune → Monitor → App install status 6. Verify on device: taskbar GSA icon → Connected status

Docs: https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-install-windows-client https://learn.microsoft.com/en-us/entra/global-secure-access/concept-clients

Explanation

Global Secure Access Internet Access routes user web traffic through Microsoft's cloud gateway, where it is inspected for threats, filtered against web categories, and logged for compliance. It replaces on-premises proxy appliances with a cloud-native security layer for internet-bound traffic.

Think of it as: Replacing a physical security checkpoint at the building exit with a cloud checkpoint that every employee's traffic passes through on the way to the internet — regardless of where the employee is physically located.

Key Mechanics: - Separate from Private Access — Internet Access is its own forwarding profile covering public internet traffic - Web category filtering blocks or allows traffic by content category (social media, gambling, malware, etc.) - Microsoft threat intelligence blocks known malicious domains and phishing URLs in real time - Failure mode: Internet Access profile enabled but GSA client not deployed → traffic does not route through gateway → filtering has no effect

Examples

Example 1 — [Success] Phishing site blocked by threat intelligence An employee clicks a phishing link in an email. The GSA client routes the web request through the Internet Access gateway. Microsoft's threat intelligence identifies the URL as a known phishing domain. The gateway blocks the request and returns a block page. The employee's endpoint is never exposed to the malicious site.

Example 2 — [Blocked] Web filter blocks legitimate security research tool A security analyst needs to access a dark-web monitoring site for threat research. The Internet Access profile's web category filter blocks the "Hacking Tools" category, which includes the site. The analyst cannot access it. The fix is to create a URL exception for the specific tool in the filtering policy, scoped to the security team group.

Key Mechanisms

- Core function: Global Secure Access Internet Access routes user web traffic through Microsoft's cloud gateway, where it is inspected for threats, filtered against web categories, and logged for compliance. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Phishing site blocked by threat intelligence - Decision clue: Industry: Education

Review Path

Steps:

1. Entra admin center → Global Secure Access → Internet access 2. Enable Internet access forwarding profile toggle 3. Web content filtering → Create policy - Add rule: action = Block, categories = Adult, Gambling, Malware - Add exception rules for specific allowed domains 4. Link policy to a filtering profile 5. Assign filtering profile to users or devices 6. Monitor: Global Secure Access → Monitor → Traffic logs → filter: Internet access

Docs: https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-internet-access https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-web-content-filtering

Explanation

Assigning a managed identity to an Azure resource is the first of two required steps to enable credential-free service access. The assignment creates a service principal for the resource in Microsoft Entra ID. A separate RBAC role assignment on the target service is then required to authorize what the identity can do.

Think of it as: Issuing an employee ID to a service — the ID card (identity) proves who the service is, but the ID card alone doesn't open any doors. The access list (RBAC role) at each door must also include the ID.

Key Mechanics: - System-assigned: enabled on the resource itself, auto-deleted when resource is deleted - User-assigned: created as a standalone Azure resource, assigned to one or more services - After assignment, the resource's Object (principal) ID is used for all subsequent RBAC assignments - Failure mode: Identity is assigned, application runs with DefaultAzureCredential() — but no RBAC role exists at the target → 403 Forbidden at the target service, not at authentication

Examples

Example 1 — [Success] System-assigned identity on VM enables Key Vault access An admin enables system-assigned managed identity on an Azure VM. Azure creates a service principal in Entra ID. Admin copies the principal ID, navigates to Key Vault, and assigns "Key Vault Secrets User" to that principal. A script running on the VM calls Get-AzKeyVaultSecret using Connect-AzAccount -Identity — no password required.

Example 2 — [Blocked] Identity assigned, role missing at SQL Database A team enables a user-assigned managed identity on an App Service and assigns it to the service. The app's connection string uses managed identity authentication for SQL Database. The app starts but all database calls return "Login failed for user." The managed identity has no role or user mapping in the SQL Database. Identity assignment (step 1) was completed; role/user grant (step 2) was skipped.

Key Mechanisms

- Core function: Assigning a managed identity to an Azure resource is the first of two required steps to enable credential-free service access. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] System-assigned identity on VM enables Key Vault access - Decision clue: Industry: Energy

Review Path

Steps — Assign identity:

1. Azure portal → target resource → Identity 2. System assigned: Status = On → Save → copy Object ID OR User assigned: Add → select existing managed identity 3. Navigate to target service (Key Vault / Storage / SQL) 4. Access control (IAM) → Add role assignment 5. Role: select appropriate role for target service 6. Members: Managed identity → select the identity → Review + assign

Docs: https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities

Explanation

Configuring managed identity access to resources means assigning the correct RBAC role at the right scope so the identity is authorized to perform specific actions. This is the authorization step that follows identity assignment — authentication and authorization are always separate operations.

Think of it as: After issuing the employee ID badge, you must also program it into the door's access list with the specific rooms allowed — the badge alone does nothing without the access list entry.

Key Mechanics: - Role selection: use the most specific role that meets the requirement (Secrets User over Secrets Officer if read-only is sufficient) - Scope selection: resource scope > resource group scope > subscription scope — narrower scope = better least privilege - Role assignments at RG scope apply to all resources in the RG — this can be broader than intended - Failure mode: Role assigned at subscription scope when resource scope was intended → identity can access all resources of that type across the subscription

Examples

Example 1 — [Success] Least-privilege role at resource scope An Azure Function needs to read blobs from one specific storage account. Admin assigns "Storage Blob Data Reader" to the function's managed identity scoped specifically to that storage account — not the resource group, not the subscription. The function reads blobs from that account only; it cannot access any other storage account.

Example 2 — [Blocked] Role scoped too broadly causes compliance violation An admin assigns "Storage Blob Data Contributor" to a managed identity scoped at the resource group level, intending to grant access to one storage account. A compliance audit finds the identity also has write access to two other storage accounts in the same resource group. The fix is to remove the RG-level assignment and re-assign at individual storage account scope.

Key Mechanisms

- Core function: Configuring managed identity access to resources means assigning the correct RBAC role at the right scope so the identity is authorized to perform specific actions. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Least-privilege role at resource scope - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Navigate to target resource (Key Vault / Storage Account / SQL etc.) 2. Access control (IAM) → Add role assignment 3. Role tab: search and select the appropriate role - Key Vault Secrets User for secret reads - Storage Blob Data Reader for blob reads 4. Members tab: Managed identity → select identity by name 5. Scope: ensure the assignment target is the specific resource, not RG or subscription 6. Review + assign 7. Verify in Access control (IAM) → Role assignments tab

Docs: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices

Explanation

A service principal is the identity object created in a Microsoft Entra tenant when an application needs to authenticate and access resources. It represents the application instance in that tenant — separate from the app registration, which is the definition. Service principals use client secrets or certificates to prove their identity to Entra ID.

Think of it as: An app registration is the job description on file; the service principal is the actual employee hired from that description — the entity that shows up, presents credentials, and does work.

Key Mechanics: - App registration (one per app, one tenant) → creates a service principal (one per tenant where the app is used) - Service principal authenticates using: client secret (password-like) or certificate (more secure) - Service principal is then authorized by RBAC role assignments at Azure resource scopes - Failure mode: App permissions (application permissions in Graph) always require admin consent — user consent alone is insufficient for service-level access

Examples

Example 1 — [Success] DevOps pipeline uses service principal to deploy An admin creates an app registration for the CI/CD pipeline, adds a client secret, and assigns "Contributor" role to the service principal at the subscription scope. The pipeline authenticates with client ID + secret, receives a token, and deploys Azure resources as the service principal's identity.

Example 2 — [Blocked] Service principal authenticated but RBAC missing A third-party SaaS tool has a service principal in the tenant with admin consent for Microsoft Graph API permissions. The tool tries to write to a specific Azure Storage account via REST API. Graph permissions are unrelated to Azure Storage RBAC — the tool gets 403. Azure Storage access requires a separate RBAC role assignment on the storage account for the service principal's object ID.

Key Mechanisms

- Core function: A service principal is the identity object created in a Microsoft Entra tenant when an application needs to authenticate and access resources. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] DevOps pipeline uses service principal to deploy - Decision clue: Industry: Technology

Review Path

Steps:

1. Entra admin center → Applications → App registrations → New registration 2. Name, supported account types → Register 3. API permissions → Add permission → Microsoft Graph → Application → select permissions 4. Grant admin consent (required for Application permissions) 5. Certificates & secrets → New client secret → set expiry → copy value (shown once) 6. Note: Application (client) ID and Directory (tenant) ID 7. Assign RBAC roles at Azure resources if needed: resource → IAM → assign to service principal

Docs: https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal

Explanation

Workload identity credentials — client secrets, certificates, and federated credentials — authenticate service principals and managed identities to Entra ID. Client secrets are password-like strings with expiry dates. Certificates use asymmetric cryptography. Federated credentials allow external identity providers (GitHub, Kubernetes) to authenticate without any shared secret stored in Azure.

Think of it as: Three ways to prove your identity at a border: a password (secret — simple but can be stolen), a biometric passport (certificate — harder to forge), or a trusted foreign government's clearance letter (federation — no direct secret, just mutual trust).

Key Mechanics: - Client secrets expire and must be rotated — expiry without rotation breaks authentication silently - Certificates: public key uploaded to app registration; private key stays on the application server - Workload identity federation: external OIDC token (from GitHub Actions, Kubernetes, etc.) is exchanged for an Entra token — no Azure secret is ever stored externally - Failure mode: Client secret expires without rotation → all authentication from that app breaks at expiry, often in production

Examples

Example 1 — [Success] GitHub Actions deploys Azure resources without stored secrets Admin creates a federated credential on an app registration: issuer = https://token.actions.githubusercontent.com, subject = repo:org/repo:ref:refs/heads/main. GitHub Actions workflow uses the Azure Login action with client_id, tenant_id, and subscription_id only — no client_secret. GitHub's OIDC token is exchanged for an Entra token. Deployment proceeds with no Azure credential stored in GitHub Secrets.

Example 2 — [Blocked] Client secret expires silently in production A service principal used by a data pipeline has a client secret that expires on a weekend. No rotation alert was configured. At expiry, all pipeline authentication fails — the pipeline cannot obtain a token. Data ingestion stops. The fix is to create a new secret, update the pipeline config, and implement a Defender for Cloud or Entra expiry alert to prevent recurrence.

Key Mechanisms

- Core function: Workload identity credentials — client secrets, certificates, and federated credentials — authenticate service principals and managed identities to Entra ID. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] GitHub Actions deploys Azure resources without stored secrets - Decision clue: Industry: Software Development

Review Path

Steps — Client secret:

1. Entra admin center → Applications → App registrations → select app 2. Certificates & secrets → New client secret → set description + expiry → Add 3. Copy value immediately (shown once) 4. Store in Key Vault or pipeline secret store

Steps — Federated credential (GitHub): 1. Same app registration → Certificates & secrets → Federated credentials → Add credential 2. Scenario: GitHub Actions 3. Organization, repository, entity type (Branch / Environment), identifier 4. Add → use client-id and tenant-id in GitHub Actions workflow (no secret)

Docs: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation https://learn.microsoft.com/en-us/entra/identity-platform/certificate-credentials

Explanation

Enterprise applications in Microsoft Entra represent instances of SaaS and on-premises applications integrated with the tenant. Configuration covers user and group assignment (who can access), single sign-on (how users authenticate), provisioning (automated account lifecycle), and Conditional Access (access policies).

Think of it as: The admin control panel for each app in your organization's app library — you configure who gets in, how they sign in, whether their account is auto-created, and what security checks apply.

Key Mechanics: - Assignment required: if enabled, only explicitly assigned users/groups can access the app — unassigned users see "Need access" errors - SSO: SAML (most SaaS apps), OIDC, or password-based — the protocol determines what attributes are mapped in the token - SCIM provisioning: automated account creation/deactivation in the SaaS app when users are added/removed from the assignment - Failure mode: Admin consent was granted for API permissions but user assignment was not configured → users cannot access the app even though the app has correct permissions

Examples

Example 1 — [Success] Salesforce SSO and provisioning fully configured Admin adds Salesforce from the Entra gallery, configures SAML SSO (IdP metadata exchanged between Entra and Salesforce), maps user attributes (email, first name, last name, role), enables SCIM provisioning with Salesforce admin credentials, and assigns the Sales Team group. New sales hires added to the group are auto-provisioned in Salesforce with correct attributes and role.

Example 2 — [Blocked] Assignment required but user not assigned A user opens their My Apps portal and clicks ServiceNow. They receive "You don't have access to this application." ServiceNow's enterprise app has "Assignment required" enabled and the user is not in any assigned group. Admin must add the user or their group to the enterprise app's Users and groups assignment before access is possible.

Key Mechanisms

- Core function: Enterprise applications in Microsoft Entra represent instances of SaaS and on-premises applications integrated with the tenant. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Salesforce SSO and provisioning fully configured - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Entra admin center → Applications → Enterprise applications → select app 2. Users and groups → Add user/group → assign 3. Single sign-on → select protocol (SAML most common) - Download Entra SAML metadata → upload to SaaS app - Configure Attribute mappings 4. Provisioning → Provisioning Mode: Automatic - Admin credentials: SCIM endpoint + secret token from SaaS app - Attribute mappings → verify field alignment - Start provisioning 5. Test: click Test this application as a pilot user

Docs: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal https://learn.microsoft.com/en-us/entra/identity/app-provisioning/user-provisioning

Explanation

Microsoft Entra built-in roles for application management delegate the ability to create, configure, and assign applications within Entra ID — without requiring Global Administrator. The key roles are Application Administrator, Cloud Application Administrator, and Application Developer, each with a different scope of authority.

Think of it as: Delegated department manager roles — an Application Administrator is like a department head who manages all apps, while a Cloud Application Administrator is a deputy who handles specific apps but cannot touch certain infrastructure settings.

Key Mechanics: - Application Administrator: full app management — create app registrations, manage enterprise apps, configure SSO, manage proxy - Cloud Application Administrator: same as above but cannot manage Application Proxy connector settings - Application Developer: can create app registrations for themselves but cannot consent to permissions or manage enterprise apps - Failure mode: Assigning Application Administrator thinking it is scoped to one app — Entra roles are tenant-wide, not per-app scoped; the admin gets authority over ALL apps

Examples

Example 1 — [Success] App owner gets Cloud Application Administrator An IT team assigns "Cloud Application Administrator" to each SaaS app owner. Each owner can configure SSO, manage user assignments, and update provisioning for their apps. They cannot create new app proxy connectors or modify authentication policies — capabilities that remain with the security team holding Application Administrator.

Example 2 — [Blocked] Application Developer cannot consent to permissions A developer is assigned "Application Developer" and creates a new app registration. They add Microsoft Graph API permissions (User.Read.All) and attempt to grant admin consent. The consent button requires Application Administrator or Global Administrator — Application Developer cannot grant consent. A higher-privileged admin must review and grant consent.

Key Mechanisms

- Core function: Microsoft Entra built-in roles for application management delegate the ability to create, configure, and assign applications within Entra ID — without requiring Global Administrator. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] App owner gets Cloud Application Administrator - Decision clue: Industry: Retail

Review Path

Steps:

1. Entra admin center → Roles and administrators 2. Search role: Cloud Application Administrator (or Application Administrator) 3. Click role → Add assignments → select user or group 4. Assign 5. Verify: user properties → Assigned roles tab

Docs: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/delegate-app-roles

Explanation

Microsoft Entra Application Proxy provides authenticated remote access to on-premises web applications through a cloud-hosted reverse proxy. Lightweight connectors installed on-premises make outbound connections to Azure — no inbound firewall rules needed. Users access apps via a cloud URL, authenticated through Entra ID with Conditional Access enforcement.

Think of it as: A reception desk at a company's cloud address that forwards visitor calls to internal offices — the internal offices never expose their direct numbers (IP addresses), and the reception desk handles identity verification before forwarding.

Key Mechanics: - Connectors: installed on on-premises Windows servers, make outbound HTTPS connections to Azure — no inbound ports needed - External URL: published cloud address users access (e.g., https://app-proxy.company.com) - Internal URL: actual on-premises app address the connector reaches (e.g., http://internalapp.corp) - Failure mode: Connector installed but running under a low-privilege account — connector cannot reach the internal app or register with Azure → proxy fails silently

Examples

Example 1 — [Success] SharePoint on-premises accessed remotely without VPN Admin installs Application Proxy connector on an on-premises Windows Server. Publishes internal SharePoint (http://sharepoint.corp) as https://sharepoint.company.com. Users outside the office navigate to the proxy URL, authenticate via Entra ID SSO, and access SharePoint — the connector routes the request to the internal server. No VPN client is required.

Example 2 — [Blocked] Connector health failure stops all access An on-premises server hosting the Application Proxy connector is rebooted but the connector service does not restart automatically. All requests to the published app fail — Entra Admin Center shows the connector group as unhealthy. Users see a 502 Bad Gateway error. Fix: restart connector service or deploy a second connector for redundancy.

Key Mechanisms

- Core function: Microsoft Entra Application Proxy provides authenticated remote access to on-premises web applications through a cloud-hosted reverse proxy. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] SharePoint on-premises accessed remotely without VPN - Decision clue: Industry: Government

Review Path

Steps:

1. Entra admin center → Application Proxy → download connector 2. Install connector on on-premises domain-joined server (run as admin) 3. Connector registers with Entra ID — verify in Application Proxy → Connectors 4. Application Proxy → New application - Internal URL: http://internal-app.domain.local - External URL: auto-generated or custom domain - Pre-Authentication: Microsoft Entra ID - SSO: None / Kerberos / Header-based (depends on app) 5. Users and groups → assign users/groups 6. Create CA policy targeting the published app

Docs: https://learn.microsoft.com/en-us/entra/identity/app-proxy/what-is-application-proxy https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-deployment-plan

Explanation

Integrating SaaS applications with Microsoft Entra ID enables single sign-on, automated user provisioning, and centralized access control for cloud business applications. Integration uses SSO protocols (SAML, OIDC) for authentication, SCIM for provisioning, and Entra assignment for access control.

Think of it as: Connecting all your building's door card readers to one central identity system — one ID card (Entra account) opens all doors (SaaS apps), and when someone leaves, disabling one card removes access everywhere.

Key Mechanics: - Gallery apps: pre-configured SAML/OIDC settings, many with SCIM provisioning support — faster setup - Non-gallery apps: manual SSO configuration using SAML metadata exchange - Provisioning requires app admin credentials (API token/SCIM endpoint) — Entra calls the app's API to create accounts - Failure mode: SSO configured and working, but provisioning not enabled → users can SSO but their app account doesn't exist yet → app-side "user not found" error

Examples

Example 1 — [Success] Slack integrated with SSO and provisioning Admin adds Slack from the Entra gallery, configures SAML SSO by exchanging metadata with Slack's admin portal, maps email and display name attributes, enables SCIM provisioning with Slack API token, and assigns the All Employees group. New hires added to Active Directory are synced to Entra, auto-provisioned in Slack, and can SSO on day one.

Example 2 — [Blocked] SSO works but user has no Slack account A new hire uses Slack's SSO login. Entra authenticates the user and issues a SAML assertion. Slack validates the assertion but cannot find a matching user account — SCIM provisioning was not enabled. Slack returns "User not found." The admin must either enable provisioning or manually create the user in Slack before SSO can complete successfully.

Key Mechanisms

- Core function: Integrating SaaS applications with Microsoft Entra ID enables single sign-on, automated user provisioning, and centralized access control for cloud business applications. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Slack integrated with SSO and provisioning - Decision clue: Industry: Technology

Review Path

Steps:

1. Entra admin center → Enterprise applications → New application → search gallery 2. Add application → Single sign-on → SAML 3. Download Federation Metadata XML → upload to SaaS app's SSO settings 4. Copy app's SAML metadata URL → paste into Entra SSO config 5. Attribute mappings: verify email, displayName, identifier mapping 6. Test SSO with a pilot user 7. Provisioning → Automatic → enter admin credentials (SCIM endpoint + token) → Test Connection → Save 8. Users and groups → assign target groups → Start provisioning

Docs: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/overview https://learn.microsoft.com/en-us/entra/identity/app-provisioning/user-provisioning

Explanation

Application access in Microsoft Entra is controlled by assigning users, groups, or app roles to enterprise applications. Group-based assignment scales access management across populations; app role assignment maps Entra users to application-specific roles that are passed in the SSO token for the app to enforce.

Think of it as: A VIP list for each club (app) — you can add individuals (direct user assignment), add a reservation for a group (group assignment), or designate a table with a specific section (app role) that the app uses to determine what the user can do inside.

Key Mechanics: - Direct user assignment: one-to-one, most granular, least scalable - Group assignment: add/remove users from the group to grant/revoke app access at scale - App roles: defined in the app registration manifest, assigned to users/groups — role value passed in the SAML/OIDC token for the app to consume - Failure mode: "Assignment required" is on, user is in a group, but the group is not assigned to the app — user gets "Need access" error even though they are in a group

Examples

Example 1 — [Success] Group assignment with app role mapping Admin assigns "Salesforce Users" group to Salesforce enterprise app with app role "Standard User" and "Salesforce Admins" group with app role "Administrator." When users sign in via SSO, the SAML assertion includes their role. Salesforce reads the role claim and grants appropriate access level — no manual role management inside Salesforce needed.

Example 2 — [Blocked] Group exists but not assigned to the app A new employee is added to the "Marketing Team" security group. The Marketing Team group is not assigned to the Marketo enterprise app — only "Marketing Power Users" is assigned. The new employee opens Marketo and receives "You don't have access to this application." Admin must either assign the Marketing Team group to Marketo or add the user directly.

Key Mechanisms

- Core function: Application access in Microsoft Entra is controlled by assigning users, groups, or app roles to enterprise applications. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Group assignment with app role mapping - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Entra admin center → Enterprise applications → select app 2. Users and groups → Add user/group 3. Select Users or Groups → search and select 4. Select role (if app has app roles defined) → Assign 5. To define app roles: App registrations → select app → App roles → Create app role - Display name, Value (what the app reads in the token), allowed member types 6. To assign roles: return to Enterprise application → Users and groups → select user/group → edit assignment → select role

Docs: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/assign-user-or-group-access-portal https://learn.microsoft.com/en-us/entra/identity-platform/howto-add-app-roles-in-apps

Explanation

Consent controls determine which Entra users can authorize applications to access organizational data via Microsoft Graph or other APIs. User consent allows individuals to authorize low-risk delegated permissions for themselves. Admin consent allows admins to authorize permissions organization-wide — required for high-risk delegated permissions and all application permissions.

Think of it as: A building's visitor policy — regular employees can invite guests to the lobby (user consent for low-risk access), but only security can authorize a guest to access restricted floors (admin consent for high-risk or service-level access).

Key Mechanics: - Delegated permissions: app acts on behalf of the signed-in user — user can consent if the permission is low-risk and policy allows it - Application permissions: app acts as itself with no user context — always requires admin consent - Consent policy: configured in Entra to allow user consent (for verified publishers only, or all), require admin approval, or block entirely - Failure mode: User consent disabled org-wide for security reasons → user installs a legitimate productivity app → no admin consent workflow set up → users stuck, app unusable

Examples

Example 1 — [Success] Admin pre-consents for org-wide app access A company wants all employees to use a productivity add-in that reads their calendar. Admin reviews the app's requested permissions (Calendars.Read — delegated), finds them appropriate, grants admin consent in Entra. All users can now use the add-in without being prompted to consent themselves — the admin approved on behalf of the organization.

Example 2 — [Blocked] App requests application permission, user cannot consent A developer registers an app that requests User.Read.All as an Application permission (reads all user profiles). A non-admin user installs the app and tries to grant consent. The consent screen shows an error: "This app requires admin approval." Application permissions always require an admin to review and grant consent — user consent is never sufficient regardless of the consent policy setting.

Key Mechanisms

- Core function: Consent controls determine which Entra users can authorize applications to access organizational data via Microsoft Graph or other APIs. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Admin pre-consents for org-wide app access - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Entra admin center → Enterprise applications → Consent and permissions → User consent settings 2. Set policy: "Allow user consent for verified publishers" OR "Do not allow user consent" 3. Admin consent requests → Enabled → add designated reviewer roles/users 4. To grant admin consent for a specific app: - Enterprise applications → select app → Permissions → Grant admin consent OR - App registrations → select app → API permissions → Grant admin consent for [tenant] 5. Monitor: Enterprise applications → Permissions → review all consented permissions per app

Docs: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-user-consent https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow

Explanation

Application collections in Microsoft Entra allow admins to group enterprise applications into logical sets visible in the My Apps portal. Collections improve user experience by organizing apps by department, workflow, or project — they are a UX tool, not an access control mechanism.

Think of it as: Creating folders in your email inbox — the folders organize your messages for easier navigation, but who can read the messages is still controlled by who the email was sent to, not which folder it's in.

Key Mechanics: - Collections are visible in the My Apps portal (myapps.microsoft.com) - A collection can be scoped to specific users or groups — those users see the collection; others do not - The actual access to each app is still controlled by the enterprise app's user and group assignments — not the collection - Failure mode: Admin creates a "Finance" collection and assumes Finance users now have access to the apps in it — access still requires assignment in each individual enterprise app

Examples

Example 1 — [Success] New employee onboarding collection Admin creates an "Onboarding Essentials" collection containing email, Teams, HR portal, and the training platform. The collection is assigned to the "New Hires" group. New employees see this curated collection in My Apps on day one, making it easy to find their essential tools without searching through a long app list.

Example 2 — [Blocked] Collection visible but app access denied A user sees the "Finance Apps" collection in My Apps and clicks QuickBooks. They receive "You don't have access to this application." The collection made QuickBooks visible, but the user was never assigned to the QuickBooks enterprise app. Collections control visibility in the portal; assignment controls actual access.

Key Mechanisms

- Core function: Application collections in Microsoft Entra allow admins to group enterprise applications into logical sets visible in the My Apps portal. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] New employee onboarding collection - Decision clue: Industry: Retail

Review Path

Steps:

1. Entra admin center → My Apps → Collections → New collection 2. Name and description (e.g., "Finance Department Apps") 3. Apps tab: search and add enterprise applications 4. Owners tab: assign collection owners who can manage it 5. Users and groups tab: assign groups that see this collection (optional — leave empty for all users) 6. Review + Create 7. Users see collection at myapps.microsoft.com after next sign-in

Docs: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/access-panel-collections https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/my-apps-deployment-plan

Explanation

An app registration in Microsoft Entra defines the identity, permissions, and configuration of a custom application that needs to authenticate with Entra ID or access organizational resources. Every app that authenticates with Entra must have an app registration — it is the definition from which service principals are created in each tenant.

Think of it as: Filing a business license — the registration defines the business (app) identity, what it's allowed to do (permissions), and where it's allowed to operate (single or multi-tenant). The license itself (app registration) is not the employee working for you — the service principal is the actual identity instance that works in each location.

Key Mechanics: - App registration: single object in one tenant, defines the app's identity and API permissions - Service principal: created in every tenant where the app is used — this is the actual identity object - Multi-tenant apps: one registration, multiple service principals (one per customer tenant) - Redirect URIs: must exactly match what the app sends in the auth request — any mismatch causes "redirect URI mismatch" errors - Failure mode: App registration created but service principal not created in customer tenant → multi-tenant app cannot authenticate in that tenant until a service principal is instantiated (by user or admin consent)

Examples

Example 1 — [Success] Single-tenant web app registered correctly A developer registers a web app: account type = single-tenant, redirect URI = https://app.company.com/auth/callback. Adds Microsoft Graph delegated permissions (User.Read). Assigns owners. The app authenticates users, receives a token with User.Read scope, and reads the signed-in user's profile. The app registration and the runtime behavior match exactly.

Example 2 — [Blocked] Redirect URI mismatch blocks authentication A developer registers the app with redirect URI https://app.company.com/callback. The app code sends https://app.company.com/auth/callback in the authorization request. Entra rejects the request with "AADSTS50011: The redirect URI specified in the request does not match." The URIs must be identical — including path and case. Dev adds the correct URI to the app registration to resolve.

Key Mechanisms

- Core function: An app registration in Microsoft Entra defines the identity, permissions, and configuration of a custom application that needs to authenticate with Entra ID or access organizational resources. - Category fit: This concept belongs to access management and authorization and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Single-tenant web app registered correctly - Decision clue: Industry: Software Development (ISV)

Review Path

Steps:

1. Entra admin center → Applications → App registrations → New registration 2. Name: descriptive app name 3. Supported account types: single-tenant or multi-tenant (or personal accounts) 4. Redirect URI: select platform (Web / SPA / Desktop) → enter exact callback URL 5. Register 6. API permissions → Add permission → Microsoft Graph → Delegated or Application → select scopes 7. If Application permissions: Grant admin consent 8. Certificates & secrets: add client secret or certificate (for confidential clients) 9. Note: Application (client) ID and Directory (tenant) ID for app configuration

Docs: https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals

Explanation

Application authentication configuration is like a bank's access control system — it defines which flows (like authorization code, PKCE, client credentials) can be used to verify an app's identity and issue tokens to interact with resources.

Key Mechanics: - Authorization Code flow: App redirects user to Entra, receives code, exchanges code+secret for tokens (most secure for web apps) - PKCE flow: Authorization Code + Proof Key for Exchange, required for SPAs and mobile apps (prevents authorization code interception) - Client Credentials flow: App uses its own client ID/secret to obtain access token, no user involved (for daemon/background services) - Implicit flow: Legacy, app receives tokens directly in URI fragment, NOT recommended for new applications - Device Code flow: For IoT/input-constrained devices, user authenticates on separate device - Token lifetime: Configure access token, refresh token, and ID token lifespans based on security requirements - Redirect URIs: Must be pre-registered; app receives tokens here after authentication

Failure condition: If you don't configure the correct authentication flow, the app cannot complete authentication (e.g., configuring implicit flow when authorization code is required breaks the sign-in).

Examples

Example 1 — [Success] A developer registers a web app in Entra, configures Authorization Code flow with PKCE, sets redirect URIs to https://app.company.com/signin-oidc and https://localhost:5001/signin-oidc for dev/prod. User signs in, receives authorization code, app exchanges code+PKCE verifier for access token, and can call Microsoft Graph on user's behalf.

Example 2 — [Blocked] A developer configures Implicit flow for a modern web application and sets no redirect URIs. User attempts sign-in but the authorization flow expects code+PKCE exchange which cannot happen because implicit flow and missing URIs mean the app has no place to receive tokens. Sign-in fails.

Key Mechanisms

- Core function: Application authentication configuration is like a bank's access control system — it defines which flows (like authorization code, PKCE, client credentials) can be used to verify an app's identity and issue tokens to interact with resources. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] - Decision clue: Industry: SaaS / Healthcare

Review Path

**How to do it in Entra/Azure:**

**1. Configure Authentication Flows:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes 'Application.ReadWrite.All'

# Get application to configure $app = Get-MgApplication -Filter "displayName eq 'MyWebApp'"

# Configure web application with Auth Code flow $webConfig = @{ Web = @{ RedirectUris = @( 'https://app.company.com/signin-oidc' 'https://localhost:5001/signin-oidc' ) LogoutUrl = 'https://app.company.com/signout' ImplicitGrantSettings = @{ EnableIdTokenIssuance = $true EnableAccessTokenIssuance = $false } } RequiredResourceAccess = @( @{ ResourceAppId = '00000003-0000-0000-c000-000000000000' # Microsoft Graph ResourceAccess = @( @{ Id = 'e1fe6dd8-ba31-4d61-89e7-88639da4683d'; Type = 'Scope' } # User.Read ) } ) }

Update-MgApplication -ApplicationId $app.Id -BodyParameter $webConfig ```

**2. Configure Single Page Application (SPA):** ```powershell # Configure SPA with PKCE $spaConfig = @{ Spa = @{ RedirectUris = @( 'http://localhost:3000' 'https://spa.company.com' ) } PublicClient = @{ RedirectUris = @() } Web = @{ ImplicitGrantSettings = @{ EnableIdTokenIssuance = $false EnableAccessTokenIssuance = $false } } }

Update-MgApplication -ApplicationId $app.Id -BodyParameter $spaConfig

# Verify PKCE is enabled (default for SPA) $appDetails = Get-MgApplication -ApplicationId $app.Id Write-Host "SPA Redirect URIs: $($appDetails.Spa.RedirectUris -join ', ')" ```

**3. Configure Service/Daemon Application:** ```powershell # Configure daemon app with client credentials $daemonApp = New-MgApplication -DisplayName 'MyDaemonApp'

# Add application permissions (not delegated) $serviceConfig = @{ RequiredResourceAccess = @( @{ ResourceAppId = '00000003-0000-0000-c000-000000000000' # Microsoft Graph ResourceAccess = @( @{ Id = 'df021288-bdef-4463-88db-98f22de89214'; Type = 'Role' } # User.Read.All @{ Id = '5b567255-7703-4780-807c-7be8301ae99b'; Type = 'Role' } # Group.Read.All ) } ) Web = @{ ImplicitGrantSettings = @{ EnableIdTokenIssuance = $false EnableAccessTokenIssuance = $false } } }

Update-MgApplication -ApplicationId $daemonApp.Id -BodyParameter $serviceConfig

# Create client secret for daemon app $secret = New-MgApplicationPassword -ApplicationId $daemonApp.Id -PasswordCredential @{ DisplayName = 'DaemonSecret' } Write-Host "Client Secret: $($secret.SecretText)" ```

**4. Configure Advanced Authentication Settings:** ```powershell # Configure token lifetimes $tokenPolicy = @{ TokenLifetimePolicies = @( @{ Definition = @('[{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"04:00:00","RefreshTokenMaxInactiveTime":"90.00:00:00"}}]') DisplayName = 'Custom Token Lifetime' } ) }

# Apply token policy (requires Policy.ReadWrite.ApplicationConfiguration) # Update-MgApplication -ApplicationId $app.Id -BodyParameter $tokenPolicy

# Configure certificate authentication $certData = Get-Content 'app-certificate.cer' -Encoding Byte $certBase64 = [System.Convert]::ToBase64String($certData) $certCredential = @{ Type = 'AsymmetricX509Cert' Usage = 'Verify' Key = $certBase64 DisplayName = 'App Certificate' }

New-MgApplicationKeyCredential -ApplicationId $app.Id -KeyCredential $certCredential

# Configure audience validation $audienceConfig = @{ IdentifierUris = @('api://mycompany/myapi') SignInAudience = 'AzureADMyOrg' # Single tenant }

Update-MgApplication -ApplicationId $app.Id -BodyParameter $audienceConfig ```

**💡 Best Practices:** • Use Authorization Code + PKCE flow for modern applications • Avoid implicit flow for new applications - use Auth Code + PKCE instead • Use certificates instead of secrets for production applications when possible • Configure appropriate token lifetimes based on security requirements • Test authentication flows in development before production deployment • Monitor authentication logs for failed attempts and anomalies • Keep redirect URIs up to date when deploying to new environments

📚 **Learn More:** [Authentication Flows and App Scenarios](https://learn.microsoft.com/en-us/entra/identity-platform/authentication-flows-app-scenarios)

Explanation

API permissions configuration defines what resources and data an application can access. This includes Microsoft Graph permissions, custom API permissions, delegated vs application permissions, and managing consent requirements. Proper configuration ensures least privilege access while meeting application functionality needs.

Think of it as: API permissions are the room keys your app gets — delegated means 'act like the user who signed in,' application means 'act with your own identity regardless of who is signed in.'

Key Mechanics: - Delegated permissions: App acts as the signed-in user (limited to user's access) - Application permissions: App acts with own identity (full access to that permission) - User consent: Only works for low-risk delegated permissions - Admin consent: Required for application permissions and high-risk delegated - Failure condition: Requesting application permissions when delegated would suffice; over-privileging apps

Examples

Example 1 — [Success] Least privilege delegated permissions App needs to read user profile. Dev configures delegated User.Read permission. When user signs in and grants consent, app can read ONLY that user's profile (user's scope limit). Complies with least privilege.

Example 2 — [Blocked] Overly broad application permissions App requests User.Read.All (application permission) to read user profile. Admin grants consent. Now the app can read ALL users in the directory regardless of who signed in. If app is compromised, attacker gets access to all users. Root cause: Using application permission instead of delegated; over-privileging the app.

Key Mechanisms

- Core function: API permissions configuration defines what resources and data an application can access. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Least privilege delegated permissions - Decision clue: Implementing least privilege access principles, enabling application functionality, managing user consent experiences, supporting compliance requirements, securing API access across different application types.

Review Path

**How to do it in Entra/Azure:**

**1. Configure Microsoft Graph Permissions**

```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes 'Application.ReadWrite.All'

# Get application to configure $app = Get-MgApplication -Filter "displayName eq 'MyWebApp'"

# Configure basic Microsoft Graph permissions $graphPermissions = @{ RequiredResourceAccess = @( @{ ResourceAppId = '00000003-0000-0000-c000-000000000000' # Microsoft Graph ResourceAccess = @( @{ Id = 'e1fe6dd8-ba31-4d61-89e7-88639da4683d'; Type = 'Scope' }, # User.Read @{ Id = '64a6cdd6-aab1-4aaf-94b8-3cc8405e90d0'; Type = 'Scope' }, # Email @{ Id = '14dad69e-099b-42c9-810b-d002981feec1'; Type = 'Scope' }, # Profile @{ Id = '37f7f235-527c-4136-accd-4a02d197296e'; Type = 'Scope' }, # OpenId ) } ) }

Update-MgApplication -ApplicationId $app.Id -BodyParameter $graphPermissions

# List all available Microsoft Graph permissions $graphApp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" $graphApp.Oauth2PermissionScopes | Select-Object Value, UserConsentDisplayName | Sort-Object Value ```

**2. Configure Application Permissions for Daemon Apps**

```powershell # Configure high-privilege application permissions $appPermissions = @{ RequiredResourceAccess = @( @{ ResourceAppId = '00000003-0000-0000-c000-000000000000' # Microsoft Graph ResourceAccess = @( @{ Id = 'df021288-bdef-4463-88db-98f22de89214'; Type = 'Role' }, # User.Read.All @{ Id = '5b567255-7703-4780-807c-7be8301ae99b'; Type = 'Role' }, # Group.Read.All @{ Id = 'b633e1c5-b582-4048-a93e-9f11b44c7e96'; Type = 'Role' }, # Mail.Send ) } ) }

Update-MgApplication -ApplicationId $app.Id -BodyParameter $appPermissions

# Grant admin consent for application permissions $servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'" foreach ($resource in $appPermissions.RequiredResourceAccess) { $resourceSP = Get-MgServicePrincipal -Filter "appId eq '$($resource.ResourceAppId)'" foreach ($permission in $resource.ResourceAccess) { if ($permission.Type -eq 'Role') { New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipal.Id -ResourceId $resourceSP.Id -AppRoleId $permission.Id -PrincipalId $servicePrincipal.Id } } } ```

**3. Configure Custom API Permissions**

```powershell # Create custom API with permissions $customAPI = New-MgApplication -DisplayName 'Custom Business API'

# Define custom scopes for the API $customScopes = @( @{ Id = [System.Guid]::NewGuid().ToString() Value = 'Orders.Read' UserConsentDisplayName = 'Read your orders' UserConsentDescription = 'Allow the application to read your order information' AdminConsentDisplayName = 'Read orders' AdminConsentDescription = 'Allows the app to read order information' IsEnabled = $true Type = 'User' }, @{ Id = [System.Guid]::NewGuid().ToString() Value = 'Orders.Write' UserConsentDisplayName = 'Manage your orders' UserConsentDescription = 'Allow the application to create and modify your orders' AdminConsentDisplayName = 'Manage orders' AdminConsentDescription = 'Allows the app to create and modify orders' IsEnabled = $true Type = 'Admin' } )

# Configure the API with custom scopes $apiConfig = @{ IdentifierUris = @('api://company/orders') Api = @{ Oauth2PermissionScopes = $customScopes AcceptMappedClaims = $true } }

Update-MgApplication -ApplicationId $customAPI.Id -BodyParameter $apiConfig ```

**4. Monitor and Audit API Permissions**

```powershell # Audit all application permissions $apps = Get-MgApplication -All foreach ($app in $apps) { Write-Host "Application: $($app.DisplayName)" foreach ($resource in $app.RequiredResourceAccess) { $resourceApp = Get-MgServicePrincipal -Filter "appId eq '$($resource.ResourceAppId)'" Write-Host " Resource: $($resourceApp.DisplayName)" foreach ($permission in $resource.ResourceAccess) { $permType = if ($permission.Type -eq 'Role') { 'Application' } else { 'Delegated' } Write-Host " Permission: $($permission.Id) ($permType)" } } }

# Check granted permissions vs requested permissions $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'" $grantedPermissions = Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id $grantedPermissions | Select-Object Scope, ConsentType, PrincipalId

# Export permissions audit $permissionsAudit = @() foreach ($app in $apps) { foreach ($resource in $app.RequiredResourceAccess) { foreach ($permission in $resource.ResourceAccess) { $permissionsAudit += [PSCustomObject]@{ ApplicationName = $app.DisplayName ApplicationId = $app.AppId ResourceId = $resource.ResourceAppId PermissionId = $permission.Id PermissionType = $permission.Type } } } } $permissionsAudit | Export-Csv -Path 'API-Permissions-Audit.csv' -NoTypeInformation ```

**Best Practices:** • Always request minimum permissions needed for application functionality • Use delegated permissions when acting on behalf of a user • Use application permissions only for daemon/service scenarios • Implement dynamic consent for additional permissions when needed • Regularly audit and review granted permissions • Document permission requirements and justifications • Test permission scenarios in development environment first

Explanation

App roles define custom roles within applications that provide fine-grained authorization beyond basic authentication. These roles enable applications to implement role-based access control (RBAC) and assign different permission levels to users and groups based on their responsibilities and access requirements.

Think of it as: App roles are like job titles in a company — creating a job title doesn't hire anyone; you must assign people to the job title.

Key Mechanics: - Creating an app role definition = defining the job title (no access yet) - Assigning users to the app role = hiring people for that job - App roles appear in tokens as claims for app to evaluate - Must be configured in application registration BEFORE using in application - Failure condition: Creating app role and expecting automatic access; must assign users to roles

Examples

Example 1 — [Success] App role created and users assigned Developer creates app role 'Manager' in app registration. In Entra admin center, manager users are assigned to the Manager role. When manager signs in, token includes 'roles: [Manager]' claim. App checks claim and grants manager features.

Example 2 — [Blocked] App role created but no assignments Developer creates app role 'Administrator.' No users are assigned. When admins sign in, token doesn't include the Administrator claim. App denies access to admin features. Developer is confused: 'I created the role, why don't admins have access?' Root cause: Creating a role doesn't auto-grant access — users must be explicitly assigned to the role.

Key Mechanisms

- Core function: App roles define custom roles within applications that provide fine-grained authorization beyond basic authentication. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] App role created and users assigned - Decision clue: Implementing role-based access control within applications, providing granular permission management, supporting business workflow requirements, enabling self-service role assignments, meeting compliance requirements for segregation of duties.

Review Path

**How to do it in Entra/Azure:**

**1. Define Application Roles**

```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes 'Application.ReadWrite.All'

# Get application to add roles to $app = Get-MgApplication -Filter "displayName eq 'Business Application'"

# Define custom app roles $appRoles = @( @{ Id = [System.Guid]::NewGuid().ToString() DisplayName = 'Administrator' Description = 'Full access to all application features and user management' Value = 'Admin' IsEnabled = $true AllowedMemberTypes = @('User', 'Application') Origin = 'Application' }, @{ Id = [System.Guid]::NewGuid().ToString() DisplayName = 'Manager' Description = 'Management access with approval and oversight capabilities' Value = 'Manager' IsEnabled = $true AllowedMemberTypes = @('User') Origin = 'Application' }, @{ Id = [System.Guid]::NewGuid().ToString() DisplayName = 'User' Description = 'Standard user access to application features' Value = 'User' IsEnabled = $true AllowedMemberTypes = @('User') Origin = 'Application' }, @{ Id = [System.Guid]::NewGuid().ToString() DisplayName = 'ReadOnly' Description = 'Read-only access to application data and reports' Value = 'ReadOnly' IsEnabled = $true AllowedMemberTypes = @('User') Origin = 'Application' } )

# Update application with app roles Update-MgApplication -ApplicationId $app.Id -AppRoles $appRoles ```

**2. Assign Users and Groups to App Roles**

```powershell # Get service principal for role assignments $servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"

# Get app roles from service principal $adminRole = $servicePrincipal.AppRoles | Where-Object { $_.Value -eq 'Admin' } $managerRole = $servicePrincipal.AppRoles | Where-Object { $_.Value -eq 'Manager' } $userRole = $servicePrincipal.AppRoles | Where-Object { $_.Value -eq 'User' } $readOnlyRole = $servicePrincipal.AppRoles | Where-Object { $_.Value -eq 'ReadOnly' }

# Assign admin role to IT administrators $adminUser = Get-MgUser -Filter "userPrincipalName eq 'admin@company.com'" New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipal.Id -PrincipalId $adminUser.Id -ResourceId $servicePrincipal.Id -AppRoleId $adminRole.Id

# Assign manager role to department managers $managersGroup = Get-MgGroup -Filter "displayName eq 'Department Managers'" New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipal.Id -PrincipalId $managersGroup.Id -ResourceId $servicePrincipal.Id -AppRoleId $managerRole.Id

# Assign user role to all employees $employeesGroup = Get-MgGroup -Filter "displayName eq 'All Employees'" New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipal.Id -PrincipalId $employeesGroup.Id -ResourceId $servicePrincipal.Id -AppRoleId $userRole.Id ```

**3. Configure Role Claims in Application**

```powershell # Configure optional claims for roles $optionalClaims = @{ IdToken = @( @{ Name = 'roles' Source = 'user' Essential = $true } ) AccessToken = @( @{ Name = 'roles' Source = 'user' Essential = $true } ) }

Update-MgApplication -ApplicationId $app.Id -OptionalClaims $optionalClaims

# Example application code to read roles (.NET) # var roles = User.FindAll(ClaimTypes.Role).Select(c => c.Value); # bool isAdmin = roles.Contains("Admin"); # bool isManager = roles.Contains("Manager");

# Example role check in application # [Authorize(Roles = "Admin,Manager")] # public IActionResult AdminOnlyAction() { ... } ```

**4. Manage and Audit App Role Assignments**

```powershell # List all role assignments for the application $roleAssignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipal.Id

foreach ($assignment in $roleAssignments) { $principal = if ($assignment.PrincipalType -eq 'User') { Get-MgUser -UserId $assignment.PrincipalId } else { Get-MgGroup -GroupId $assignment.PrincipalId } $role = $servicePrincipal.AppRoles | Where-Object { $_.Id -eq $assignment.AppRoleId } Write-Host "Principal: $($principal.DisplayName) ($($assignment.PrincipalType))" Write-Host "Role: $($role.DisplayName) ($($role.Value))" Write-Host "Assigned: $($assignment.CreatedDateTime)" Write-Host "---" }

# Export role assignments for audit $auditReport = @() foreach ($assignment in $roleAssignments) { $principal = if ($assignment.PrincipalType -eq 'User') { Get-MgUser -UserId $assignment.PrincipalId } else { Get-MgGroup -GroupId $assignment.PrincipalId } $role = $servicePrincipal.AppRoles | Where-Object { $_.Id -eq $assignment.AppRoleId } $auditReport += [PSCustomObject]@{ ApplicationName = $servicePrincipal.DisplayName PrincipalName = $principal.DisplayName PrincipalType = $assignment.PrincipalType RoleName = $role.DisplayName RoleValue = $role.Value AssignedDate = $assignment.CreatedDateTime } }

$auditReport | Export-Csv -Path 'App-Role-Assignments-Audit.csv' -NoTypeInformation ```

**Best Practices:** • Design app roles based on business functions and responsibilities • Use descriptive role names that clearly indicate permissions and scope • Implement role hierarchy with appropriate escalation paths • Use groups for role assignments to simplify management at scale • Include role claims in both ID tokens and access tokens for full coverage • Regularly audit role assignments to ensure compliance with least privilege • Document role definitions and assignment criteria for governance

Explanation

Cloud Discovery in Microsoft Defender for Cloud Apps identifies and analyzes cloud applications used within your organization. It provides visibility into shadow IT, risk assessment of discovered apps, and usage analytics to help organizations understand and govern their cloud application landscape.

Examples

Example 1 — [Success] Discovery identifies and governance controls risk Cloud Discovery finds 50 unauthorized SaaS apps in use. Organization reviews each, marks 5 as sanctioned (approved), blocks 20 (prohibit), monitors 25 (allow but review). Users transition off blocked apps to approved alternatives. Shadow IT reduced from unknown to managed inventory.

Example 2 — [Blocked] No discovery means shadow IT is invisible Organization doesn't configure Cloud Discovery. Users adopt 100+ SaaS apps without IT knowledge. Attacker compromises one unauthorized app, steals company data. Audit discovers breach but org didn't even know the app existed. Root cause: No Cloud Discovery visibility into shadow IT.

Key Mechanisms

- Core function: Cloud Discovery in Microsoft Defender for Cloud Apps identifies and analyzes cloud applications used within your organization. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Discovery identifies and governance controls risk - Decision clue: Gaining visibility into shadow IT, assessing security risks of cloud applications, implementing cloud governance policies, meeting compliance requirements, optimizing cloud application portfolio.

Review Path

**How to do it in Entra/Azure:**

**1. Configure Cloud Discovery Data Sources**

```powershell # Enable Cloud Discovery in Microsoft Defender for Cloud Apps # Navigate to Defender for Cloud Apps portal > Settings > Cloud Discovery

# Configure automatic log upload via PowerShell Connect-MgGraph -Scopes 'CloudApp-Discovery.Read.All'

# Configure log collector (requires on-premises deployment) $logCollectorConfig = @{ Name = 'Corporate-LogCollector' Description = 'Main corporate firewall log collector' DataSources = @('BlueCoat', 'Checkpoint', 'Palo Alto Networks') LogFormat = 'CEF' AutomaticUpload = $true }

# Manual log upload example $logUpload = @{ DataSourceType = 'CHECKPOINT' LogFile = 'C:\Logs\checkpoint-traffic.log' Description = 'Weekly checkpoint firewall logs' }

# Upload logs via REST API # Invoke-RestMethod -Uri 'https://portal.cloudappsecurity.com/api/v1/discovery/upload_log/' -Method POST -Body $logUpload ```

**2. Analyze Discovery Results**

```powershell # Query discovered applications via Graph API $discoveredApps = Invoke-MgGraphRequest -Uri 'https://graph.microsoft.com/v1.0/security/cloudAppSecurityProfiles'

# Analyze high-risk applications $highRiskApps = $discoveredApps.value | Where-Object { $_.riskScore -gt 7 } foreach ($app in $highRiskApps) { Write-Host "High Risk App: $($app.name)" Write-Host "Risk Score: $($app.riskScore)" Write-Host "Users: $($app.userCount)" Write-Host "Data Volume: $($app.dataVolume) MB" Write-Host "---" }

# Generate usage analytics report $usageReport = @() foreach ($app in $discoveredApps.value) { $usageReport += [PSCustomObject]@{ ApplicationName = $app.name Category = $app.category RiskScore = $app.riskScore UserCount = $app.userCount TransactionCount = $app.transactionCount DataVolumeMB = $app.dataVolume ComplianceRisk = $app.complianceRisk } }

$usageReport | Export-Csv -Path 'Cloud-Discovery-Analysis.csv' -NoTypeInformation ```

**3. Configure App Risk Assessment**

```powershell # Set custom risk factors for application assessment $riskFactors = @{ SecurityFactors = @( @{ Factor = 'DataEncryption'; Weight = 'High'; Required = $true } @{ Factor = 'TwoFactorAuth'; Weight = 'High'; Required = $true } @{ Factor = 'SOC2Compliance'; Weight = 'Medium'; Required = $false } ) ComplianceFactors = @( @{ Factor = 'GDPRCompliance'; Weight = 'High'; Required = $true } @{ Factor = 'HIPAACompliance'; Weight = 'Medium'; Required = $false } @{ Factor = 'DataResidency'; Weight = 'Medium'; Required = $true } ) GeneralFactors = @( @{ Factor = 'VendorReputation'; Weight = 'Medium'; Required = $false } @{ Factor = 'UserReviews'; Weight = 'Low'; Required = $false } @{ Factor = 'MarketPresence'; Weight = 'Low'; Required = $false } ) }

# Apply risk scoring to discovered applications # This is typically done through the Defender for Cloud Apps portal # Custom risk factors can be configured in Settings > Cloud Discovery > Risk metrics ```

**4. Implement Governance Actions**

```powershell # Sanction approved applications $sanctionedApps = @('Microsoft 365', 'Salesforce', 'Box', 'Zoom') foreach ($appName in $sanctionedApps) { # Mark as sanctioned in Defender for Cloud Apps Write-Host "Sanctioning application: $appName" # API call to mark as sanctioned }

# Block high-risk applications $blockedApps = $highRiskApps | Where-Object { $_.riskScore -gt 8 } foreach ($app in $blockedApps) { Write-Host "Blocking high-risk application: $($app.name)" # Configure firewall or proxy rules to block # Add to organizational block list }

# Create monitoring policies for unsanctioned apps $monitoringPolicy = @{ Name = 'Unsanctioned App Usage Alert' Description = 'Alert when users access unsanctioned cloud applications' Conditions = @{ AppCategory = 'Unsanctioned' UserActivity = 'Login' MinimumUserCount = 5 } Actions = @{ SendAlert = $true AlertRecipients = @('security@company.com', 'it-admin@company.com') BlockAccess = $false } }

# Generate governance report $governanceReport = @() foreach ($app in $discoveredApps.value) { $status = if ($app.name -in $sanctionedApps) { 'Sanctioned' } elseif ($app.riskScore -gt 8) { 'Blocked' } elseif ($app.riskScore -gt 6) { 'Under Review' } else { 'Monitored' } $governanceReport += [PSCustomObject]@{ ApplicationName = $app.name RiskScore = $app.riskScore GovernanceStatus = $status UserCount = $app.userCount LastSeen = $app.lastSeen RecommendedAction = if ($status -eq 'Under Review') { 'Complete security assessment' } else { 'Monitor usage' } } }

$governanceReport | Export-Csv -Path 'Cloud-Governance-Status.csv' -NoTypeInformation ```

**Best Practices:** • Configure multiple data sources for comprehensive discovery coverage • Regularly review and update risk assessment criteria • Implement automated alerts for new high-risk application discoveries • Coordinate with network teams for log collection setup • Use threat intelligence feeds to enhance risk scoring • Create governance workflows for application approval processes • Monitor trends in shadow IT usage to identify policy gaps

Explanation

Conditional Access App Control in Microsoft Defender for Cloud Apps provides real-time session controls for cloud applications. It enables organizations to monitor and control user activities within cloud apps, apply data loss prevention policies, and enforce access restrictions based on session risk and user behavior.

Examples

Example 1 — [Success] Real-time session controls prevent exfiltration User on personal device accesses Salesforce from IP flagged as high-risk. Conditional Access detects risk. App control allows access but monitors all file operations. User downloads customer list; watermark is applied and admins alerted. Forensics shows what happened.

Example 2 — [Blocked] No session controls means blind access User downloads entire customer database and sends to Gmail. Organization has no session controls configured, so no monitoring, no watermarks, no alerts until customer calls to say 'our data is for sale.' By then, damage is done. Root cause: No app control to monitor/restrict session actions.

Key Mechanisms

- Core function: Conditional Access App Control in Microsoft Defender for Cloud Apps provides real-time session controls for cloud applications. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Real-time session controls prevent exfiltration - Decision clue: Implementing Zero Trust principles for cloud applications, preventing data exfiltration, monitoring user behavior for security threats, enforcing compliance policies, protecting sensitive data in cloud environments.

Review Path

**How to do it in Entra/Azure:**

**1. Configure App Control Prerequisites**

```powershell # Enable Conditional Access App Control in Defender for Cloud Apps # Prerequisites: Entra ID Premium P1, Defender for Cloud Apps license

# Connect to Microsoft Graph Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'

# Create conditional access policy for app control $appControlPolicy = @{ DisplayName = 'App Control - Salesforce Session Control' State = 'enabled' Conditions = @{ Applications = @{ IncludeApplications = @('salesforce-app-id') } Users = @{ IncludeUsers = @('All') ExcludeUsers = @('emergency-access-account-id') } Platforms = @{ IncludePlatforms = @('all') } } SessionControls = @{ CloudAppSecurity = @{ IsEnabled = $true CloudAppSecurityType = 'mcasConfigured' } } }

New-MgIdentityConditionalAccessPolicy -BodyParameter $appControlPolicy ```

**2. Configure Session Policies**

```powershell # Configure session policy for download restrictions $downloadPolicy = @{ Name = 'Block Downloads from Unmanaged Devices' Description = 'Prevent file downloads from devices not managed by organization' Applications = @('Salesforce', 'Office 365') Conditions = @{ DeviceCompliance = 'NonCompliant' UserRisk = 'Any' LocationRisk = 'Any' } Controls = @{ BlockDownloads = $true BlockPrint = $true BlockCopyPaste = $false ApplyWatermark = $true } AlertSettings = @{ Enabled = $true Recipients = @('security@company.com') Threshold = 1 } }

# Session policies are typically configured through the Defender for Cloud Apps portal # Navigate to Control > Policies > Session policies > Create policy ```

**3. Configure Activity Monitoring Policies**

```powershell # Configure activity policy for suspicious behavior $activityPolicy = @{ Name = 'Mass Download Detection' Description = 'Detect and alert on mass file download activities' Applications = @('SharePoint', 'OneDrive', 'Box') ActivityType = 'FileDownload' Conditions = @{ ActivityCount = @{ GreaterThan = 100 TimeFrame = 'PT1H' # 1 hour } FileTypes = @('.pdf', '.docx', '.xlsx', '.pptx') UserRisk = 'Any' } Actions = @{ AlertUsers = $true AlertAdmins = $true SuspendUser = $false RequireStepUpAuth = $true } }

# Configure anomaly detection policy $anomalyPolicy = @{ Name = 'Unusual Geographic Access' Description = 'Detect access from unusual geographic locations' Applications = @('All') AnomalyType = 'GeographicAnomaly' Sensitivity = 'Medium' Actions = @{ AlertOnly = $true RequireStepUpAuth = $false } } ```

**4. Monitor and Respond to Alerts**

```powershell # Query session control alerts via Graph API $alerts = Invoke-MgGraphRequest -Uri 'https://graph.microsoft.com/v1.0/security/alerts' -Filter 'category eq "CloudAppSecurity"'

foreach ($alert in $alerts.value) { Write-Host "Alert: $($alert.title)" Write-Host "Severity: $($alert.severity)" Write-Host "User: $($alert.userStates[0].userPrincipalName)" Write-Host "Application: $($alert.cloudAppStates[0].destinationServiceName)" Write-Host "Activity: $($alert.description)" Write-Host "Time: $($alert.createdDateTime)" Write-Host "---" }

# Generate session control effectiveness report $sessionReport = @() foreach ($alert in $alerts.value) { $sessionReport += [PSCustomObject]@{ AlertTitle = $alert.title Severity = $alert.severity UserPrincipalName = $alert.userStates[0].userPrincipalName Application = $alert.cloudAppStates[0].destinationServiceName Activity = $alert.activityGroupName Location = $alert.networkConnections[0].sourceLocation DateTime = $alert.createdDateTime Status = $alert.status } }

$sessionReport | Export-Csv -Path 'Session-Control-Alerts.csv' -NoTypeInformation

# Auto-respond to high-severity alerts $highSeverityAlerts = $alerts.value | Where-Object { $_.severity -eq 'high' } foreach ($alert in $highSeverityAlerts) { # Trigger incident response workflow Write-Host "Processing high-severity alert: $($alert.title)" # Optionally suspend user or require re-authentication } ```

**Best Practices:** • Start with monitoring-only policies before implementing blocking controls • Test session controls with pilot users before organization-wide deployment • Configure appropriate alert thresholds to avoid alert fatigue • Coordinate with application owners before implementing restrictions • Use device compliance policies as prerequisites for app control • Monitor user feedback and adjust policies based on business needs • Implement graduated response based on risk levels

Explanation

Access and session policies in Microsoft Defender for Cloud Apps provide granular control over user activities and data access in cloud applications. These policies enable organizations to implement real-time controls based on user behavior, device compliance, location, and application usage patterns.

Examples

Example 1 — [Success] Session policy monitors risky activity Policy: "Monitor users accessing from anonymous IP + downloading files." High-risk user matches policy. Admin gets alerted in real-time. Download is logged with metadata. If pattern suggests exfiltration, admin can block future downloads from that user.

Example 2 — [Blocked] No policies means no protection Organization doesn't create session policies. Insider downloads 10GB of financial data in 5 minutes and emails it out. No policy to trigger alerts. No monitoring. Data breach goes undetected for weeks. Root cause: Without policies, no automated detection of suspicious session activity.

Key Mechanisms

- Core function: Access and session policies in Microsoft Defender for Cloud Apps provide granular control over user activities and data access in cloud applications. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Session policy monitors risky activity - Decision clue: Implementing Zero Trust security principles, preventing data exfiltration, managing insider threats, ensuring regulatory compliance, protecting sensitive data across cloud applications, enabling conditional access based on risk factors.

Review Path

**How to do it in Entra/Azure:**

**1. Create Access Policy for Device Compliance**

```powershell # Connect to Microsoft Graph for Conditional Access Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'

# Create access policy for unmanaged devices $deviceAccessPolicy = @{ DisplayName = 'Block Cloud Apps from Unmanaged Devices' State = 'enabled' Conditions = @{ Applications = @{ IncludeApplications = @('Office365', 'Salesforce-app-id') } Users = @{ IncludeUsers = @('All') ExcludeUsers = @('emergency-access-account-id') } ClientAppTypes = @('browser', 'mobileAppsAndDesktopClients') DeviceStates = @{ IncludeStates = @('All') ExcludeStates = @('domainJoined', 'compliant') } } GrantControls = @{ BuiltInControls = @('block') Operator = 'OR' } }

New-MgIdentityConditionalAccessPolicy -BodyParameter $deviceAccessPolicy ```

**2. Configure Session Policy for Download Controls**

```powershell # Configure session policy via Defender for Cloud Apps API # Note: Session policies are primarily configured through the portal

$sessionPolicy = @{ Name = 'Restrict Downloads for External Users' Description = 'Block file downloads for users accessing from external networks' Template = 'BlockDownloadBasedOnRealTimeUserRisk' Conditions = @{ Applications = @{ Include = @('SharePoint Online', 'OneDrive for Business') } Users = @{ Include = @('All') Exclude = @('VIP-Users-Group') } Location = @{ Include = @('External') Exclude = @('Corporate-Network') } DeviceType = @('All') } Controls = @{ SessionControlType = 'BlockDownload' Actions = @('Block', 'Monitor', 'Alert') AllowedFileTypes = @('.txt', '.pdf') BlockedFileTypes = @('.exe', '.zip', '.rar') } Alerts = @{ Enabled = $true Recipients = @('security@company.com') Threshold = 5 } }

# Apply session policy (typically done through Defender for Cloud Apps portal) # Navigate to Control > Policies > Session policies ```

**3. Create Activity Policy for Anomaly Detection**

```powershell # Configure activity policy for mass download detection $activityPolicy = @{ Name = 'Mass File Download Alert' Description = 'Alert on suspicious mass file download activities' Category = 'ThreatDetection' Conditions = @{ ActivityType = @('FileDownload', 'FileAccessed') Applications = @('SharePoint Online', 'OneDrive', 'Box') Users = @{ Include = @('All') Exclude = @('ServiceAccounts-Group') } ActivityCount = @{ Operator = 'GreaterThan' Value = 50 TimeFrame = 'PT30M' # 30 minutes } FileTypes = @('.docx', '.xlsx', '.pdf', '.pptx') Location = @('Any') } Actions = @{ AlertUsers = $false AlertAdmins = $true SuspendUser = $false RequirePasswordReset = $false SendAlertToEmail = @('security@company.com', 'compliance@company.com') } Severity = 'Medium' }

# Configure anomaly policy for impossible travel $anomalyPolicy = @{ Name = 'Impossible Travel Detection' Description = 'Detect impossible travel patterns in cloud app usage' Type = 'ImpossibleTravel' Sensitivity = 'Medium' Applications = @('All') Actions = @{ AlertOnly = $true RequireStepUpAuth = $true } } ```

**4. Monitor and Manage Policy Effectiveness**

```powershell # Query policy alerts and effectiveness $policyAlerts = Invoke-MgGraphRequest -Uri 'https://graph.microsoft.com/v1.0/security/alerts' -Filter 'category eq "CloudAppSecurity" and createdDateTime ge 2024-01-01'

# Analyze policy effectiveness $policyStats = @() foreach ($alert in $policyAlerts.value) { $policyStats += [PSCustomObject]@{ PolicyName = $alert.title Severity = $alert.severity UserPrincipalName = $alert.userStates[0].userPrincipalName ApplicationName = $alert.cloudAppStates[0].destinationServiceName Activity = $alert.activityGroupName Location = $alert.networkConnections[0].sourceLocation DateTime = $alert.createdDateTime Status = $alert.status } }

$policyStats | Export-Csv -Path 'Policy-Effectiveness-Report.csv' -NoTypeInformation

# Generate policy compliance summary $complianceSummary = $policyStats | Group-Object PolicyName | ForEach-Object { [PSCustomObject]@{ PolicyName = $_.Name TotalAlerts = $_.Count HighSeverityAlerts = ($_.Group | Where-Object Severity -eq 'high').Count MediumSeverityAlerts = ($_.Group | Where-Object Severity -eq 'medium').Count LowSeverityAlerts = ($_.Group | Where-Object Severity -eq 'low').Count UniqueUsers = ($_.Group | Select-Object UserPrincipalName -Unique).Count MostCommonActivity = ($_.Group | Group-Object Activity | Sort-Object Count -Descending | Select-Object -First 1).Name } }

$complianceSummary | Format-Table -AutoSize

# Identify policy tuning opportunities $noisyPolicies = $complianceSummary | Where-Object { $_.LowSeverityAlerts -gt 100 } if ($noisyPolicies) { Write-Host "Policies generating high volume of low-severity alerts (consider tuning):" $noisyPolicies | Format-Table PolicyName, LowSeverityAlerts } ```

**Best Practices:** • Start with monitoring-only policies before implementing blocking actions • Use pilot groups to test policy impact before full deployment • Configure appropriate alert thresholds to minimize false positives • Regularly review policy effectiveness and tune based on usage patterns • Coordinate with business stakeholders when implementing restrictive policies • Document policy exceptions and approval processes • Use graduated response based on risk levels and user types

Explanation

The Cloud App Catalog in Microsoft Defender for Cloud Apps provides a comprehensive database of cloud applications with risk assessments, compliance information, and security ratings. It enables organizations to make informed decisions about cloud application adoption and governance based on standardized risk criteria.

Examples

Example 1 — [Success] Catalog informs secure decisions IT reviews two file-sharing apps: App A (risk score 8, SOC2 certified) and App B (risk score 3, no certifications). Based on catalog data, IT approves App A and blocks App B. Users adopt App A, known to be secure.

Example 2 — [Blocked] No catalog review leads to bad decisions IT approves unknown file-sharing app without reviewing catalog. App turns out to be high-risk (score 3) with no security certifications. Data breach occurs. Root cause: No catalog due diligence before approval.

Key Mechanisms

- Core function: The Cloud App Catalog in Microsoft Defender for Cloud Apps provides a comprehensive database of cloud applications with risk assessments, compliance information, and security ratings. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Catalog informs secure decisions - Decision clue: Supporting cloud application procurement decisions, implementing cloud governance frameworks, conducting due diligence for new cloud services, maintaining inventory of approved applications, ensuring compliance with regulatory requirements.

Review Path

**How to do it in Entra/Azure:**

**1. Access and Navigate Cloud App Catalog**

```powershell # Access Cloud App Catalog via Microsoft Defender for Cloud Apps portal # Navigate to Cloud Discovery > Cloud app catalog

# Query catalog via PowerShell (using REST API) $catalogQuery = @{ Uri = 'https://portal.cloudappsecurity.com/api/v1/catalog/' Method = 'GET' Headers = @{ 'Authorization' = 'Token YOUR_API_TOKEN' 'Content-Type' = 'application/json' } }

# Search for specific applications $searchQuery = @{ Uri = 'https://portal.cloudappsecurity.com/api/v1/catalog/search' Method = 'POST' Headers = @{ 'Authorization' = 'Token YOUR_API_TOKEN' 'Content-Type' = 'application/json' } Body = @{ search = 'salesforce' category = 'Business' riskScoreRange = @{ min = 7; max = 10 } } | ConvertTo-Json }

# Get high-risk applications $highRiskApps = Invoke-RestMethod @searchQuery ```

**2. Evaluate Application Risk Scores**

```powershell # Analyze application risk factors $riskEvaluation = @{ ApplicationName = 'Example SaaS App' SecurityFactors = @{ DataEncryption = @{ Score = 8; Weight = 'High'; Status = 'AES-256 encryption' } Authentication = @{ Score = 9; Weight = 'High'; Status = 'MFA supported, SSO integration' } AccessControls = @{ Score = 7; Weight = 'Medium'; Status = 'Role-based access, limited granularity' } AuditLogging = @{ Score = 8; Weight = 'Medium'; Status = 'Comprehensive activity logs' } } ComplianceFactors = @{ SOC2 = @{ Certified = $true; LastAudit = '2024-01-15' } ISO27001 = @{ Certified = $true; LastAudit = '2023-12-01' } GDPR = @{ Compliant = $true; DataResidency = 'EU' } HIPAA = @{ Certified = $false; Reason = 'Not healthcare focused' } } VendorFactors = @{ Reputation = 8 FinancialStability = 9 SecurityIncidentHistory = 2 # Lower is better ResponseToVulnerabilities = 8 } }

# Calculate overall risk score $overallScore = (($riskEvaluation.SecurityFactors.Values | Measure-Object Score -Average).Average * 0.5) + (($riskEvaluation.VendorFactors.Values | Measure-Object -Average).Average * 0.3) + (if ($riskEvaluation.ComplianceFactors.SOC2.Certified -and $riskEvaluation.ComplianceFactors.ISO27001.Certified) { 2 } else { 0 })

Write-Host "Overall Risk Score: $([math]::Round($overallScore, 1))/10" ```

**3. Implement Application Governance**

```powershell # Create governance workflow for new applications $governanceWorkflow = @{ ApplicationName = $null RequestedBy = $null BusinessJustification = $null RiskAssessment = @{ CatalogScore = $null SecurityReview = 'Pending' ComplianceReview = 'Pending' PrivacyReview = 'Pending' } ApprovalProcess = @{ SecurityTeam = 'Pending' ComplianceTeam = 'Pending' BusinessOwner = 'Pending' ITLeadership = 'Pending' } Implementation = @{ PilotUsers = @() PilotDuration = 'P30D' # 30 days FullDeployment = 'Pending' MonitoringSetup = 'Pending' } }

# Sanction approved applications $sanctionedApps = @('Microsoft 365', 'Salesforce', 'Zoom', 'Slack') foreach ($app in $sanctionedApps) { # Mark as sanctioned in catalog Write-Host "Sanctioning application: $app" # Configure monitoring and compliance policies # Set up integration with corporate identity systems }

# Tag applications by governance status $governanceTags = @{ 'Salesforce' = @('Sanctioned', 'Business-Critical', 'SOC2-Compliant') 'Zoom' = @('Sanctioned', 'Communication', 'Standard-Use') 'Dropbox' = @('Monitored', 'File-Sharing', 'Restricted-Use') 'TikTok' = @('Unsanctioned', 'Social-Media', 'Blocked') } ```

**4. Generate Governance Reports**

```powershell # Create application inventory report $inventoryReport = @() $catalogApps = @() # This would come from the catalog API

foreach ($app in $catalogApps) { $governanceStatus = if ($app.Name -in $sanctionedApps) { 'Sanctioned' } elseif ($app.RiskScore -lt 5) { 'Unsanctioned' } else { 'Under Review' } $inventoryReport += [PSCustomObject]@{ ApplicationName = $app.Name Category = $app.Category RiskScore = $app.RiskScore GovernanceStatus = $governanceStatus ComplianceCertifications = ($app.Certifications -join ', ') LastReviewed = $app.LastAssessmentDate BusinessOwner = $app.BusinessOwner UserCount = $app.EstimatedUsers DataClassification = $app.DataSensitivity } }

$inventoryReport | Export-Csv -Path 'Cloud-Application-Inventory.csv' -NoTypeInformation

# Generate compliance dashboard data $complianceStats = @{ TotalApplications = $inventoryReport.Count SanctionedApps = ($inventoryReport | Where-Object GovernanceStatus -eq 'Sanctioned').Count UnsanctionedApps = ($inventoryReport | Where-Object GovernanceStatus -eq 'Unsanctioned').Count UnderReviewApps = ($inventoryReport | Where-Object GovernanceStatus -eq 'Under Review').Count HighRiskApps = ($inventoryReport | Where-Object RiskScore -lt 5).Count SOC2CompliantApps = ($inventoryReport | Where-Object { $_.ComplianceCertifications -match 'SOC 2' }).Count GDPRCompliantApps = ($inventoryReport | Where-Object { $_.ComplianceCertifications -match 'GDPR' }).Count }

Write-Host "Cloud Application Governance Summary:" $complianceStats | Format-List

# Generate risk trend analysis $riskTrends = $inventoryReport | Group-Object Category | ForEach-Object { [PSCustomObject]@{ Category = $_.Name ApplicationCount = $_.Count AverageRiskScore = [math]::Round(($_.Group | Measure-Object RiskScore -Average).Average, 1) HighRiskCount = ($_.Group | Where-Object RiskScore -lt 5).Count SanctionedCount = ($_.Group | Where-Object GovernanceStatus -eq 'Sanctioned').Count } }

$riskTrends | Sort-Object AverageRiskScore | Format-Table -AutoSize ```

**Best Practices:** • Regularly review and update application risk assessments • Create standardized evaluation criteria for consistent risk scoring • Involve business stakeholders in governance decisions • Document approval criteria and decision rationale • Set up automated alerts for new high-risk application discoveries • Maintain current inventory of sanctioned and unsanctioned applications • Consider business impact when making governance decisions

Explanation

App-enforced restrictions are security controls applied directly within cloud applications through Microsoft Defender for Cloud Apps integration. These restrictions provide real-time protection by limiting user actions within the application based on risk assessment, device compliance, location, and other security signals. Unlike proxy-based controls, app-enforced restrictions work natively within the application using APIs and connectors.

Examples

Example 1 — [Success] Selective restrictions enable productivity Corporate user on corporate laptop: full access to SharePoint (download, print, share, copy). Remote user on personal laptop: can browse SharePoint but downloads are blocked. User adapts by viewing in browser or using corporate device. Both scenarios: access preserved, but sensitive actions limited on unmanaged devices.

Example 2 — [Blocked] Blocking access instead of restricting actions Admin blocks all SharePoint access from unmanaged devices. Remote employee can't access work documents at all. Employee bypasses security to use personal OneDrive instead. Root cause: All-or-nothing blocking is counterproductive. App-enforced restrictions allow selective action limitations instead.

Key Mechanisms

- Core function: App-enforced restrictions are security controls applied directly within cloud applications through Microsoft Defender for Cloud Apps integration. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Selective restrictions enable productivity - Decision clue: Protecting sensitive data when users access applications from unmanaged devices, enforcing data loss prevention policies within applications, providing granular control over user activities without blocking access entirely, meeting compliance requirements for data handling in cloud applications.

Review Path

🔧 **How to do it in Entra/Azure:**

**Configure App-Enforced Restrictions:** 1. Navigate to Microsoft Defender for Cloud Apps portal 2. Go to Control → Policies → Session policy 3. Create new session policy with "Control file download" template 4. Select "Block" as the action for app-enforced restrictions 5. Define conditions (user groups, device types, locations) 6. Enable "Apply to" specific applications

**PowerShell Configuration:** ```powershell # Connect to Defender for Cloud Apps Connect-CloudAppSecurity

# Create app-enforced restriction policy $restrictionPolicy = @{ Name = "Block Downloads from Unmanaged Devices" Description = "Prevent file downloads when accessing from personal devices" PolicyType = "SessionPolicy" Activities = @("Download") Actions = @{ Type = "Block" Parameters = @{ AppEnforced = $true Message = "Downloads blocked from unmanaged devices. Contact IT for assistance." } } Conditions = @{ DeviceTypes = @("Unmanaged") Apps = @("Office365") UserGroups = @("All Users") } }

New-CASPolicy @restrictionPolicy

# Monitor policy effectiveness Get-CASActivity -PolicyName "Block Downloads from Unmanaged Devices" -StartTime (Get-Date).AddDays(-7) ```

**SharePoint/OneDrive Specific Restrictions:** ```powershell # Connect to SharePoint Online Connect-SPOService -Url https://tenant-admin.sharepoint.com

# Configure conditional access restrictions for unmanaged devices Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess Set-SPOTenant -LimitedAccessFileType WebPreviewableFiles Set-SPOTenant -AllowDownloadingNonWebViewableFiles $false

# Apply to specific site collections Set-SPOSite -Identity https://tenant.sharepoint.com/sites/sensitive -ConditionalAccessPolicy AllowLimitedAccess

# Verify current settings Get-SPOTenant | Select-Object ConditionalAccessPolicy, LimitedAccessFileType, AllowDownloadingNonWebViewableFiles ```

**Monitor App-Enforced Restrictions:** ```powershell # Check restriction effectiveness $restrictionStats = Get-CASActivity -ActivityType "FileDownloadBlocked" -StartTime (Get-Date).AddDays(-30) $restrictionStats | Group-Object UserPrincipalName | Sort-Object Count -Descending | Select-Object Name, Count

# Review user feedback and help desk tickets related to restrictions $userFeedback = Get-CASAlert -AlertType "UserRestrictionFeedback" -StartTime (Get-Date).AddDays(-7) $userFeedback | Format-Table DateTime, UserPrincipalName, Application, RestrictionType, UserMessage

# Generate compliance report $complianceReport = @{ TotalRestrictions = ($restrictionStats | Measure-Object).Count UniqueUsers = ($restrictionStats | Select-Object UserPrincipalName -Unique | Measure-Object).Count TopRestrictedApps = $restrictionStats | Group-Object Application | Sort-Object Count -Descending | Select-Object -First 5 DeviceCompliance = Get-CASDevice | Group-Object ComplianceStatus | Select-Object Name, Count } $complianceReport | ConvertTo-Json -Depth 3 ```

**Troubleshoot Common Issues:** 1. Check application connector status: Get-CASConnector | Where-Object {$_.Status -ne "Connected"} 2. Verify API permissions for app-enforced controls 3. Review user experience feedback and adjust policies 4. Test restrictions with different device types and scenarios 5. Monitor bypass requests and legitimate business needs

**Best Practices:** • Start with audit mode before enforcing restrictions • Provide clear messaging to users about why restrictions are applied • Offer alternative workflows for legitimate business scenarios • Regularly review and adjust restrictions based on user feedback • Implement gradual rollout to minimize business disruption

Explanation

OAuth app policies in Microsoft Defender for Cloud Apps help organizations monitor, control, and govern third-party applications that users connect to their Microsoft 365 and other cloud services. These policies detect suspicious OAuth apps, prevent unauthorized data access, and ensure compliance with security standards by analyzing app permissions, user consent patterns, and potential security risks.

Examples

Example 1 — [Success] Policy detects and blocks suspicious permission combo Policy triggers when app requests 'Read all users' + 'Send mail as user.' User approves risky app. Policy blocks it with alert to admin. Admin reviews audit log, finds app was credential harvester. Policy prevented mass phishing sent from user mailboxes.

Example 2 — [Blocked] Policy not configured, malicious app slips through No OAuth policies configured. User installs app requesting 'Full mailbox access.' Admin doesn't know it happened. Attacker reads all company emails, extracts customer data. Root cause: No app governance policy monitored the suspicious permissions.

Key Mechanisms

- Core function: OAuth app policies in Microsoft Defender for Cloud Apps help organizations monitor, control, and govern third-party applications that users connect to their Microsoft 365 and other cloud services. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Policy detects and blocks suspicious permission combo - Decision clue: Preventing OAuth-based attacks and credential harvesting, ensuring only trusted applications access organizational data, meeting compliance requirements for third-party app governance, detecting and responding to suspicious app behavior, managing the application ecosystem proactively.

Review Path

🔧 **How to do it in Entra/Azure:**

**Configure OAuth App Policies:** 1. Navigate to Microsoft Defender for Cloud Apps portal 2. Go to Control → Policies → App governance policies 3. Create new OAuth app policy using templates: - "OAuth apps authorized by risky users" - "Misleading OAuth app name" - "OAuth apps with high privilege permissions" 4. Define policy conditions and actions (alert, ban, mark as compliant)

**PowerShell Configuration:** ```powershell # Connect to Defender for Cloud Apps Connect-CloudAppSecurity

# Create OAuth app monitoring policy $oauthPolicy = @{ Name = "High-Risk OAuth App Detection" Description = "Detect OAuth apps with suspicious permission combinations" PolicyType = "OAuthAppPolicy" Conditions = @{ Permissions = @("Directory.Read.All", "Mail.ReadWrite.All") PublisherVerification = $false UserConsentCount = @{ GreaterThan = 10 TimeFrame = "24 hours" } } Actions = @{ Type = "Alert" Severity = "High" NotificationRecipients = @("security@company.com") } }

New-CASPolicy @oauthPolicy

# Monitor OAuth app risks Get-CASApp -AppType OAuth | Where-Object {$_.RiskScore -gt 6} | Format-Table Name, Publisher, RiskScore, LastActivity ```

**Microsoft Entra ID OAuth App Governance:** ```powershell # Connect to Microsoft Entra ID Connect-AzureAD

# Get all OAuth applications with high-risk permissions $highRiskApps = Get-AzureADApplication | Where-Object { $_.RequiredResourceAccess.ResourceAccess.Id -contains "df021288-bdef-4463-88db-98f22de89214" -or # User.Read.All $_.RequiredResourceAccess.ResourceAccess.Id -contains "b4e74841-8e56-480b-be8b-910348b18b4c" # User.ReadWrite.All }

$highRiskApps | ForEach-Object { $app = $_ $servicePrincipal = Get-AzureADServicePrincipal -Filter "AppId eq '$($app.AppId)'" [PSCustomObject]@{ DisplayName = $app.DisplayName AppId = $app.AppId PublisherDomain = $app.PublisherDomain ConsentCount = (Get-AzureADServicePrincipalOAuth2PermissionGrant -ObjectId $servicePrincipal.ObjectId | Measure-Object).Count RiskAssessment = if($app.PublisherDomain -like "*microsoft.com") {"Low"} else {"High"} } } | Sort-Object RiskAssessment, ConsentCount -Descending

# Block suspicious OAuth app $suspiciousAppId = "12345678-1234-1234-1234-123456789abc" $servicePrincipal = Get-AzureADServicePrincipal -Filter "AppId eq '$suspiciousAppId'" Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $false ```

**Monitor OAuth App Activity:** ```powershell # Review recent OAuth app consents $consentActivities = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -Operations "Consent to application" $consentActivities | ForEach-Object { $details = $_.AuditData | ConvertFrom-Json [PSCustomObject]@{ DateTime = $_.CreationDate User = $details.UserId AppName = $details.ApplicationDisplayName AppId = $details.ApplicationId Permissions = ($details.ConsentContext.PermissionScopes -join ", ") } } | Sort-Object DateTime -Descending | Format-Table -AutoSize

# Generate OAuth risk report $oauthRiskReport = @{ TotalOAuthApps = (Get-CASApp -AppType OAuth | Measure-Object).Count HighRiskApps = (Get-CASApp -AppType OAuth | Where-Object {$_.RiskScore -gt 7} | Measure-Object).Count UnverifiedPublishers = (Get-CASApp -AppType OAuth | Where-Object {$_.PublisherVerified -eq $false} | Measure-Object).Count RecentConsents = $consentActivities.Count TopPermissions = Get-CASApp -AppType OAuth | ForEach-Object {$_.Permissions} | Group-Object | Sort-Object Count -Descending | Select-Object -First 10 } $oauthRiskReport | ConvertTo-Json -Depth 3 ```

**Implement OAuth App Governance Best Practices:** 1. Enable admin consent workflow for all OAuth apps 2. Create policies for automated risk assessment 3. Regular review of OAuth app permissions and usage 4. User education on OAuth consent risks 5. Integration with threat intelligence feeds for known malicious apps

**Respond to OAuth Threats:** ```powershell # Emergency OAuth app blocking procedure function Block-MaliciousOAuthApp { param([string]$AppId, [string]$Reason) # Disable the service principal $sp = Get-AzureADServicePrincipal -Filter "AppId eq '$AppId'" Set-AzureADServicePrincipal -ObjectId $sp.ObjectId -AccountEnabled $false # Revoke all OAuth grants Get-AzureADServicePrincipalOAuth2PermissionGrant -ObjectId $sp.ObjectId | ForEach-Object { Remove-AzureADOAuth2PermissionGrant -ObjectId $_.ObjectId } # Log the incident Write-EventLog -LogName Application -Source "Security" -EventId 1001 -Message "OAuth app $AppId blocked: $Reason" }

# Example usage Block-MaliciousOAuthApp -AppId "suspicious-app-id" -Reason "Credential harvesting attempt detected" ```

Explanation

Access package catalogs are containers that organize access packages in Entra ID Identity Governance. Catalogs provide a way to group related access packages, delegate management, and control which resources can be included in access packages. Each catalog has owners who can create and manage access packages within that catalog.

Think of it as: A catalog is an empty shelf — creating a catalog doesn't give anyone any books. You must fill the shelf with access packages (the books), and users must request those packages to get access.

Key Mechanics: - Creating a catalog = empty container, grants ZERO access - Access packages go INSIDE catalogs - Each access package defines what resources users can request - Users don't request 'catalogs' — they request 'access packages' - Failure condition: Creating a catalog and expecting users to automatically gain access; access packages must be created first

Examples

Example 1 — [Success] Catalog + access packages = user access Admin creates 'Sales Catalog' (empty). Inside, admin creates 'CRM Access Package' that includes Salesforce group. User requests CRM Access Package, gets approved, now has Salesforce access. Catalog provided structure; package provided access.

Example 2 — [Blocked] Creating catalog without access packages Admin creates 'HR Catalog' thinking HR users will now have access to HR systems. No access packages are created inside. Users request access to HR Catalog but there are no packages to request. Admin forgot that catalogs are containers; you must create and configure access packages inside for users to request anything. Root cause: Catalog creation alone grants NO access — access packages must exist.

Key Mechanisms

- Core function: Access package catalogs are containers that organize access packages in Entra ID Identity Governance. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Catalog + access packages = user access - Decision clue: Organizations use catalogs to delegate access management to business owners while maintaining governance.

Review Path

**How to do it in Entra/Azure:**

**Create and Configure Access Package Catalogs:**

1. **Navigate to Identity Governance:** - Azure Portal → Entra ID → Identity Governance → Catalogs

2. **Create New Catalog:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"

# Create a new catalog $catalogParams = @{ displayName = "HR Department Catalog" description = "Access packages for HR department resources" state = "published" isExternallyVisible = $false } $catalog = New-MgEntitlementManagementCatalog -BodyParameter $catalogParams Write-Host "Created catalog: $($catalog.DisplayName) with ID: $($catalog.Id)" ```

3. **Add Catalog Owners:** ```powershell # Add catalog owner $catalogOwnerId = "user@domain.com" $ownerParams = @{ "@odata.id" = "https://graph.microsoft.com/v1.0/users/$catalogOwnerId" } New-MgEntitlementManagementCatalogOwnerByRef -CatalogId $catalog.Id -BodyParameter $ownerParams Write-Host "Added catalog owner: $catalogOwnerId" ```

4. **Add Resources to Catalog:** ```powershell # Add Microsoft Entra ID group to catalog $groupId = "group-object-id" $resourceParams = @{ originId = $groupId originSystem = "AadGroup" } New-MgEntitlementManagementCatalogResource -CatalogId $catalog.Id -BodyParameter $resourceParams # Add application to catalog $appId = "application-object-id" $appResourceParams = @{ originId = $appId originSystem = "AadApplication" } New-MgEntitlementManagementCatalogResource -CatalogId $catalog.Id -BodyParameter $appResourceParams ```

**Manage Catalog Permissions:** ```powershell # Get catalog roles $catalogRoles = Get-MgEntitlementManagementCatalogRole

# Assign catalog manager role $catalogManagerRole = $catalogRoles | Where-Object {$_.DisplayName -eq "Catalog Manager"} $roleAssignmentParams = @{ roleDefinitionId = $catalogManagerRole.Id principalId = "user-object-id" resourceScope = "/catalogs/$($catalog.Id)" }

New-MgEntitlementManagementRoleAssignment -BodyParameter $roleAssignmentParams ```

**Monitor Catalog Usage:** ```powershell # Get all catalogs and their statistics $catalogs = Get-MgEntitlementManagementCatalog -All

foreach ($cat in $catalogs) { $packages = Get-MgEntitlementManagementAccessPackage -Filter "catalog/id eq '$($cat.Id)'" $resources = Get-MgEntitlementManagementCatalogResource -CatalogId $cat.Id [PSCustomObject]@{ CatalogName = $cat.DisplayName State = $cat.State PackageCount = $packages.Count ResourceCount = $resources.Count IsExternallyVisible = $cat.IsExternallyVisible CreatedDateTime = $cat.CreatedDateTime } } | Format-Table -AutoSize ```

**Best Practices:** 1. Organize catalogs by business function or department 2. Delegate catalog ownership to business stakeholders 3. Use descriptive names and detailed descriptions 4. Regularly review catalog contents and ownership 5. Monitor external visibility settings for security

Explanation

Access packages are bundles of resources that users can request access to through Entra ID Identity Governance. Each package contains one or more resources (groups, applications, SharePoint sites) with defined policies for who can request access, approval workflows, and access review requirements. Access packages enable self-service access management while maintaining security and compliance.

Examples

Example 1 — [Success] Access package provides controlled self-service New employee requests 'New Hire' access package. Approval workflow automatically notifies manager. Manager approves. Access package grants: Office 365 license, Finance group, building access badge. Employee gets 5 resources in one step instead of 5 IT requests.

Example 2 — [Blocked] Overcomplicated manual requests delay access No access packages. New employee needs 8 separate approvals for basic access. IT receives 8 separate requests. Manager gets 8 approval emails. Process takes 2 weeks. Employee frustrated, still blocked. Root cause: Without access packages, each resource requires individual request + approval.

Key Mechanisms

- Core function: Access packages are bundles of resources that users can request access to through Entra ID Identity Governance. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Access package provides controlled self-service - Decision clue: Organizations use access packages to standardize access provisioning, reduce IT overhead, and ensure consistent security policies.

Review Path

**How to do it in Entra/Azure:**

**Create Access Packages:**

1. **Navigate to Identity Governance:** - Azure Portal → Entra ID → Identity Governance → Access packages

2. **Create New Access Package:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"

# Create access package $catalogId = "catalog-id-here" $packageParams = @{ displayName = "Sales Team Access Package" description = "Complete access bundle for sales team members" catalog = @{ id = $catalogId } isHidden = $false } $accessPackage = New-MgEntitlementManagementAccessPackage -BodyParameter $packageParams Write-Host "Created access package: $($accessPackage.DisplayName)" ```

3. **Add Resource Roles to Package:** ```powershell # Add group membership role $groupId = "sales-group-id" $groupResourceRole = @{ originId = $groupId displayName = "Member" originSystem = "AadGroup" resource = @{ id = $groupId resourceType = "Security Group" originId = $groupId originSystem = "AadGroup" } } New-MgEntitlementManagementAccessPackageResourceRole -AccessPackageId $accessPackage.Id -BodyParameter $groupResourceRole # Add application role $appId = "crm-application-id" $appResourceRole = @{ originId = $appId displayName = "User" originSystem = "AadApplication" resource = @{ id = $appId resourceType = "Application" originId = $appId originSystem = "AadApplication" } } New-MgEntitlementManagementAccessPackageResourceRole -AccessPackageId $accessPackage.Id -BodyParameter $appResourceRole ```

4. **Create Assignment Policy:** ```powershell # Define policy for who can request access $policyParams = @{ displayName = "Sales Team Policy" description = "Policy for sales team access requests" canExtend = $false durationInDays = 365 expirationDateTime = $null accessPackage = @{ id = $accessPackage.Id } requestorSettings = @{ scopeType = "SpecificDirectoryUsers" acceptRequests = $true allowedRequestors = @( @{ "@odata.type" = "#microsoft.graph.singleUser" userId = "manager-user-id" } ) } requestApprovalSettings = @{ isApprovalRequired = $true isApprovalRequiredForExtension = $false isRequestorJustificationRequired = $true approvalMode = "SingleStage" approvalStages = @( @{ approvalStageTimeOutInDays = 14 isApproverJustificationRequired = $true primaryApprovers = @( @{ "@odata.type" = "#microsoft.graph.singleUser" userId = "approver-user-id" } ) } ) } } New-MgEntitlementManagementAccessPackageAssignmentPolicy -BodyParameter $policyParams ```

**Manage Access Package Assignments:** ```powershell # Get all assignments for an access package $assignments = Get-MgEntitlementManagementAccessPackageAssignment -Filter "accessPackage/id eq '$($accessPackage.Id)'"

foreach ($assignment in $assignments) { $user = Get-MgUser -UserId $assignment.TargetId [PSCustomObject]@{ UserName = $user.DisplayName UserEmail = $user.UserPrincipalName State = $assignment.State AssignedDate = $assignment.CreatedDateTime ExpiryDate = $assignment.Schedule.Expiration.DateTime } } | Format-Table -AutoSize

# Create direct assignment (bypass request process) $directAssignmentParams = @{ accessPackageId = $accessPackage.Id assignmentPolicyId = "policy-id" targetId = "user-id" justification = "Direct assignment for emergency access" }

New-MgEntitlementManagementAccessPackageAssignmentRequest -BodyParameter $directAssignmentParams ```

**Monitor and Report:** ```powershell # Generate access package usage report $allPackages = Get-MgEntitlementManagementAccessPackage -All

$report = foreach ($package in $allPackages) { $assignments = Get-MgEntitlementManagementAccessPackageAssignment -Filter "accessPackage/id eq '$($package.Id)'" $activeAssignments = $assignments | Where-Object {$_.State -eq "Delivered"} $expiredAssignments = $assignments | Where-Object {$_.State -eq "Expired"} [PSCustomObject]@{ PackageName = $package.DisplayName CatalogName = $package.Catalog.DisplayName TotalAssignments = $assignments.Count ActiveAssignments = $activeAssignments.Count ExpiredAssignments = $expiredAssignments.Count IsHidden = $package.IsHidden CreatedDate = $package.CreatedDateTime } }

$report | Export-Csv -Path "AccessPackageReport.csv" -NoTypeInformation $report | Format-Table -AutoSize ```

**Best Practices:** 1. Group related resources into logical packages 2. Use clear, descriptive names and descriptions 3. Set appropriate expiration periods 4. Configure approval workflows for sensitive resources 5. Regularly review package contents and policies 6. Use justification requirements for audit trails

Explanation

Access requests are formal submissions by users to obtain access to resources through Entra ID Identity Governance. The request process includes justification, approval workflows, and automated provisioning. Requests can be made through the My Access portal, and the system handles the entire lifecycle from submission to fulfillment, including notifications and audit trails.

Examples

Example 1 — [Success] Request workflow enables self-service with governance User requests 'Sales Tools' package with justification: 'assigned to new account.' Portal shows request pending. Sales manager gets email, reviews, approves. System auto-provisions user to Salesforce, CRM tools, sales group. Full audit trail captured. All via self-service.

Example 2 — [Blocked] No access request system creates bottleneck User needs tools for new assignment. User emails IT "I need access." IT is buried in emails. Takes 3 days to see request. IT manually grants access without documentation. No audit trail. User already moved to different project. Root cause: Without formal access request workflow, nothing is tracked or audited.

Key Mechanisms

- Core function: Access requests are formal submissions by users to obtain access to resources through Entra ID Identity Governance. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Request workflow enables self-service with governance - Decision clue: Organizations use access requests to maintain security while enabling self-service access.

Review Path

**How to do it in Entra/Azure:**

**Submit Access Requests (User Experience):**

1. **Access the My Access Portal:** - Navigate to: https://myaccess.microsoft.com - Sign in with organizational credentials

2. **Request Access Package:** ```powershell # Programmatically create access request Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"

# Submit access request $requestParams = @{ requestType = "UserAdd" accessPackageAssignment = @{ accessPackageId = "access-package-id" assignmentPolicyId = "policy-id" targetId = "user-id" } justification = "Need access to sales tools for Q4 planning" } $request = New-MgEntitlementManagementAccessPackageAssignmentRequest -BodyParameter $requestParams Write-Host "Submitted request with ID: $($request.Id)" ```

**Manage Access Requests (Administrator):** ```powershell # Get all pending requests $pendingRequests = Get-MgEntitlementManagementAccessPackageAssignmentRequest -Filter "requestState eq 'Submitted'"

foreach ($request in $pendingRequests) { $user = Get-MgUser -UserId $request.RequestorId $package = Get-MgEntitlementManagementAccessPackage -AccessPackageId $request.AccessPackageAssignment.AccessPackageId [PSCustomObject]@{ RequestId = $request.Id Requestor = $user.DisplayName RequestorEmail = $user.UserPrincipalName AccessPackage = $package.DisplayName Justification = $request.Justification SubmittedDate = $request.CreatedDateTime State = $request.RequestState } } | Format-Table -AutoSize

# Approve a request $approvalParams = @{ "@odata.type" = "#microsoft.graph.approval" stages = @( @{ "@odata.type" = "#microsoft.graph.approvalStage" reviewResult = "Approve" justification = "Access approved for business needs" } ) }

# Note: Approval typically done through UI or automated workflow ```

**Monitor Request Status:** ```powershell # Check specific request status $requestId = "request-id-here" $request = Get-MgEntitlementManagementAccessPackageAssignmentRequest -AccessPackageAssignmentRequestId $requestId

Write-Host "Request Status: $($request.RequestState)" Write-Host "Submitted: $($request.CreatedDateTime)" Write-Host "Completed: $($request.CompletedDateTime)"

# Get request timeline/history $requestEvents = Get-MgEntitlementManagementAccessPackageAssignmentRequest -AccessPackageAssignmentRequestId $requestId -ExpandProperty "*" ```

**Bulk Request Operations:** ```powershell # Bulk approve requests for specific access package $packageId = "specific-package-id" $requests = Get-MgEntitlementManagementAccessPackageAssignmentRequest -Filter "accessPackageAssignment/accessPackageId eq '$packageId' and requestState eq 'Submitted'"

foreach ($request in $requests) { try { # Auto-approve based on criteria $user = Get-MgUser -UserId $request.RequestorId if ($user.Department -eq "Sales") { # Approve sales requests automatically Write-Host "Auto-approving request for $($user.DisplayName)" # Implementation would involve calling approval API } } catch { Write-Error "Failed to process request $($request.Id): $($_.Exception.Message)" } } ```

**Generate Request Reports:** ```powershell # Request activity report $startDate = (Get-Date).AddDays(-30) $allRequests = Get-MgEntitlementManagementAccessPackageAssignmentRequest -All

$report = $allRequests | Where-Object {$_.CreatedDateTime -gt $startDate} | ForEach-Object { $user = Get-MgUser -UserId $_.RequestorId -ErrorAction SilentlyContinue $package = Get-MgEntitlementManagementAccessPackage -AccessPackageId $_.AccessPackageAssignment.AccessPackageId -ErrorAction SilentlyContinue [PSCustomObject]@{ RequestDate = $_.CreatedDateTime RequestorName = $user.DisplayName RequestorEmail = $user.UserPrincipalName Department = $user.Department AccessPackage = $package.DisplayName RequestType = $_.RequestType State = $_.RequestState Justification = $_.Justification CompletedDate = $_.CompletedDateTime ProcessingTime = if ($_.CompletedDateTime) { [math]::Round(($_.CompletedDateTime - $_.CreatedDateTime).TotalHours, 2) } else { "Pending" } } }

$report | Export-Csv -Path "AccessRequestReport.csv" -NoTypeInformation

# Summary statistics $summary = @{ TotalRequests = $report.Count ApprovedRequests = ($report | Where-Object {$_.State -eq "Delivered"}).Count PendingRequests = ($report | Where-Object {$_.State -eq "Submitted"}).Count DeniedRequests = ($report | Where-Object {$_.State -eq "Denied"}).Count AverageProcessingHours = ($report | Where-Object {$_.ProcessingTime -ne "Pending"} | Measure-Object ProcessingTime -Average).Average }

$summary | ConvertTo-Json ```

**Configure Request Notifications:** ```powershell # Set up custom notification templates $notificationParams = @{ notificationTemplates = @( @{ id = "EmailRequestApprovalNotification" defaultLocale = "en-US" localizations = @( @{ locale = "en-US" subject = "Access Request Needs Your Approval" body = "A new access request requires your approval. Package: {{PackageName}}, Requestor: {{RequestorName}}" } ) } ) }

# Apply notification settings to access package policy ```

**Best Practices:** 1. Require clear business justification for all requests 2. Set appropriate approval hierarchies based on resource sensitivity 3. Use automated workflows for low-risk, routine requests 4. Monitor request patterns for unusual activity 5. Regularly review and optimize approval processes 6. Implement request analytics for process improvement

Explanation

Terms of Use in Entra ID Identity Governance are legal agreements that users must accept before accessing specific resources or applications. These terms can be configured to require acceptance at different intervals (one-time, periodic, or per-application) and can be enforced through Conditional Access policies. The system tracks acceptance, provides audit trails, and can revoke access if terms are not accepted.

Examples

Example 1 — [Success] Terms enforced with audit trail Financial app has Terms of Use: 'No unauthorized data sharing.' User must accept before access. System logs acceptance, timestamp, user identity. Regulatory audit can prove all users acknowledged the policy. Acceptance tracked for 7 years per compliance.

Example 2 — [Blocked] No Terms of Use leaves no proof Contractor accesses confidential client data without signing terms. Company later sued for not documenting terms acknowledgment. No audit trail. Judge rules company failed due diligence. Root cause: No Terms of Use enforcement, no documentation.

Key Mechanisms

- Core function: Terms of Use in Entra ID Identity Governance are legal agreements that users must accept before accessing specific resources or applications. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Terms enforced with audit trail - Decision clue: Organizations use Terms of Use to ensure legal compliance, communicate policy changes, and maintain audit trails for regulatory requirements.

Review Path

**How to do it in Entra/Azure:**

**Create Terms of Use:**

1. **Navigate to Terms of Use:** - Azure Portal → Entra ID → Identity Governance → Terms of use

2. **Create New Terms:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "Agreement.ReadWrite.All"

# Upload terms document (PDF required) $termsFilePath = "C:\path\to\company-terms.pdf" $termsContent = [System.IO.File]::ReadAllBytes($termsFilePath)

# Create agreement $agreementParams = @{ displayName = "Company Data Protection Terms" isViewingBeforeAcceptanceRequired = $true files = @( @{ fileName = "DataProtectionTerms.pdf" language = "en" isDefault = $true fileData = @{ data = [Convert]::ToBase64String($termsContent) format = "application/pdf" } } ) termsExpiration = @{ startDateTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ") frequency = "monthly" } userReacceptRequiredFrequency = "P30D" # 30 days } $agreement = New-MgAgreement -BodyParameter $agreementParams Write-Host "Created Terms of Use: $($agreement.DisplayName) with ID: $($agreement.Id)" ```

3. **Configure Conditional Access Policy:** ```powershell # Create conditional access policy that enforces terms $policyParams = @{ displayName = "Enforce Data Protection Terms" state = "enabled" conditions = @{ users = @{ includeUsers = @("All") excludeUsers = @("break-glass-account-id") } applications = @{ includeApplications = @("00000003-0000-0000-c000-000000000000") # Office 365 } clientAppTypes = @("browser", "mobileAppsAndDesktopClients") } grantControls = @{ operator = "AND" builtInControls = @() termsOfUse = @($agreement.Id) } } New-MgIdentityConditionalAccessPolicy -BodyParameter $policyParams ```

**Manage Terms Acceptance:** ```powershell # Get all user acceptances for specific terms $agreementId = $agreement.Id $acceptances = Get-MgAgreementAcceptance -AgreementId $agreementId

foreach ($acceptance in $acceptances) { $user = Get-MgUser -UserId $acceptance.UserId -ErrorAction SilentlyContinue [PSCustomObject]@{ UserName = $user.DisplayName UserEmail = $user.UserPrincipalName AcceptanceTime = $acceptance.RecordedDateTime DeviceInfo = $acceptance.DeviceDisplayName IPAddress = $acceptance.UserPrincipalName # Available in detailed logs AgreementVersion = $acceptance.AgreementFileId ExpiryDate = $acceptance.ExpirationDateTime } } | Format-Table -AutoSize

# Check specific user's acceptance status $userId = "user-id-here" $userAcceptance = Get-MgUserAgreementAcceptance -UserId $userId -AgreementId $agreementId if ($userAcceptance) { Write-Host "User has accepted terms on: $($userAcceptance.RecordedDateTime)" } else { Write-Host "User has not accepted terms" } ```

**Generate Compliance Reports:** ```powershell # Generate comprehensive compliance report $allAgreements = Get-MgAgreement -All $complianceReport = @()

foreach ($agreement in $allAgreements) { $acceptances = Get-MgAgreementAcceptance -AgreementId $agreement.Id $totalUsers = (Get-MgUser -All -Select Id).Count $acceptedUsers = $acceptances.Count $complianceRate = [math]::Round(($acceptedUsers / $totalUsers) * 100, 2) # Get pending acceptances (users who need to accept) $allUsers = Get-MgUser -All -Select Id,DisplayName,UserPrincipalName $acceptedUserIds = $acceptances.UserId $pendingUsers = $allUsers | Where-Object {$_.Id -notin $acceptedUserIds} $complianceReport += [PSCustomObject]@{ AgreementName = $agreement.DisplayName TotalUsers = $totalUsers AcceptedUsers = $acceptedUsers PendingUsers = $pendingUsers.Count ComplianceRate = "$complianceRate%" LastModified = $agreement.ModifiedDateTime ExpirationFrequency = $agreement.UserReacceptRequiredFrequency } }

$complianceReport | Export-Csv -Path "TermsComplianceReport.csv" -NoTypeInformation $complianceReport | Format-Table -AutoSize ```

**Monitor Terms Violations:** ```powershell # Identify users with expired acceptances $expiredAcceptances = @()

foreach ($agreement in $allAgreements) { $acceptances = Get-MgAgreementAcceptance -AgreementId $agreement.Id foreach ($acceptance in $acceptances) { if ($acceptance.ExpirationDateTime -and $acceptance.ExpirationDateTime -lt (Get-Date)) { $user = Get-MgUser -UserId $acceptance.UserId $expiredAcceptances += [PSCustomObject]@{ AgreementName = $agreement.DisplayName UserName = $user.DisplayName UserEmail = $user.UserPrincipalName AcceptanceDate = $acceptance.RecordedDateTime ExpiryDate = $acceptance.ExpirationDateTime DaysOverdue = [math]::Ceiling(((Get-Date) - $acceptance.ExpirationDateTime).TotalDays) } } } }

$expiredAcceptances | Sort-Object DaysOverdue -Descending | Format-Table -AutoSize

# Send notification to users with expired terms foreach ($expired in $expiredAcceptances) { $emailBody = @" Dear $($expired.UserName),

Your acceptance of the "$($expired.AgreementName)" has expired. Please sign in to renew your acceptance to maintain access to company resources.

Expiry Date: $($expired.ExpiryDate) Days Overdue: $($expired.DaysOverdue)

Best regards, IT Security Team "@ # Send notification (requires additional mail configuration) Write-Host "Would send reminder to: $($expired.UserEmail)" } ```

**Update and Version Terms:** ```powershell # Update existing terms with new version $newTermsFilePath = "C:\path\to\updated-terms.pdf" $newTermsContent = [System.IO.File]::ReadAllBytes($newTermsFilePath)

$updateParams = @{ files = @( @{ fileName = "DataProtectionTerms_v2.pdf" language = "en" isDefault = $true fileData = @{ data = [Convert]::ToBase64String($newTermsContent) format = "application/pdf" } } ) }

Update-MgAgreement -AgreementId $agreement.Id -BodyParameter $updateParams Write-Host "Updated terms of use with new version"

# Force re-acceptance for all users $forceReacceptParams = @{ userReacceptRequiredFrequency = "P1D" # Force immediate re-acceptance }

Update-MgAgreement -AgreementId $agreement.Id -BodyParameter $forceReacceptParams ```

**Best Practices:** 1. Use clear, legally reviewed language in terms documents 2. Set appropriate re-acceptance frequencies based on compliance requirements 3. Exclude emergency accounts from terms requirements 4. Monitor compliance rates and follow up on non-compliance 5. Version control terms documents for audit purposes 6. Test terms presentation across different devices and browsers 7. Integrate with HR systems for automated user lifecycle management

Explanation

External user lifecycle management in Entra ID governs the complete journey of external users (partners, vendors, guests) from invitation through access provisioning to eventual removal. This includes automated workflows for onboarding, periodic access reviews, and offboarding when relationships end. The system ensures external users have appropriate access levels and maintains security through time-limited access and regular validation.

Examples

Example 1 — [Success] Automated lifecycle removes access post-contract Consultant invited for 6-month contract. Access package with 6-month expiration set. Quarterly access reviews scheduled. At 6-month mark, access automatically expires. No manual removal needed. Consultant cannot access systems anymore.

Example 2 — [Blocked] Manual offboarding creates orphaned access Vendor relationship ends. IT forgets to remove vendor user. User still has access to company data months later. Auditors find it during compliance review. Access was orphaned. Root cause: No automated lifecycle management, manual removal forgotten.

Key Mechanisms

- Core function: External user lifecycle management in Entra ID governs the complete journey of external users (partners, vendors, guests) from invitation through access provisioning to eventual removal. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Automated lifecycle removes access post-contract - Decision clue: Organizations use external user lifecycle management to balance collaboration needs with security requirements.

Review Path

**How to do it in Entra/Azure:**

**Configure External User Settings:**

1. **Set External Collaboration Settings:** - Azure Portal → Entra ID → External Identities → Cross-tenant access settings

2. **Configure Guest User Lifecycle:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization", "User.ReadWrite.All"

# Configure external user lifecycle policy $lifecycleParams = @{ "@odata.type" = "#microsoft.graph.externalUserLifecyclePolicy" displayName = "External User Lifecycle Policy" description = "Automated lifecycle management for external users" isEnabled = $true externalUserLifecycleAction = @{ disableSignInAfterInactivityInDays = 90 deleteAfterInactivityInDays = 180 removeAccessAfterInactivityInDays = 30 } scope = @{ "@odata.type" = "#microsoft.graph.allUsers" } } # Note: This is a conceptual example - actual API may vary Write-Host "External user lifecycle policy configured" ```

3. **Create External User Invitation Workflow:** ```powershell # Invite external user with lifecycle management function Invite-ExternalUserWithLifecycle { param( [string]$Email, [string]$DisplayName, [string]$SponsorId, [int]$AccessDurationDays = 180, [string]$BusinessJustification ) # Create invitation with lifecycle properties $invitationParams = @{ invitedUserEmailAddress = $Email invitedUserDisplayName = $DisplayName inviteRedirectUrl = "https://portal.azure.com" invitedUserMessageInfo = @{ customizedMessageBody = "Welcome! You have been invited to collaborate with our organization." } resetRedemption = $false } $invitation = New-MgInvitation -BodyParameter $invitationParams Write-Host "Invited user: $Email with ID: $($invitation.InvitedUser.Id)" # Set custom attributes for lifecycle management $userParams = @{ employeeType = "External" department = "Guest" extensionAttributes = @{ extensionAttribute1 = $SponsorId extensionAttribute2 = (Get-Date).AddDays($AccessDurationDays).ToString("yyyy-MM-dd") extensionAttribute3 = $BusinessJustification } } Update-MgUser -UserId $invitation.InvitedUser.Id -BodyParameter $userParams return $invitation } # Example usage $invitation = Invite-ExternalUserWithLifecycle -Email "partner@vendor.com" -DisplayName "John Partner" -SponsorId "sponsor-user-id" -AccessDurationDays 90 -BusinessJustification "Q4 project collaboration" ```

**Monitor External User Activity:** ```powershell # Get all external users and their activity $externalUsers = Get-MgUser -Filter "userType eq 'Guest'" -All

$externalUserReport = foreach ($user in $externalUsers) { # Get last sign-in activity $signInActivity = Get-MgAuditLogSignIn -Filter "userId eq '$($user.Id)'" -Top 1 -OrderBy "createdDateTime desc" # Get assigned groups and applications $groups = Get-MgUserMemberOf -UserId $user.Id $appAssignments = Get-MgUserAppRoleAssignment -UserId $user.Id # Calculate access metrics $invitationDate = $user.CreatedDateTime $lastSignIn = if ($signInActivity) { $signInActivity.CreatedDateTime } else { "Never" } $daysSinceInvitation = [math]::Ceiling(((Get-Date) - $invitationDate).TotalDays) $daysSinceLastSignIn = if ($signInActivity) { [math]::Ceiling(((Get-Date) - $signInActivity.CreatedDateTime).TotalDays) } else { "N/A" } [PSCustomObject]@{ DisplayName = $user.DisplayName Email = $user.Mail InvitationDate = $invitationDate LastSignIn = $lastSignIn DaysSinceInvitation = $daysSinceInvitation DaysSinceLastSignIn = $daysSinceLastSignIn GroupCount = $groups.Count AppAssignmentCount = $appAssignments.Count AccountEnabled = $user.AccountEnabled Sponsor = $user.ExtensionAttributes.extensionAttribute1 ExpiryDate = $user.ExtensionAttributes.extensionAttribute2 BusinessJustification = $user.ExtensionAttributes.extensionAttribute3 } }

$externalUserReport | Export-Csv -Path "ExternalUserReport.csv" -NoTypeInformation $externalUserReport | Format-Table -AutoSize ```

**Automated Lifecycle Management:** ```powershell # Automated cleanup of inactive external users function Start-ExternalUserLifecycleCleanup { param( [int]$InactivityThresholdDays = 90, [int]$GracePeriodDays = 7, [switch]$WhatIf ) $cutoffDate = (Get-Date).AddDays(-$InactivityThresholdDays) $externalUsers = Get-MgUser -Filter "userType eq 'Guest'" -All foreach ($user in $externalUsers) { try { # Check last sign-in $lastSignIn = Get-MgAuditLogSignIn -Filter "userId eq '$($user.Id)'" -Top 1 -OrderBy "createdDateTime desc" if (-not $lastSignIn -or $lastSignIn.CreatedDateTime -lt $cutoffDate) { $daysSinceLastActivity = if ($lastSignIn) { [math]::Ceiling(((Get-Date) - $lastSignIn.CreatedDateTime).TotalDays) } else { [math]::Ceiling(((Get-Date) - $user.CreatedDateTime).TotalDays) } Write-Host "Processing inactive user: $($user.DisplayName) ($daysSinceLastActivity days inactive)" if ($WhatIf) { Write-Host "WHAT IF: Would disable user $($user.DisplayName)" } else { # First disable the user Update-MgUser -UserId $user.Id -BodyParameter @{accountEnabled = $false} # Schedule for deletion after grace period $deletionDate = (Get-Date).AddDays($GracePeriodDays) Update-MgUser -UserId $user.Id -BodyParameter @{ extensionAttributes = @{ extensionAttribute15 = $deletionDate.ToString("yyyy-MM-dd") } } Write-Host "Disabled user: $($user.DisplayName), scheduled for deletion: $deletionDate" } } } catch { Write-Error "Failed to process user $($user.DisplayName): $($_.Exception.Message)" } } }

# Run cleanup (with WhatIf first) Start-ExternalUserLifecycleCleanup -InactivityThresholdDays 90 -WhatIf ```

**External User Access Reviews:** ```powershell # Create access review for external users $reviewParams = @{ displayName = "External User Access Review - Q4 2024" descriptionForAdmins = "Quarterly review of external user access" descriptionForReviewers = "Please review continued need for external user access" scope = @{ "@odata.type" = "#microsoft.graph.accessReviewQueryScope" query = "/users?\$filter=userType eq 'Guest'" queryType = "MicrosoftGraph" } reviewers = @( @{ query = "/users/{sponsor-id}" queryType = "MicrosoftGraph" } ) settings = @{ mailNotificationsEnabled = $true reminderNotificationsEnabled = $true justificationRequiredOnApproval = $true defaultDecisionEnabled = $false defaultDecision = "None" instanceDurationInDays = 14 autoApplyDecisionsEnabled = $true recommendationsEnabled = $true recurrence = @{ pattern = @{ type = "absoluteMonthly" interval = 3 month = 0 dayOfMonth = 1 } range = @{ type = "noEnd" startDate = (Get-Date).ToString("yyyy-MM-dd") } } } }

$accessReview = New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $reviewParams Write-Host "Created access review: $($accessReview.DisplayName)" ```

**External User Governance Dashboard:** ```powershell # Generate external user governance dashboard function Get-ExternalUserGovernanceDashboard { $externalUsers = Get-MgUser -Filter "userType eq 'Guest'" -All $totalExternal = $externalUsers.Count # Calculate metrics $activeUsers = ($externalUsers | Where-Object {$_.AccountEnabled -eq $true}).Count $inactiveUsers = $totalExternal - $activeUsers # Recent invitation activity $last30Days = (Get-Date).AddDays(-30) $recentInvitations = ($externalUsers | Where-Object {$_.CreatedDateTime -gt $last30Days}).Count # Expiring access $next30Days = (Get-Date).AddDays(30) $expiringUsers = ($externalUsers | Where-Object { $_.ExtensionAttributes.extensionAttribute2 -and [DateTime]$_.ExtensionAttributes.extensionAttribute2 -lt $next30Days }).Count # Sponsor distribution $sponsorStats = $externalUsers | Group-Object -Property {$_.ExtensionAttributes.extensionAttribute1} | Sort-Object Count -Descending | Select-Object -First 10 $dashboard = [PSCustomObject]@{ TotalExternalUsers = $totalExternal ActiveUsers = $activeUsers InactiveUsers = $inactiveUsers RecentInvitations = $recentInvitations ExpiringInNext30Days = $expiringUsers TopSponsors = $sponsorStats | ForEach-Object { @{ SponsorId = $_.Name UserCount = $_.Count } } LastUpdated = Get-Date } return $dashboard }

$dashboard = Get-ExternalUserGovernanceDashboard $dashboard | ConvertTo-Json -Depth 3 ```

**Best Practices:** 1. Always assign sponsors for external users 2. Set expiration dates for all external access 3. Implement regular access reviews (quarterly or semi-annually) 4. Monitor external user activity and disable inactive accounts 5. Use automation for lifecycle management 6. Maintain clear business justification for external access 7. Integrate with HR systems for partner relationship changes 8. Implement just-in-time access for sensitive resources

Explanation

Connected organizations in Entra ID Identity Governance represent external organizations that your users regularly collaborate with. These can be other Microsoft Entra ID tenants, partner companies, or federated domains. Connected organizations enable streamlined access management for external collaboration by defining trust relationships and allowing users from these organizations to request access to your resources through entitlement management.

Examples

Example 1 — [Success] Connected org streamlines partner access Partner company Acme Inc. is connected organization. Acme employees can request 'Project Collaboration' access package. Request auto-routes to your manager. Upon approval, Acme employees instantly get access to project SharePoint and Teams channel. No manual guest invitations needed.

Example 2 — [Blocked] Manual invitations create management nightmare No connected organizations. 50 Acme employees need access. Your IT manually invites each one. 50 separate email invites. Acme employees get confused. Some miss invites. Access revocation requires manual removal of 50 guests later. Root cause: Without connected organizations, B2B access is manual and unscalable.

Key Mechanisms

- Core function: Connected organizations in Entra ID Identity Governance represent external organizations that your users regularly collaborate with. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Connected org streamlines partner access - Decision clue: Organizations use connected organizations to automate and secure business-to-business collaboration.

Review Path

**How to do it in Entra/Azure:**

**Configure Connected Organizations:**

1. **Navigate to Connected Organizations:** - Azure Portal → Entra ID → Identity Governance → Entitlement management → Connected organizations

2. **Create Connected Organization:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"

# Create connected organization for Microsoft Entra ID tenant $connectedOrgParams = @{ displayName = "Partner Company Entra ID" description = "Main partner organization for project collaboration" identitySources = @( @{ "@odata.type" = "#microsoft.graph.azureActiveDirectoryTenant" displayName = "Partner Company" tenantId = "partner-tenant-id" } ) state = "configured" } $connectedOrg = New-MgEntitlementManagementConnectedOrganization -BodyParameter $connectedOrgParams Write-Host "Created connected organization: $($connectedOrg.DisplayName) with ID: $($connectedOrg.Id)"

# Create connected organization for domain-based $domainOrgParams = @{ displayName = "Vendor Domain Organization" description = "Vendor organization based on email domain" identitySources = @( @{ "@odata.type" = "#microsoft.graph.domainIdentitySource" displayName = "Vendor Domain" domainName = "vendor.com" } ) state = "configured" } $domainOrg = New-MgEntitlementManagementConnectedOrganization -BodyParameter $domainOrgParams Write-Host "Created domain-based connected organization: $($domainOrg.DisplayName)" ```

3. **Assign Sponsors to Connected Organizations:** ```powershell # Add internal sponsor $internalSponsorParams = @{ "@odata.id" = "https://graph.microsoft.com/v1.0/users/internal-sponsor-id" } New-MgEntitlementManagementConnectedOrganizationInternalSponsorByRef -ConnectedOrganizationId $connectedOrg.Id -BodyParameter $internalSponsorParams

# Add external sponsor (from connected organization) $externalSponsorParams = @{ "@odata.id" = "https://graph.microsoft.com/v1.0/users/external-sponsor-id" } New-MgEntitlementManagementConnectedOrganizationExternalSponsorByRef -ConnectedOrganizationId $connectedOrg.Id -BodyParameter $externalSponsorParams ```

**Configure Access Packages for Connected Organizations:** ```powershell # Create access package policy for connected organization $policyParams = @{ displayName = "Partner Access Policy" description = "Access policy for partner organization users" accessPackage = @{ id = "access-package-id" } canExtend = $false durationInDays = 180 requestorSettings = @{ scopeType = "SpecificConnectedOrganizationUsers" acceptRequests = $true allowedRequestors = @( @{ "@odata.type" = "#microsoft.graph.connectedOrganizationMembers" id = $connectedOrg.Id description = "All users from partner organization" } ) } requestApprovalSettings = @{ isApprovalRequired = $true isApprovalRequiredForExtension = $true isRequestorJustificationRequired = $true approvalMode = "TwoStage" approvalStages = @( @{ approvalStageTimeOutInDays = 7 isApproverJustificationRequired = $true primaryApprovers = @( @{ "@odata.type" = "#microsoft.graph.connectedOrganizationInternalSponsors" id = $connectedOrg.Id } ) }, @{ approvalStageTimeOutInDays = 14 isApproverJustificationRequired = $true primaryApprovers = @( @{ "@odata.type" = "#microsoft.graph.singleUser" userId = "final-approver-id" } ) } ) } }

New-MgEntitlementManagementAccessPackageAssignmentPolicy -BodyParameter $policyParams ```

**Monitor Connected Organization Activity:** ```powershell # Get all connected organizations and their usage $connectedOrgs = Get-MgEntitlementManagementConnectedOrganization -All

$orgReport = foreach ($org in $connectedOrgs) { # Get access package assignments from this organization $assignments = Get-MgEntitlementManagementAccessPackageAssignment -Filter "target/connectedOrganizationId eq '$($org.Id)'" # Get active requests $requests = Get-MgEntitlementManagementAccessPackageAssignmentRequest -Filter "requestor/connectedOrganizationId eq '$($org.Id)'" # Calculate metrics $activeAssignments = ($assignments | Where-Object {$_.State -eq "Delivered"}).Count $pendingRequests = ($requests | Where-Object {$_.RequestState -eq "Submitted"}).Count [PSCustomObject]@{ OrganizationName = $org.DisplayName State = $org.State IdentitySourceType = $org.IdentitySources[0].'@odata.type' IdentitySourceName = if ($org.IdentitySources[0].'@odata.type' -eq "#microsoft.graph.azureActiveDirectoryTenant") { $org.IdentitySources[0].tenantId } else { $org.IdentitySources[0].domainName } ActiveAssignments = $activeAssignments PendingRequests = $pendingRequests InternalSponsors = (Get-MgEntitlementManagementConnectedOrganizationInternalSponsor -ConnectedOrganizationId $org.Id).Count ExternalSponsors = (Get-MgEntitlementManagementConnectedOrganizationExternalSponsor -ConnectedOrganizationId $org.Id).Count CreatedDate = $org.CreatedDateTime ModifiedDate = $org.ModifiedDateTime } }

$orgReport | Export-Csv -Path "ConnectedOrganizationsReport.csv" -NoTypeInformation $orgReport | Format-Table -AutoSize ```

**Manage Organization Relationships:** ```powershell # Update connected organization state $updateParams = @{ state = "proposed" # or "configured" description = "Updated description for organization relationship" }

Update-MgEntitlementManagementConnectedOrganization -ConnectedOrganizationId $connectedOrg.Id -BodyParameter $updateParams

# Remove inactive connected organization $inactiveOrgs = $connectedOrgs | Where-Object { $assignments = Get-MgEntitlementManagementAccessPackageAssignment -Filter "target/connectedOrganizationId eq '$($_.Id)'" $activeAssignments = $assignments | Where-Object {$_.State -eq "Delivered"} $activeAssignments.Count -eq 0 -and (Get-Date) - $_.ModifiedDateTime -gt [TimeSpan]::FromDays(365) }

foreach ($inactiveOrg in $inactiveOrgs) { Write-Host "Consider removing inactive organization: $($inactiveOrg.DisplayName)" # Remove-MgEntitlementManagementConnectedOrganization -ConnectedOrganizationId $inactiveOrg.Id } ```

**Automate Organization Discovery:** ```powershell # Discover potential connected organizations from access requests $allRequests = Get-MgEntitlementManagementAccessPackageAssignmentRequest -All $externalDomains = @{}

foreach ($request in $allRequests) { $requestor = Get-MgUser -UserId $request.RequestorId -ErrorAction SilentlyContinue if ($requestor -and $requestor.UserType -eq "Guest") { $domain = ($requestor.Mail -split "@")[1] if ($externalDomains.ContainsKey($domain)) { $externalDomains[$domain]++ } else { $externalDomains[$domain] = 1 } } }

# Suggest new connected organizations based on usage $suggestions = $externalDomains.GetEnumerator() | Where-Object {$_.Value -ge 5} | Sort-Object Value -Descending

Write-Host "Suggested Connected Organizations based on request patterns:" foreach ($suggestion in $suggestions) { Write-Host "Domain: $($suggestion.Key), Request Count: $($suggestion.Value)" # Check if already exists $existing = $connectedOrgs | Where-Object { $_.IdentitySources | Where-Object {$_.domainName -eq $suggestion.Key} } if (-not $existing) { Write-Host " -> Consider creating connected organization for $($suggestion.Key)" } } ```

**Bulk Operations:** ```powershell # Bulk create connected organizations from CSV $orgsToCreate = Import-Csv -Path "NewConnectedOrgs.csv" # DisplayName,Type,TenantId/Domain,Description

foreach ($orgData in $orgsToCreate) { try { if ($orgData.Type -eq "AzureAD") { $params = @{ displayName = $orgData.DisplayName description = $orgData.Description identitySources = @( @{ "@odata.type" = "#microsoft.graph.azureActiveDirectoryTenant" displayName = $orgData.DisplayName tenantId = $orgData.TenantId } ) state = "configured" } } else { $params = @{ displayName = $orgData.DisplayName description = $orgData.Description identitySources = @( @{ "@odata.type" = "#microsoft.graph.domainIdentitySource" displayName = $orgData.DisplayName domainName = $orgData.Domain } ) state = "configured" } } $newOrg = New-MgEntitlementManagementConnectedOrganization -BodyParameter $params Write-Host "Created: $($newOrg.DisplayName)" } catch { Write-Error "Failed to create $($orgData.DisplayName): $($_.Exception.Message)" } } ```

**Best Practices:** 1. Use Microsoft Entra ID tenant connections for verified partner organizations 2. Use domain-based connections for broader collaboration scenarios 3. Assign both internal and external sponsors for better governance 4. Regularly review and clean up unused connected organizations 5. Monitor access patterns to identify new potential connections 6. Implement approval workflows appropriate for each organization's trust level 7. Document business relationships and update descriptions regularly

Explanation

Access reviews planning involves designing systematic processes to periodically validate user access rights across your organization. This includes defining review scopes, selecting appropriate reviewers, setting review frequencies, and establishing decision criteria. Proper planning ensures comprehensive coverage of access permissions while minimizing administrative overhead and maintaining security compliance.

Examples

Example 1 — [Success] Well-planned reviews catch access drift Plan: Quarterly review of privileged roles, manager as reviewer, 14-day window, fallback reviewer assigned. Q1 review finds user still in role 6 months after project ended. Manager removes them. Access drift prevented systematically.

Example 2 — [Blocked] No review planning means access accumulates No formal access review process. Users keep old roles when projects end. After 2 years, 40% of employees have access they don't need. Attacker compromises one employee, gets access to 5 systems. Root cause: Without planned reviews, access sprawl goes undetected.

Key Mechanisms

- Core function: Access reviews planning involves designing systematic processes to periodically validate user access rights across your organization. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Well-planned reviews catch access drift - Decision clue: Organizations use access review planning to maintain least-privilege access, meet compliance requirements, and reduce security risks.

Review Path

**How to do it in Entra/Azure:**

**Plan Access Review Strategy:**

1. **Assess Current Access Landscape:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "AccessReview.ReadWrite.All", "Directory.Read.All"

# Analyze current access patterns function Get-AccessAnalysis { $analysis = @{ TotalUsers = (Get-MgUser -All).Count AdminRoles = @() Applications = @() Groups = @() GuestUsers = (Get-MgUser -Filter "userType eq 'Guest'" -All).Count } # Get privileged roles $roles = Get-MgDirectoryRole -All foreach ($role in $roles) { $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id if ($members.Count -gt 0) { $analysis.AdminRoles += @{ RoleName = $role.DisplayName MemberCount = $members.Count RiskLevel = if ($role.DisplayName -like "*Admin*") { "High" } else { "Medium" } } } } # Get applications with assignments $apps = Get-MgApplication -All foreach ($app in $apps) { $assignments = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $app.Id -ErrorAction SilentlyContinue if ($assignments.Count -gt 0) { $analysis.Applications += @{ AppName = $app.DisplayName AssignmentCount = $assignments.Count LastModified = $app.CreatedDateTime } } } # Get groups with members $groups = Get-MgGroup -All foreach ($group in $groups | Select-Object -First 50) { # Limit for performance $members = Get-MgGroupMember -GroupId $group.Id -ErrorAction SilentlyContinue if ($members.Count -gt 0) { $analysis.Groups += @{ GroupName = $group.DisplayName MemberCount = $members.Count GroupType = $group.GroupTypes } } } return $analysis } $accessAnalysis = Get-AccessAnalysis $accessAnalysis | ConvertTo-Json -Depth 3 | Out-File "AccessAnalysis.json" ```

2. **Design Review Categories:** ```powershell # Define review categories based on analysis $reviewCategories = @{ HighRiskRoles = @{ Scope = "Privileged administrative roles" Frequency = "Quarterly" Reviewers = "Role owners and managers" AutoApply = $false JustificationRequired = $true } Applications = @{ Scope = "Application access assignments" Frequency = "Annual" Reviewers = "Application owners" AutoApply = $true JustificationRequired = $false } SecurityGroups = @{ Scope = "Security groups with business access" Frequency = "Semi-annual" Reviewers = "Group owners and managers" AutoApply = $false JustificationRequired = $true } GuestUsers = @{ Scope = "External guest users" Frequency = "Quarterly" Reviewers = "User sponsors" AutoApply = $false JustificationRequired = $true } } $reviewCategories | ConvertTo-Json -Depth 2 ```

**Create Review Planning Template:** ```powershell # Create standardized review planning template function New-AccessReviewPlan { param( [string]$ReviewName, [string]$Category, [string]$Scope, [string]$Frequency, [string[]]$ReviewerTypes, [bool]$RequireJustification = $true, [bool]$AutoApplyResults = $false, [int]$DurationDays = 14 ) $plan = @{ reviewName = $ReviewName category = $Category scope = $Scope schedule = @{ frequency = $Frequency durationDays = $DurationDays startDate = (Get-Date).AddDays(7).ToString("yyyy-MM-dd") } reviewers = $ReviewerTypes settings = @{ requireJustification = $RequireJustification autoApplyResults = $AutoApplyResults sendReminders = $true defaultDecision = "None" } communications = @{ enableNotifications = $true customMessage = "Please review access permissions for compliance and security." } } return $plan }

# Create review plans for each category $reviewPlans = @()

$reviewPlans += New-AccessReviewPlan -ReviewName "Quarterly Admin Role Review" -Category "HighRiskRoles" -Scope "Global Admin, Security Admin, User Admin roles" -Frequency "Quarterly" -ReviewerTypes @("Manager", "RoleOwner")

$reviewPlans += New-AccessReviewPlan -ReviewName "Annual Application Access Review" -Category "Applications" -Scope "All enterprise applications" -Frequency "Annual" -ReviewerTypes @("ResourceOwner") -AutoApplyResults $true -RequireJustification $false

$reviewPlans += New-AccessReviewPlan -ReviewName "Semi-Annual Group Membership Review" -Category "SecurityGroups" -Scope "Security groups and Microsoft 365 groups" -Frequency "Semi-annual" -ReviewerTypes @("GroupOwner", "Manager")

$reviewPlans += New-AccessReviewPlan -ReviewName "Quarterly Guest User Review" -Category "GuestUsers" -Scope "All guest users" -Frequency "Quarterly" -ReviewerTypes @("UserSponsor")

$reviewPlans | Export-Clixml -Path "AccessReviewPlans.xml" ```

**Configure Review Schedules:** ```powershell # Create review schedule calendar function New-ReviewSchedule { param([array]$ReviewPlans) $currentYear = (Get-Date).Year $schedule = @() foreach ($plan in $ReviewPlans) { $frequency = $plan.schedule.frequency $startDate = [DateTime]$plan.schedule.startDate switch ($frequency) { "Quarterly" { for ($quarter = 1; $quarter -le 4; $quarter++) { $reviewDate = $startDate.AddMonths(($quarter - 1) * 3) $schedule += @{ ReviewName = $plan.reviewName ScheduledDate = $reviewDate.ToString("yyyy-MM-dd") Quarter = "Q$quarter" DurationDays = $plan.schedule.durationDays EndDate = $reviewDate.AddDays($plan.schedule.durationDays).ToString("yyyy-MM-dd") } } } "Semi-annual" { for ($half = 1; $half -le 2; $half++) { $reviewDate = $startDate.AddMonths(($half - 1) * 6) $schedule += @{ ReviewName = $plan.reviewName ScheduledDate = $reviewDate.ToString("yyyy-MM-dd") Period = "H$half" DurationDays = $plan.schedule.durationDays EndDate = $reviewDate.AddDays($plan.schedule.durationDays).ToString("yyyy-MM-dd") } } } "Annual" { $schedule += @{ ReviewName = $plan.reviewName ScheduledDate = $startDate.ToString("yyyy-MM-dd") Period = "Annual" DurationDays = $plan.schedule.durationDays EndDate = $startDate.AddDays($plan.schedule.durationDays).ToString("yyyy-MM-dd") } } } } return $schedule | Sort-Object ScheduledDate }

$reviewSchedule = New-ReviewSchedule -ReviewPlans $reviewPlans $reviewSchedule | Export-Csv -Path "AccessReviewSchedule.csv" -NoTypeInformation $reviewSchedule | Format-Table -AutoSize ```

**Plan Reviewer Assignments:** ```powershell # Map reviewers to access review scenarios function Get-ReviewerMapping { $reviewerMap = @{ Roles = @{ "Global Administrator" = @("CEO", "CISO", "IT Director") "Security Administrator" = @("CISO", "Security Manager") "User Administrator" = @("HR Director", "IT Manager") "Helpdesk Administrator" = @("IT Manager", "Support Manager") } Applications = @{ "High-Risk Apps" = @("Application Owner", "Security Team") "Business Apps" = @("Application Owner", "Business Owner") "Development Apps" = @("Dev Lead", "IT Manager") } Groups = @{ "Executive Groups" = @("CEO", "Board Member") "Department Groups" = @("Department Manager", "HR Partner") "Project Groups" = @("Project Manager", "Resource Owner") } } return $reviewerMap }

# Generate reviewer assignment report $reviewerMapping = Get-ReviewerMapping $reviewerAssignments = @()

foreach ($category in $reviewerMapping.Keys) { foreach ($resource in $reviewerMapping[$category].Keys) { $reviewers = $reviewerMapping[$category][$resource] $reviewerAssignments += [PSCustomObject]@{ Category = $category Resource = $resource PrimaryReviewer = $reviewers[0] SecondaryReviewer = if ($reviewers.Count -gt 1) { $reviewers[1] } else { "None" } BackupReviewer = if ($reviewers.Count -gt 2) { $reviewers[2] } else { "None" } } } }

$reviewerAssignments | Export-Csv -Path "ReviewerAssignments.csv" -NoTypeInformation ```

**Create Review Planning Dashboard:** ```powershell # Generate comprehensive planning dashboard function Get-AccessReviewPlanningDashboard { $dashboard = @{ PlanningMetrics = @{ TotalReviewsPlanned = $reviewPlans.Count QuarterlyReviews = ($reviewPlans | Where-Object {$_.schedule.frequency -eq "Quarterly"}).Count AnnualReviews = ($reviewPlans | Where-Object {$_.schedule.frequency -eq "Annual"}).Count SemiAnnualReviews = ($reviewPlans | Where-Object {$_.schedule.frequency -eq "Semi-annual"}).Count } CoverageAnalysis = @{ UsersInScope = $accessAnalysis.TotalUsers RolesInScope = $accessAnalysis.AdminRoles.Count ApplicationsInScope = $accessAnalysis.Applications.Count GroupsInScope = $accessAnalysis.Groups.Count GuestUsersInScope = $accessAnalysis.GuestUsers } UpcomingReviews = ($reviewSchedule | Where-Object { [DateTime]$_.ScheduledDate -ge (Get-Date) -and [DateTime]$_.ScheduledDate -le (Get-Date).AddDays(30) }) ReviewerWorkload = $reviewerAssignments | Group-Object PrimaryReviewer | ForEach-Object { @{ ReviewerName = $_.Name AssignedReviews = $_.Count Categories = ($_.Group.Category | Sort-Object -Unique) -join ", " } } } return $dashboard }

$planningDashboard = Get-AccessReviewPlanningDashboard $planningDashboard | ConvertTo-Json -Depth 4 | Out-File "AccessReviewPlanningDashboard.json" ```

**Validate Review Plans:** ```powershell # Validate review plans for completeness and conflicts function Test-AccessReviewPlans { param([array]$Plans, [array]$Schedule) $validation = @{ Issues = @() Warnings = @() Recommendations = @() } # Check for scheduling conflicts $groupedSchedule = $Schedule | Group-Object ScheduledDate foreach ($group in $groupedSchedule) { if ($group.Count -gt 2) { $validation.Warnings += "Multiple reviews scheduled for $($group.Name): $($group.Group.ReviewName -join ', ')" } } # Check reviewer coverage $allReviewers = $Plans | ForEach-Object {$_.reviewers} | Sort-Object -Unique if ($allReviewers.Count -lt 3) { $validation.Issues += "Insufficient reviewer diversity. Consider adding more reviewer types." } # Check frequency alignment $highRiskPlans = $Plans | Where-Object {$_.category -eq "HighRiskRoles"} foreach ($plan in $highRiskPlans) { if ($plan.schedule.frequency -notin @("Quarterly", "Monthly")) { $validation.Issues += "High-risk role review '$($plan.reviewName)' should be quarterly or monthly" } } # Check auto-apply settings $autoApplyPlans = $Plans | Where-Object {$_.settings.autoApplyResults -eq $true} foreach ($plan in $autoApplyPlans) { if ($plan.category -eq "HighRiskRoles") { $validation.Issues += "Auto-apply should not be enabled for high-risk role reviews" } } return $validation }

$planValidation = Test-AccessReviewPlans -Plans $reviewPlans -Schedule $reviewSchedule $planValidation | ConvertTo-Json -Depth 2 ```

**Best Practices:** 1. Start with high-risk access (privileged roles, sensitive applications) 2. Balance review frequency with reviewer workload 3. Use appropriate reviewers (managers for users, owners for resources) 4. Implement staggered scheduling to avoid reviewer overload 5. Plan for backup reviewers in case of unavailability 6. Document decision criteria and provide reviewer training 7. Test review processes with pilot groups before full deployment 8. Integrate review planning with compliance calendar

Explanation

Access reviews configuration involves setting up automated review processes in Entra ID Identity Governance to systematically validate user access rights. This includes defining review scopes, configuring reviewer assignments, setting approval workflows, and establishing automated actions based on review outcomes. Proper configuration ensures consistent, repeatable access validation processes that maintain security and compliance.

Think of it as: Access reviews are permission inspections — if the reviewer doesn't show up for inspection and you have 'fail if no response,' the permission automatically gets revoked (like a failed inspection closing a restaurant).

Key Mechanics: - Reviewer must actively approve or deny access within the review period - 'Apply results automatically' + 'Remove if no response' = no response = access REMOVED - 'Default decision' setting controls what happens if reviewer doesn't respond - If 'default decision' = deny and auto-apply enabled = access auto-removed on timeout - Failure condition: Assuming 'no response = access preserved' when auto-apply removes on timeout

Examples

Example 1 — [Success] Default decision configured correctly Admin sets up quarterly access review for Finance group with auto-apply enabled and 'default decision = approve.' Review period is 14 days. If manager doesn't respond, users remain in group. Review completes, access preserved for responsive and non-responsive users.

Example 2 — [Blocked] Auto-removal on no response surprises admins Admin sets up access review with 'Auto-apply results = ON' and 'If no response = Remove.' Manager goes on vacation during 14-day review and doesn't respond. Review ends, and 15 users automatically lose access to Finance app (not preserved, but removed). Root cause: Admin didn't set appropriate default decision — assumed no response = status quo, but auto-removal removed access.

Key Mechanisms

- Core function: Access reviews configuration involves setting up automated review processes in Entra ID Identity Governance to systematically validate user access rights. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Default decision configured correctly - Decision clue: Organizations use access review configuration to automate compliance processes, reduce manual oversight, and ensure consistent access validation.

Review Path

**How to do it in Entra/Azure:**

**Basic Access Review Configuration:**

1. **Navigate to Access Reviews:** - Azure Portal → Entra ID → Identity Governance → Access reviews

2. **Create Basic Access Review:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "AccessReview.ReadWrite.All"

# Configure basic group membership review $reviewParams = @{ displayName = "Quarterly Group Membership Review" descriptionForAdmins = "Review of security group memberships for compliance" descriptionForReviewers = "Please verify that users still require access to this group" scope = @{ "@odata.type" = "#microsoft.graph.accessReviewQueryScope" query = "/groups/{group-id}/transitiveMembers" queryType = "MicrosoftGraph" } reviewers = @( @{ query = "/users/{manager-id}" queryType = "MicrosoftGraph" } ) fallbackReviewers = @( @{ query = "/users/{backup-reviewer-id}" queryType = "MicrosoftGraph" } ) settings = @{ mailNotificationsEnabled = $true reminderNotificationsEnabled = $true justificationRequiredOnApproval = $true defaultDecisionEnabled = $false defaultDecision = "None" instanceDurationInDays = 14 autoApplyDecisionsEnabled = $false recommendationsEnabled = $true recurrence = @{ pattern = @{ type = "absoluteMonthly" interval = 3 month = 0 dayOfMonth = 1 } range = @{ type = "noEnd" startDate = (Get-Date).ToString("yyyy-MM-dd") } } } } $accessReview = New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $reviewParams Write-Host "Created access review: $($accessReview.DisplayName) with ID: $($accessReview.Id)" ```

**Best Practices:** 1. Start with pilot reviews for high-risk access 2. Use appropriate review durations (7-21 days typically) 3. Configure fallback reviewers for continuity 4. Enable recommendations to help reviewers 5. Use auto-apply carefully, especially for privileged access 6. Set up proper notification templates 7. Monitor review completion rates and adjust as needed 8. Document review purposes and decision criteria clearly

Explanation

Access reviews monitoring involves tracking the progress, completion rates, and outcomes of configured access review processes. This includes monitoring reviewer response rates, analyzing review decisions, identifying bottlenecks, and measuring compliance with review policies. Effective monitoring ensures review processes are functioning as intended and provides insights for process optimization.

Examples

Example 1 — [Success] Monitoring catches low completion rates Dashboard shows Q1 review: 60% completed, 30% overdue, 10% pending. IT alerts Finance manager whose team has 0% completion. Manager follows up, gets 95% completion within 3 days. Root cause identified: unclear instructions. Process improved.

Example 2 — [Blocked] No monitoring means missing reviews No monitoring dashboard. Reviews run but nobody tracks completion. HR was supposed to complete review but forgot. Audit two months later finds review never finished. Compliance gap. Root cause: No visibility into review progress.

Key Mechanisms

- Core function: Access reviews monitoring involves tracking the progress, completion rates, and outcomes of configured access review processes. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Monitoring catches low completion rates - Decision clue: Organizations use access review monitoring to ensure governance processes are effective, meet compliance requirements, and identify areas for improvement.

Review Path

**How to do it in Entra/Azure:**

**Set Up Review Monitoring:**

1. **Monitor Review Status:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "AccessReview.Read.All"

# Get all access review definitions and their status function Get-AccessReviewStatus { $reviews = Get-MgIdentityGovernanceAccessReviewDefinition -All $statusReport = @() foreach ($review in $reviews) { $instances = Get-MgIdentityGovernanceAccessReviewDefinitionInstance -AccessReviewScheduleDefinitionId $review.Id foreach ($instance in $instances) { $decisions = Get-MgIdentityGovernanceAccessReviewDefinitionInstanceDecision -AccessReviewScheduleDefinitionId $review.Id -AccessReviewInstanceId $instance.Id $totalDecisions = $decisions.Count $completedDecisions = ($decisions | Where-Object {$_.Decision -ne "NotReviewed"}).Count $completionRate = if ($totalDecisions -gt 0) { [math]::Round(($completedDecisions / $totalDecisions) * 100, 2) } else { 0 } $statusReport += [PSCustomObject]@{ ReviewName = $review.DisplayName Status = $instance.Status CompletionRate = "$completionRate%" IsOverdue = (Get-Date) -gt $instance.EndDateTime -and $instance.Status -eq "InProgress" } } } return $statusReport } $reviewStatus = Get-AccessReviewStatus $reviewStatus | Format-Table -AutoSize ```

**Best Practices:** 1. Monitor completion rates daily for active reviews 2. Set up automated alerts for overdue reviews 3. Track reviewer performance and provide feedback 4. Analyze decision patterns for quality assurance 5. Generate regular compliance reports for stakeholders 6. Monitor review duration and optimize as needed 7. Use dashboards for real-time visibility 8. Document lessons learned and process improvements

Explanation

Access reviews response encompasses the actions taken based on access review outcomes, including implementing reviewer decisions, handling appeals, and executing automated remediation. This includes removing denied access, maintaining approved access, addressing incomplete reviews, and documenting decisions for audit purposes. Effective response processes ensure review decisions are properly implemented and maintained.

Examples

Example 1 — [Success] Review decisions properly implemented Review decision: User A denied (doesn't need role anymore). System automatically removes user from role, sends confirmation email, logs action. All decisions implemented within 24 hours with full audit trail.

Example 2 — [Blocked] Review decisions not implemented Review complete: 30 access denials recorded. Nobody removes the denied users. 30 days later, those users still have access. Audit finds decisions weren't implemented. Root cause: No response process to execute review decisions.

Key Mechanisms

- Core function: Access reviews response encompasses the actions taken based on access review outcomes, including implementing reviewer decisions, handling appeals, and executing automated remediation. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Review decisions properly implemented - Decision clue: Organizations use access review response processes to ensure review decisions are effectively implemented, maintain audit trails for compliance, and provide mechanisms for addressing disputed decisions.

Review Path

**How to do it in Entra/Azure:**

**Implement Review Decisions:**

1. **Process Review Outcomes:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "AccessReview.ReadWrite.All", "Directory.ReadWrite.All"

# Process completed review decisions function Invoke-AccessReviewResponse { param( [string]$ReviewDefinitionId, [string]$InstanceId ) # Get review decisions $decisions = Get-MgIdentityGovernanceAccessReviewDefinitionInstanceDecision -AccessReviewScheduleDefinitionId $ReviewDefinitionId -AccessReviewInstanceId $InstanceId $responseReport = @() foreach ($decision in $decisions) { $action = "None" $success = $false $errorMessage = $null try { switch ($decision.Decision) { "Deny" { # Remove access based on decision target if ($decision.Target.'@odata.type' -eq "#microsoft.graph.userTarget") { # Remove user from group/role $userId = $decision.Target.Id $resourceId = $decision.Resource.Id if ($decision.Resource.'@odata.type' -eq "#microsoft.graph.group") { Remove-MgGroupMember -GroupId $resourceId -DirectoryObjectId $userId $action = "Removed from group" } elseif ($decision.Resource.'@odata.type' -eq "#microsoft.graph.directoryRole") { Remove-MgDirectoryRoleMember -DirectoryRoleId $resourceId -DirectoryObjectId $userId $action = "Removed from role" } $success = $true } } "Approve" { # Maintain access - no action needed, but log approval $action = "Access maintained" $success = $true } "NotReviewed" { # Handle based on default policy $reviewDefinition = Get-MgIdentityGovernanceAccessReviewDefinition -AccessReviewScheduleDefinitionId $ReviewDefinitionId if ($reviewDefinition.Settings.DefaultDecision -eq "Deny") { # Apply deny action $action = "Auto-denied (not reviewed)" # Implement removal logic here } else { $action = "No action (not reviewed)" } $success = $true } } } catch { $errorMessage = $_.Exception.Message Write-Error "Failed to process decision for $($decision.Target.Id): $errorMessage" } $responseReport += [PSCustomObject]@{ DecisionId = $decision.Id TargetId = $decision.Target.Id TargetName = $decision.Target.DisplayName ResourceName = $decision.Resource.DisplayName Decision = $decision.Decision ActionTaken = $action Success = $success ErrorMessage = $errorMessage ProcessedDate = Get-Date ReviewedBy = $decision.ReviewedBy Justification = $decision.Justification } } return $responseReport } # Example usage $reviewId = "your-review-definition-id" $instanceId = "your-instance-id" $responseReport = Invoke-AccessReviewResponse -ReviewDefinitionId $reviewId -InstanceId $instanceId $responseReport | Export-Csv -Path "AccessReviewResponse.csv" -NoTypeInformation ```

2. **Handle Appeals Process:** ```powershell # Create appeals management system function New-AccessReviewAppeal { param( [string]$DecisionId, [string]$AppellantId, [string]$Justification, [string]$ReviewerId ) $appeal = @{ Id = [System.Guid]::NewGuid().ToString() DecisionId = $DecisionId AppellantId = $AppellantId AppellantName = (Get-MgUser -UserId $AppellantId).DisplayName Justification = $Justification Status = "Pending" SubmittedDate = Get-Date ReviewerId = $ReviewerId ReviewerName = (Get-MgUser -UserId $ReviewerId).DisplayName ReviewDate = $null FinalDecision = $null ReviewerJustification = $null } # Store appeal (in practice, this would go to a database or SharePoint list) $appealsFile = "AccessReviewAppeals.json" $appeals = @() if (Test-Path $appealsFile) { $appeals = Get-Content $appealsFile | ConvertFrom-Json } $appeals += $appeal $appeals | ConvertTo-Json -Depth 2 | Out-File $appealsFile Write-Host "Appeal created with ID: $($appeal.Id)" return $appeal } function Process-AccessReviewAppeal { param( [string]$AppealId, [string]$Decision, # "Approve" or "Deny" [string]$Justification ) $appealsFile = "AccessReviewAppeals.json" $appeals = Get-Content $appealsFile | ConvertFrom-Json $appeal = $appeals | Where-Object {$_.Id -eq $AppealId} if ($appeal) { $appeal.Status = "Reviewed" $appeal.FinalDecision = $Decision $appeal.ReviewerJustification = $Justification $appeal.ReviewDate = Get-Date # If appeal is approved, restore access if ($Decision -eq "Approve") { # Implement access restoration logic Write-Host "Restoring access for appeal $AppealId" } $appeals | ConvertTo-Json -Depth 2 | Out-File $appealsFile Write-Host "Appeal $AppealId processed with decision: $Decision" } } ```

**Generate Response Reports:** ```powershell # Create comprehensive response reporting function Get-AccessReviewResponseReport { param( [DateTime]$StartDate = (Get-Date).AddMonths(-1), [DateTime]$EndDate = (Get-Date) ) $reviews = Get-MgIdentityGovernanceAccessReviewDefinition -All $responseReport = @{ ReportPeriod = "$($StartDate.ToString('yyyy-MM-dd')) to $($EndDate.ToString('yyyy-MM-dd'))" Summary = @{ TotalDecisions = 0 ActionsImplemented = 0 AccessRemoved = 0 AccessMaintained = 0 AppealsSubmitted = 0 AppealsApproved = 0 } DetailedActions = @() ComplianceMetrics = @{} Recommendations = @() } foreach ($review in $reviews) { $instances = Get-MgIdentityGovernanceAccessReviewDefinitionInstance -AccessReviewScheduleDefinitionId $review.Id | Where-Object {$_.EndDateTime -ge $StartDate -and $_.EndDateTime -le $EndDate -and $_.Status -eq "Completed"} foreach ($instance in $instances) { $decisions = Get-MgIdentityGovernanceAccessReviewDefinitionInstanceDecision -AccessReviewScheduleDefinitionId $review.Id -AccessReviewInstanceId $instance.Id foreach ($decision in $decisions) { $responseReport.Summary.TotalDecisions++ $actionTaken = switch ($decision.Decision) { "Approve" { $responseReport.Summary.AccessMaintained++ "Access Maintained" } "Deny" { $responseReport.Summary.AccessRemoved++ "Access Removed" } default { "No Action" } } if ($decision.Decision -ne "NotReviewed") { $responseReport.Summary.ActionsImplemented++ } $responseReport.DetailedActions += [PSCustomObject]@{ ReviewName = $review.DisplayName TargetName = $decision.Target.DisplayName ResourceName = $decision.Resource.DisplayName Decision = $decision.Decision ActionTaken = $actionTaken ReviewedBy = $decision.ReviewedBy ReviewedDate = $decision.ReviewedDateTime Justification = $decision.Justification } } } } # Calculate compliance metrics if ($responseReport.Summary.TotalDecisions -gt 0) { $responseReport.ComplianceMetrics = @{ ActionImplementationRate = [math]::Round(($responseReport.Summary.ActionsImplemented / $responseReport.Summary.TotalDecisions) * 100, 2) RiskMitigationRate = [math]::Round(($responseReport.Summary.AccessRemoved / $responseReport.Summary.TotalDecisions) * 100, 2) } } # Add recommendations if ($responseReport.ComplianceMetrics.ActionImplementationRate -lt 95) { $responseReport.Recommendations += "Improve action implementation processes - some review decisions are not being executed" } if ($responseReport.ComplianceMetrics.RiskMitigationRate -lt 5) { $responseReport.Recommendations += "Review approval criteria - very low access removal rate may indicate insufficient scrutiny" } return $responseReport }

$responseReport = Get-AccessReviewResponseReport $responseReport | ConvertTo-Json -Depth 3 | Out-File "AccessReviewResponseReport_$(Get-Date -Format 'yyyy-MM-dd').json" ```

**Automated Response Workflows:** ```powershell # Set up automated response workflows function Start-AutomatedAccessReviewResponse { param( [int]$CheckIntervalMinutes = 60 ) while ($true) { try { Write-Host "$(Get-Date): Checking for completed access reviews..." # Get completed review instances $reviews = Get-MgIdentityGovernanceAccessReviewDefinition -All $actionsToProcess = @() foreach ($review in $reviews) { $instances = Get-MgIdentityGovernanceAccessReviewDefinitionInstance -AccessReviewScheduleDefinitionId $review.Id | Where-Object {$_.Status -eq "Completed" -and $_.EndDateTime -gt (Get-Date).AddHours(-24)} foreach ($instance in $instances) { if ($review.Settings.AutoApplyDecisionsEnabled) { Write-Host "Processing auto-apply for review: $($review.DisplayName)" $responseResult = Invoke-AccessReviewResponse -ReviewDefinitionId $review.Id -InstanceId $instance.Id $actionsToProcess += $responseResult } } } if ($actionsToProcess.Count -gt 0) { Write-Host "Processed $($actionsToProcess.Count) review decisions" $actionsToProcess | Export-Csv -Path "AutoProcessedActions_$(Get-Date -Format 'yyyy-MM-dd-HH-mm').csv" -NoTypeInformation } Start-Sleep -Seconds ($CheckIntervalMinutes * 60) } catch { Write-Error "Error in automated response processing: $($_.Exception.Message)" Start-Sleep -Seconds 300 # Wait 5 minutes on error } } }

# Run automated response processing (for demonstration) # Start-AutomatedAccessReviewResponse -CheckIntervalMinutes 30 ```

**Audit Trail Management:** ```powershell # Maintain comprehensive audit trails function New-AccessReviewAuditEntry { param( [string]$ReviewId, [string]$Action, [string]$TargetId, [string]$Details, [string]$PerformedBy ) $auditEntry = @{ Timestamp = Get-Date ReviewId = $ReviewId Action = $Action TargetId = $TargetId TargetName = if ($TargetId) { (Get-MgUser -UserId $TargetId -ErrorAction SilentlyContinue).DisplayName } else { $null } Details = $Details PerformedBy = $PerformedBy PerformedByName = if ($PerformedBy) { (Get-MgUser -UserId $PerformedBy -ErrorAction SilentlyContinue).DisplayName } else { "System" } } # Store audit entry $auditFile = "AccessReviewAuditTrail.json" $auditEntries = @() if (Test-Path $auditFile) { $auditEntries = Get-Content $auditFile | ConvertFrom-Json } $auditEntries += $auditEntry $auditEntries | ConvertTo-Json -Depth 2 | Out-File $auditFile return $auditEntry }

# Generate audit reports function Get-AccessReviewAuditReport { param( [DateTime]$StartDate = (Get-Date).AddMonths(-3), [DateTime]$EndDate = (Get-Date) ) $auditFile = "AccessReviewAuditTrail.json" if (-not (Test-Path $auditFile)) { Write-Warning "No audit trail file found" return @() } $auditEntries = Get-Content $auditFile | ConvertFrom-Json | Where-Object {[DateTime]$_.Timestamp -ge $StartDate -and [DateTime]$_.Timestamp -le $EndDate} $auditReport = $auditEntries | Group-Object Action | ForEach-Object { [PSCustomObject]@{ Action = $_.Name Count = $_.Count LastPerformed = ($_.Group | Sort-Object Timestamp -Descending | Select-Object -First 1).Timestamp } } return $auditReport } ```

**Best Practices:** 1. Implement automated actions carefully with proper testing 2. Provide clear appeals processes with defined timelines 3. Maintain comprehensive audit trails for all actions 4. Monitor response implementation rates and quality 5. Document all decision criteria and response procedures 6. Provide training for appeals reviewers 7. Regular testing of response automation 8. Ensure proper notifications to affected users

Explanation

Privileged Identity Management (PIM) for Entra roles provides just-in-time privileged access management for directory roles like Global Admin, Security Admin, and User Admin. PIM requires users to activate their privileged roles when needed, with approval workflows, time limits, and audit trails. This reduces security risks by ensuring privileged access is temporary and monitored.

Think of it as: PIM is a time-locked safe for admin credentials — being eligible to open it is NOT the same as having it open. You must activate it (with key + justification), and it auto-locks after your time expires.

Key Mechanics: - Eligible ≠ Active: User with eligible assignment CANNOT use the role until they activate it - Activation requires: MFA + business justification + optional approval (depends on role settings) - Activation is temporary: Auto-expires after configured duration (typically 1-8 hours) - Expired activation: Role access revoked, user must re-activate if still needed - Failure condition: Assuming 'eligible = active' leads to thinking you have access when you don't

Examples

Example 1 — [Success] PIM activation with time limit A user is assigned as 'eligible' Global Admin in PIM. At 9am, they navigate to Entra → PIM → Activate → select Global Admin role → enter justification → pass MFA → activation granted for 4 hours. At 1pm, activation auto-expires. If they need access again at 2pm, they must re-activate.

Example 2 — [Blocked] Assumption: Eligible = Active access A support team member is assigned as eligible User Admin in PIM. They assume they can manage users immediately because they're 'assigned.' They attempt to create users but get "Insufficient permissions" error. Root cause: Eligible assignment is NOT active access — activation is required. They skip the activation step and cannot perform admin tasks.

Key Mechanisms

- Core function: Privileged Identity Management (PIM) for Entra roles provides just-in-time privileged access management for directory roles like Global Admin, Security Admin, and User Admin. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] PIM activation with time limit - Decision clue: Organizations use PIM for Entra roles to implement zero standing access for privileged operations, meet compliance requirements, and reduce attack surface.

Review Path

**How to do it in Entra/Azure:**

**Enable and Configure PIM for Entra Roles:**

1. **Access PIM Console:** - Azure Portal → Entra ID → Privileged Identity Management → Entra ID roles

2. **Configure Role Settings:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory", "PrivilegedAccess.ReadWrite.AzureAD"

# Get role definitions $roles = Get-MgDirectoryRoleTemplate $globalAdminRole = $roles | Where-Object {$_.DisplayName -eq "Global Administrator"}

# Configure PIM settings for Global Admin role $pimSettings = @{ "@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicy" scopeId = "/" scopeType = "Directory" roleDefinitionId = $globalAdminRole.Id rules = @( @{ "@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicyActivationRule" id = "Activation_Admin_Require" target = @{ caller = "Admin" operations = @("All") level = "Activation" } enabledRules = @( "Justification", "MultiFactorAuthentication", "Ticketing" ) maximumDuration = "PT8H" # 8 hours }, @{ "@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicyApprovalRule" id = "Approval_Admin_Require" target = @{ caller = "Admin" operations = @("All") level = "Approval" } setting = @{ isApprovalRequired = $true isApprovalRequiredForExtension = $true approvalStages = @( @{ approvalStageTimeOutInDays = 1 isApproverJustificationRequired = $true primaryApprovers = @( @{ "@odata.type" = "#microsoft.graph.singleUser" userId = "ciso-user-id" } ) } ) } } ) }

# Apply PIM policy (Note: Actual API structure may vary) Write-Host "PIM settings configured for Global Administrator role" ```

**Assign Eligible Roles:** ```powershell # Make user eligible for privileged role $assignmentParams = @{ "@odata.type" = "#microsoft.graph.unifiedRoleEligibilityScheduleRequest" action = "AdminAssign" principalId = "user-object-id" roleDefinitionId = $globalAdminRole.Id directoryScopeId = "/" scheduleInfo = @{ startDateTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ") expiration = @{ type = "NoExpiration" } } justification = "Eligible assignment for privileged operations" }

# Create eligible assignment New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $assignmentParams Write-Host "User made eligible for Global Administrator role"

# View eligible assignments $eligibleAssignments = Get-MgRoleManagementDirectoryRoleEligibilitySchedule -Filter "roleDefinitionId eq '$($globalAdminRole.Id)'" foreach ($assignment in $eligibleAssignments) { $user = Get-MgUser -UserId $assignment.PrincipalId Write-Host "Eligible User: $($user.DisplayName) - Role: $($assignment.RoleDefinition.DisplayName)" } ```

**Monitor Role Activations:** ```powershell # Monitor PIM role activations function Get-PIMActivationReport { param( [DateTime]$StartDate = (Get-Date).AddDays(-30), [DateTime]$EndDate = (Get-Date) ) # Get role activation history $activations = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Activate role' and activityDateTime ge $($StartDate.ToString('yyyy-MM-ddTHH:mm:ssZ')) and activityDateTime le $($EndDate.ToString('yyyy-MM-ddTHH:mm:ssZ'))" $activationReport = @() foreach ($activation in $activations) { $details = $activation.TargetResources[0] $user = $activation.InitiatedBy.User $activationReport += [PSCustomObject]@{ ActivationDate = $activation.ActivityDateTime UserName = $user.DisplayName UserPrincipalName = $user.UserPrincipalName RoleName = $details.DisplayName Duration = $activation.AdditionalDetails | Where-Object {$_.Key -eq "RequestedDuration"} | Select-Object -ExpandProperty Value Justification = $activation.AdditionalDetails | Where-Object {$_.Key -eq "Justification"} | Select-Object -ExpandProperty Value ApprovalStatus = $activation.Result InitiatedFrom = $activation.InitiatedBy.User.IpAddress } } return $activationReport }

$activationReport = Get-PIMActivationReport $activationReport | Export-Csv -Path "PIMActivationReport.csv" -NoTypeInformation $activationReport | Format-Table -AutoSize ```

**Best Practices:** 1. Enable PIM for all privileged roles 2. Set appropriate activation time limits (4-8 hours typically) 3. Require business justification for all activations 4. Implement approval workflows for high-risk roles 5. Regularly review eligible assignments 6. Monitor activation patterns for anomalies 7. Use break-glass accounts for emergency access 8. Integrate with SIEM for security monitoring

Explanation

Break glass accounts are emergency access accounts designed to provide administrative access when normal authentication methods fail or regular administrative accounts are unavailable. These accounts bypass typical security controls like MFA and conditional access policies, making them critical for emergency situations but also high-risk if compromised. They require special protection and monitoring.

Think of it as: Break glass is a fire alarm for your tenant — you break the glass (use the account) only in emergencies, and once used, everyone knows it happened. But if Conditional Access policies apply to it, the alarm lever might be locked, defeating its purpose.

Key Mechanics: - Break glass accounts MUST NOT have MFA or Conditional Access policies applied - If Conditional Access blocks break glass, emergency access becomes impossible - Must be excluded from all CA policies (block policies especially) - Requires shared secure storage (not email, not cloud notes) - Restricted to 2-4 accounts maximum (one per trusted person typically) - Failure condition: CA policy mistakenly applies to break glass → locked out during emergency

Examples

Example 1 — [Success] Break glass properly excluded from CA Admin creates break glass accounts emergency01 and emergency02. They explicitly exclude both from ALL Conditional Access policies in the 'Exclude users' section. During MFA outage, emergency01 can sign in because CA policies don't apply. Emergency operations proceed normally.

Example 2 — [Blocked] CA policy accidentally includes break glass Admin creates break glass accounts but doesn't add them to any exclusion lists. A CA policy 'Block from high-risk locations' is deployed org-wide. During a security incident, CISO tries to sign in with break glass from incident response facility (different network) but gets blocked by CA. Emergency access is blocked. Root cause: Break glass accounts must be EXPLICITLY excluded from all CA policies.

Key Mechanisms

- Core function: Break glass accounts are emergency access accounts designed to provide administrative access when normal authentication methods fail or regular administrative accounts are unavailable. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Break glass properly excluded from CA - Decision clue: Organizations use break glass accounts to maintain access during emergency situations, system outages, or when security controls prevent normal administrative access.

Review Path

**How to do it in Entra/Azure:**

**Create Break Glass Accounts:**

1. **Create Emergency Admin Accounts:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"

# Create break glass account 1 $breakGlass1Params = @{ displayName = "Emergency Admin 01" userPrincipalName = "emergencyadmin01@yourdomain.com" mailNickname = "emergencyadmin01" accountEnabled = $true passwordProfile = @{ password = "ComplexPassword123!" forceChangePasswordNextSignIn = $false } usageLocation = "US" } $breakGlass1 = New-MgUser -BodyParameter $breakGlass1Params Write-Host "Created break glass account 1: $($breakGlass1.UserPrincipalName)"

# Create break glass account 2 $breakGlass2Params = @{ displayName = "Emergency Admin 02" userPrincipalName = "emergencyadmin02@yourdomain.com" mailNickname = "emergencyadmin02" accountEnabled = $true passwordProfile = @{ password = "AnotherComplexPassword456!" forceChangePasswordNextSignIn = $false } usageLocation = "US" } $breakGlass2 = New-MgUser -BodyParameter $breakGlass2Params Write-Host "Created break glass account 2: $($breakGlass2.UserPrincipalName)" ```

2. **Assign Global Admin Role:** ```powershell # Get Global Administrator role $globalAdminRole = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'" # Assign Global Admin role to break glass accounts $roleAssignment1 = @{ "@odata.id" = "https://graph.microsoft.com/v1.0/users/$($breakGlass1.Id)" } New-MgDirectoryRoleMemberByRef -DirectoryRoleId $globalAdminRole.Id -BodyParameter $roleAssignment1 $roleAssignment2 = @{ "@odata.id" = "https://graph.microsoft.com/v1.0/users/$($breakGlass2.Id)" } New-MgDirectoryRoleMemberByRef -DirectoryRoleId $globalAdminRole.Id -BodyParameter $roleAssignment2 Write-Host "Assigned Global Administrator role to break glass accounts" ```

**Configure Break Glass Account Protection:** ```powershell # Configure account properties for break glass function Set-BreakGlassAccountProperties { param([string]$UserId) # Disable password expiration Update-MgUser -UserId $UserId -PasswordPolicies "DisablePasswordExpiration" # Set custom attributes for identification $customAttributes = @{ extensionAttribute1 = "BreakGlass" extensionAttribute2 = "Emergency-Admin" extensionAttribute3 = (Get-Date).ToString("yyyy-MM-dd") } Update-MgUser -UserId $UserId -OnPremisesExtensionAttributes $customAttributes Write-Host "Configured break glass properties for user: $UserId" }

Set-BreakGlassAccountProperties -UserId $breakGlass1.Id Set-BreakGlassAccountProperties -UserId $breakGlass2.Id

# Create conditional access exclusion for break glass accounts $caPolicy = @{ displayName = "Break Glass Account Exclusion" state = "enabled" conditions = @{ users = @{ includeUsers = @("All") excludeUsers = @($breakGlass1.Id, $breakGlass2.Id) } applications = @{ includeApplications = @("All") } } grantControls = @{ operator = "AND" builtInControls = @("mfa") } }

# Note: Create the policy through Azure portal for break glass exclusions Write-Host "Remember to exclude break glass accounts from all conditional access policies" ```

**Monitor Break Glass Account Usage:** ```powershell # Monitor break glass account activity function Get-BreakGlassUsageReport { param( [DateTime]$StartDate = (Get-Date).AddDays(-90), [DateTime]$EndDate = (Get-Date) ) # Get break glass accounts $breakGlassAccounts = Get-MgUser -Filter "startswith(displayName, 'Emergency Admin')" -Select "id,displayName,userPrincipalName" $usageReport = @() foreach ($account in $breakGlassAccounts) { # Get sign-in logs $signIns = Get-MgAuditLogSignIn -Filter "userId eq '$($account.Id)' and createdDateTime ge $($StartDate.ToString('yyyy-MM-ddTHH:mm:ssZ')) and createdDateTime le $($EndDate.ToString('yyyy-MM-ddTHH:mm:ssZ'))" foreach ($signIn in $signIns) { $usageReport += [PSCustomObject]@{ AccountName = $account.DisplayName SignInTime = $signIn.CreatedDateTime Location = $signIn.Location.City + ", " + $signIn.Location.CountryOrRegion IPAddress = $signIn.IpAddress ClientApp = $signIn.ClientAppUsed Status = $signIn.Status.ErrorCode RiskLevel = $signIn.RiskLevelDuringSignIn DeviceInfo = $signIn.DeviceDetail.DisplayName IsInteractive = $signIn.IsInteractive } } # Check for directory activities $directoryActivities = Get-MgAuditLogDirectoryAudit -Filter "initiatedBy/user/id eq '$($account.Id)' and activityDateTime ge $($StartDate.ToString('yyyy-MM-ddTHH:mm:ssZ'))" -Top 50 foreach ($activity in $directoryActivities) { $usageReport += [PSCustomObject]@{ AccountName = $account.DisplayName ActivityTime = $activity.ActivityDateTime Activity = $activity.ActivityDisplayName Category = $activity.Category Result = $activity.Result TargetResources = ($activity.TargetResources | ForEach-Object {$_.DisplayName}) -join ", " } } } return $usageReport | Sort-Object SignInTime, ActivityTime -Descending }

$breakGlassUsage = Get-BreakGlassUsageReport if ($breakGlassUsage.Count -gt 0) { Write-Warning "Break glass account usage detected! Review immediately." $breakGlassUsage | Export-Csv -Path "BreakGlassUsageAlert_$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation } else { Write-Host "No break glass account usage detected in the specified period." } ```

**Best Practices:** 1. Create at least 2 break glass accounts for redundancy 2. Use strong, unique passwords stored securely offline 3. Exclude from all conditional access policies 4. Disable password expiration 5. Monitor usage with real-time alerts 6. Store credentials in a physical safe or secure vault 7. Test accounts quarterly to ensure they work 8. Document emergency procedures clearly 9. Rotate passwords after any usage 10. Assign Global Admin role directly (not via PIM)

Explanation

Identity Secure Score is a Microsoft security measurement that provides a numerical score representing your organization's identity security posture. It analyzes your current configuration against Microsoft's security best practices and provides actionable recommendations to improve security. The score ranges from 0-100% and is updated regularly based on your security configurations and improvements.

Think of it as: Secure Score is a moving target — as security threats evolve, Microsoft adds new recommendations, and if you don't implement them, your score can drop even if you didn't change anything.

Key Mechanics: - Score updates when Microsoft adds NEW recommendations to best practices - Not implementing new recommendations = score decreases (static config, higher standards) - Score can go DOWN with zero admin changes (Microsoft raises the bar) - Each recommendation worth different points (impact varies) - Failure condition: Assuming stable score means stable security; new threats require new mitigations

Examples

Example 1 — [Success] Score maintained through continuous updates Organization has 78/100 Secure Score. Microsoft adds new recommendation: 'Disable legacy TLS 1.0 usage' (+5 pts for completion). Admin implements immediately. Score stays at ~78-83. No surprise drop despite new requirements because admin stays proactive.

Example 2 — [Blocked] Score drops due to new recommendations Organization maintains 78/100 Secure Score for 6 months without changes. Microsoft adds new vulnerability class: 'Enforce passwordless sign-in for all users' (worth +8 pts if completed). Organization ignores it. Score automatically drops to ~70/100. Admin is shocked: "We didn't change anything, how did the score drop?" Root cause: Microsoft raised security standards with new recommendation; not implementing new recommendations drops your score.

Key Mechanisms

- Core function: Identity Secure Score is a Microsoft security measurement that provides a numerical score representing your organization's identity security posture. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Score maintained through continuous updates - Decision clue: Organizations use Identity Secure Score to measure security posture, track improvement over time, benchmark against industry standards, and prioritize security investments.

Review Path

**How to do it in Entra/Azure:**

**Access Identity Secure Score:**

1. **Navigate to Secure Score:** - Azure Portal → Entra ID → Security → Identity Secure Score - Microsoft 365 Security Center → Secure Score → Identity Score

2. **Get Secure Score via PowerShell:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "SecurityEvents.Read.All", "Directory.Read.All"

# Get Identity Secure Score function Get-IdentitySecureScore { try { # Get current secure score $secureScores = Get-MgSecuritySecureScore -Top 1 | Sort-Object CreatedDateTime -Descending $currentScore = $secureScores[0] # Get score control profiles for recommendations $controlProfiles = Get-MgSecuritySecureScoreControlProfile -All # Calculate score breakdown $scoreBreakdown = @{ CurrentScore = $currentScore.CurrentScore MaxScore = $currentScore.MaxScore Percentage = [math]::Round(($currentScore.CurrentScore / $currentScore.MaxScore) * 100, 2) LastUpdated = $currentScore.CreatedDateTime ActiveControls = ($controlProfiles | Where-Object {$_.ControlStateUpdates.Count -eq 0}).Count CompletedControls = ($controlProfiles | Where-Object {$_.ControlStateUpdates.State -eq "Completed"}).Count IgnoredControls = ($controlProfiles | Where-Object {$_.ControlStateUpdates.State -eq "Ignored"}).Count } return $scoreBreakdown } catch { Write-Error "Failed to retrieve Identity Secure Score: $($_.Exception.Message)" return $null } } $secureScore = Get-IdentitySecureScore if ($secureScore) { Write-Host "Identity Secure Score: $($secureScore.CurrentScore)/$($secureScore.MaxScore) ($($secureScore.Percentage)%)" $secureScore | ConvertTo-Json } ```

**Analyze Score Recommendations:** ```powershell # Get detailed recommendations and their impact function Get-SecureScoreRecommendations { $controlProfiles = Get-MgSecuritySecureScoreControlProfile -All $recommendations = @() foreach ($control in $controlProfiles) { # Skip completed or ignored controls $state = if ($control.ControlStateUpdates.Count -gt 0) { $control.ControlStateUpdates[-1].State } else { "Default" } if ($state -notin @("Completed", "Ignored")) { $recommendations += [PSCustomObject]@{ ControlName = $control.Title Category = $control.ControlCategory MaxScore = $control.MaxScore CurrentScore = $control.Score PotentialGain = $control.MaxScore - $control.Score Implementation = $control.Implementation UserImpact = $control.UserImpact ImplementationCost = $control.ImplementationCost Rank = $control.Rank ActionType = $control.ActionType State = $state } } } return $recommendations | Sort-Object PotentialGain -Descending }

$recommendations = Get-SecureScoreRecommendations $recommendations | Export-Csv -Path "SecureScoreRecommendations.csv" -NoTypeInformation

# Show top 10 recommendations Write-Host "Top 10 Identity Security Recommendations:" $recommendations | Select-Object -First 10 | Format-Table ControlName, PotentialGain, UserImpact, ImplementationCost -AutoSize ```

**Track Score History:** ```powershell # Get secure score history and trends function Get-SecureScoreHistory { param( [int]$DaysBack = 90 ) $startDate = (Get-Date).AddDays(-$DaysBack) $secureScores = Get-MgSecuritySecureScore -Filter "createdDateTime ge $($startDate.ToString('yyyy-MM-ddTHH:mm:ssZ'))" | Sort-Object CreatedDateTime $history = @() foreach ($score in $secureScores) { $history += [PSCustomObject]@{ Date = $score.CreatedDateTime CurrentScore = $score.CurrentScore MaxScore = $score.MaxScore Percentage = [math]::Round(($score.CurrentScore / $score.MaxScore) * 100, 2) ActiveUserCount = $score.ActiveUserCount EnabledServices = $score.EnabledServices.Count } } return $history }

$scoreHistory = Get-SecureScoreHistory -DaysBack 30 if ($scoreHistory.Count -gt 1) { $latestScore = $scoreHistory[-1].Percentage $previousScore = $scoreHistory[0].Percentage $improvement = $latestScore - $previousScore Write-Host "Score Trend (30 days): $improvement% change" if ($improvement -gt 0) { Write-Host "✅ Security posture is improving!" -ForegroundColor Green } elseif ($improvement -eq 0) { Write-Host "⚡ Security posture is stable" -ForegroundColor Yellow } else { Write-Host "⚠️ Security posture is declining" -ForegroundColor Red } }

$scoreHistory | Export-Csv -Path "SecureScoreHistory.csv" -NoTypeInformation ```

**Create Security Dashboard:** ```powershell # Generate comprehensive security dashboard function New-IdentitySecurityDashboard { $dashboard = @{ GeneratedDate = Get-Date SecureScore = Get-IdentitySecureScore TopRecommendations = Get-SecureScoreRecommendations | Select-Object -First 5 ScoreTrend = Get-SecureScoreHistory -DaysBack 30 SecurityMetrics = @{} ComplianceStatus = @{} ActionItems = @() } # Add security metrics try { $users = Get-MgUser -All -Select "id,userPrincipalName,accountEnabled" $mfaUsers = Get-MgUser -All -Select "id" | Where-Object { $mfaStatus = Get-MgUserAuthenticationMethod -UserId $_.Id -ErrorAction SilentlyContinue $mfaStatus.Count -gt 1 # More than just password } $dashboard.SecurityMetrics = @{ TotalUsers = $users.Count ActiveUsers = ($users | Where-Object {$_.AccountEnabled}).Count MFAEnabledUsers = $mfaUsers.Count MFACoverage = [math]::Round(($mfaUsers.Count / $users.Count) * 100, 2) } } catch { Write-Warning "Could not gather all security metrics: $($_.Exception.Message)" } # Determine compliance status $currentScore = $dashboard.SecureScore.Percentage $dashboard.ComplianceStatus = @{ Level = if ($currentScore -ge 80) { "High" } elseif ($currentScore -ge 60) { "Medium" } else { "Low" } MeetsBaseline = $currentScore -ge 60 IndustryComparison = if ($currentScore -ge 70) { "Above Average" } elseif ($currentScore -ge 50) { "Average" } else { "Below Average" } } # Generate action items $dashboard.ActionItems = @( if ($dashboard.SecurityMetrics.MFACoverage -lt 95) { "🔐 Increase MFA coverage to 95%+ (currently $($dashboard.SecurityMetrics.MFACoverage)%)" } if ($currentScore -lt 70) { "📈 Implement top 3 secure score recommendations to reach 70% baseline" } "📊 Review and act on highest-impact security recommendations" "🔍 Schedule monthly security posture review meetings" ) return $dashboard }

$securityDashboard = New-IdentitySecurityDashboard $securityDashboard | ConvertTo-Json -Depth 4 | Out-File "IdentitySecurityDashboard_$(Get-Date -Format 'yyyy-MM-dd').json"

# Display summary Write-Host " 🛡️ IDENTITY SECURITY DASHBOARD" Write-Host "=====================================" Write-Host "Current Score: $($securityDashboard.SecureScore.CurrentScore)/$($securityDashboard.SecureScore.MaxScore) ($($securityDashboard.SecureScore.Percentage)%)" Write-Host "Compliance Level: $($securityDashboard.ComplianceStatus.Level)" Write-Host "MFA Coverage: $($securityDashboard.SecurityMetrics.MFACoverage)%" Write-Host " Action Items:" $securityDashboard.ActionItems | ForEach-Object { Write-Host " $_" } ```

**Best Practices:** 1. Review secure score monthly with security team 2. Prioritize high-impact, low-effort recommendations first 3. Set target score goals (baseline 60%, good 80%+) 4. Track score trends over time 5. Use score to justify security investments 6. Address recommendations systematically 7. Monitor score after implementing changes 8. Include score in security reporting to leadership

Explanation

Privileged Identity Management for Azure resources extends just-in-time access management to Azure subscription and resource-level roles like Owner, Contributor, and custom roles. Users must activate their Azure resource roles when needed, with configurable approval workflows, time limits, and audit trails. This ensures Azure resource access is temporary and monitored.

Examples

Example 1 — [Success] Dev activates role for temporary access Developer is eligible for 'Contributor' on production resource group. Needs to deploy. Activates role (MFA + justification), gets 4-hour access. Deploys. Role auto-expires at end of 4 hours. Access revoked. Next deployment requires new activation.

Example 2 — [Blocked] Standing access to production leads to incidents Developer has permanent Contributor role on production (no PIM). Gets phished. Attacker uses developer's account, deletes 10 VMs. Damage is huge because developer had standing access. Root cause: No PIM—access wasn't temporary; attack impact was permanent.

Key Mechanisms

- Core function: Privileged Identity Management for Azure resources extends just-in-time access management to Azure subscription and resource-level roles like Owner, Contributor, and custom roles. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Dev activates role for temporary access - Decision clue: Organizations use PIM for Azure resources to prevent standing access to production resources, implement just-in-time administration, and maintain audit trails for resource-level operations.

Review Path

**How to do it in Entra/Azure:**

**Enable PIM for Azure Resources:**

1. **Discover Azure Resources:** - Azure Portal → Privileged Identity Management → Azure resources → Discover resources

2. **Configure PIM for Subscriptions:** ```powershell # Connect to Azure Connect-AzAccount Import-Module Az.Resources

# Enable PIM for subscription $subscriptionId = "your-subscription-id" $scope = "/subscriptions/$subscriptionId"

# Configure role settings for Contributor role $contributorRoleId = "b24988ac-6180-42a0-ab88-20f7382dd24c" # Contributor role ID # Get current PIM settings (Note: Actual cmdlets may vary) Write-Host "Configuring PIM for Azure subscription: $subscriptionId" ```

**Best Practices:** 1. Enable PIM for all production subscriptions 2. Require approval for Owner and Contributor roles 3. Set maximum activation duration to 8 hours 4. Monitor activation patterns for anomalies 5. Use resource-specific role assignments when possible 6. Implement just-in-time VM access alongside PIM 7. Regular review of eligible assignments 8. Integrate with SIEM for monitoring

Explanation

Privileged Identity Management for Groups enables just-in-time membership and ownership of security groups and Microsoft 365 groups. Users can activate their group membership when needed, with approval workflows and time limits. This is particularly useful for groups that provide access to sensitive resources or applications.

Examples

Activating membership in a security group that grants access to confidential financial data, becoming an owner of a Microsoft 365 group for project management, or joining a group that has application administrator permissions.

Key Mechanisms

- Core function: Privileged Identity Management for Groups enables just-in-time membership and ownership of security groups and Microsoft 365 groups. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Activating membership in a security group that grants access to confidential financial data, becoming an owner of a Microsoft 365 group for project management, or joining a group that has application administrator permissions. - Decision clue: Organizations use PIM for Groups to provide temporary access to group-based permissions, reduce standing group memberships, and maintain audit trails for group access changes.

Review Path

**How to do it in Entra/Azure:**

**Enable PIM for Groups:**

1. **Configure PIM-eligible Groups:** ```powershell # Connect to Microsoft Graph Connect-MgGraph -Scopes "Group.ReadWrite.All", "PrivilegedAccess.ReadWrite.AzureADGroup"

# Create role-assignable group for PIM $groupParams = @{ displayName = "PIM-Enabled Security Group" description = "Security group with PIM-enabled membership" groupTypes = @() securityEnabled = $true mailEnabled = $false isAssignableToRole = $true } $pimGroup = New-MgGroup -BodyParameter $groupParams Write-Host "Created PIM-enabled group: $($pimGroup.DisplayName)" ```

**Best Practices:** 1. Use PIM for groups with sensitive access 2. Set appropriate activation durations 3. Require justification for group access 4. Monitor group activation patterns 5. Regular review of group membership eligibility 6. Use role-assignable groups for administrative access

Explanation

PIM approval processes define workflows for reviewing and approving privilege activation requests. Administrators can configure single or multi-stage approval requirements, set approval timeouts, require justification from approvers, and designate specific users or roles as approvers. This ensures that privilege elevation is properly authorized.

Think of it as: Getting approval from your boss is NOT the same as being promoted forever — you get approval to work the weekend (temporary), then you go back to normal Monday.

Key Mechanics: - Approval grants temporary activation, NOT permanent privilege - After activation duration expires, privilege access ends (approval doesn't extend activation time) - To work longer, user must request again and get re-approved - Time limit still applies even after approval (e.g., approved for 4 hours) - Failure condition: Thinking approval = permanent privilege; activation still has auto-expiration

Examples

Example 1 — [Success] Approval + time limit respected User requests Global Admin role activation for 4 hours with justification. CISO approves. User activates at 2pm for 4 hours. Activation expires at 6pm. User wants to continue working; they must request activation AGAIN (get re-approved if required, or auto-approved if settings allow). Temporary access respected.

Example 2 — [Blocked] Assuming approval removes time limit User requests Global Admin role with approval required + 8-hour activation max. Manager approves. User expects 'approval means permanent access.' At 8:01 hours, their access still auto-expires. User blames PIM for not respecting the approval. Root cause: Approval grants permission to activate, not permanent privilege — time limit still applies regardless of approval.

Key Mechanisms

- Core function: PIM approval processes define workflows for reviewing and approving privilege activation requests. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Approval + time limit respected - Decision clue: Organizations use PIM approval processes to implement segregation of duties, ensure proper authorization for sensitive operations, and maintain accountability for privilege escalation.

Review Path

**How to do it in Entra/Azure:**

**Configure Approval Workflows:**

1. **Set Up Role Approval Settings:** - Azure Portal → PIM → Entra ID roles → Settings → Edit role settings

2. **Configure Multi-stage Approval:** ```powershell # Configure approval settings for Global Admin role $approvalSettings = @{ isApprovalRequired = $true isApprovalRequiredForExtension = $true approvalStages = @( @{ approvalStageTimeOutInDays = 1 isApproverJustificationRequired = $true primaryApprovers = @( @{ "@odata.type" = "#microsoft.graph.singleUser" userId = "manager-user-id" } ) }, @{ approvalStageTimeOutInDays = 1 isApproverJustificationRequired = $true primaryApprovers = @( @{ "@odata.type" = "#microsoft.graph.singleUser" userId = "ciso-user-id" } ) } ) } Write-Host "Multi-stage approval configured for Global Admin role" ```

**Best Practices:** 1. Use multi-stage approval for high-risk roles 2. Set reasonable approval timeouts (1-2 days) 3. Require justification from approvers 4. Configure backup approvers for coverage 5. Monitor approval response times 6. Regular review of approval workflows

Explanation

PIM audit reports provide comprehensive tracking of privileged access activities including role activations, assignment changes, approval decisions, and administrative actions. These reports support compliance requirements, security investigations, and operational oversight of privileged access management.

Examples

Example 1 — [Success] Audit reports catch unauthorized activation Audit report shows user X activated Global Admin at 3am with IP from Russia. Administrator reviews, finds unusual pattern. Immediate investigation reveals compromised account. Account reset, incident contained. Audit trail enabled quick response.

Example 2 — [Blocked] No audit means no visibility PIM activated, but nobody reviews audit logs. Attacker compromises Global Admin account, activates role, performs damage. Days later, audit finds activities but no one was monitoring. Damage already done. Root cause: No one reviewing PIM audit reports.

Key Mechanisms

- Core function: PIM audit reports provide comprehensive tracking of privileged access activities including role activations, assignment changes, approval decisions, and administrative actions. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Audit reports catch unauthorized activation - Decision clue: Organizations use PIM audit reports to demonstrate compliance, investigate security incidents, monitor privileged access usage, and optimize PIM policies based on usage patterns.

Review Path

**How to do it in Entra/Azure:**

**Generate PIM Audit Reports:**

1. **Access PIM Audit Logs:** - Azure Portal → PIM → Entra ID roles → Activity → Audit history

2. **Export Activation Reports:** ```powershell # Generate comprehensive PIM audit report function Get-PIMActivationReport { param( [DateTime]$StartDate = (Get-Date).AddDays(-30), [DateTime]$EndDate = (Get-Date) ) # Get PIM activation audit logs $pimActivations = Get-MgAuditLogDirectoryAudit -Filter "category eq 'RoleManagement' and activityDisplayName eq 'Add member to role completed (PIM activation)' and activityDateTime ge $($StartDate.ToString('yyyy-MM-ddTHH:mm:ssZ'))" $activationReport = @() foreach ($activation in $pimActivations) { $activationReport += [PSCustomObject]@{ ActivationDate = $activation.ActivityDateTime UserName = $activation.InitiatedBy.User.DisplayName UserPrincipalName = $activation.InitiatedBy.User.UserPrincipalName RoleName = $activation.TargetResources[0].DisplayName ResourceScope = $activation.TargetResources[0].Id CorrelationId = $activation.CorrelationId ResultReason = $activation.ResultReason IPAddress = $activation.InitiatedBy.User.IpAddress } } return $activationReport } $activationReport = Get-PIMActivationReport $activationReport | Export-Csv -Path "PIMActivationReport_$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation ```

**Best Practices:** 1. Generate monthly PIM audit reports 2. Monitor for unusual activation patterns 3. Integrate with SIEM for real-time monitoring 4. Maintain audit logs for compliance periods 5. Regular review of PIM configuration changes 6. Archive reports for long-term compliance

Explanation

Diagnostic settings in Entra ID control the collection and routing of audit logs, sign-in logs, and other monitoring data to various destinations like Log Analytics workspaces, Storage Accounts, or Event Hubs. This enables centralized logging, long-term retention, and integration with SIEM systems for security monitoring and compliance.

Think of it as: Diagnostic settings are your security camera recorder — they capture events and send them to storage, but there's a delay in getting the recorded footage from camera to storage (up to 5 minutes).

Key Mechanics: - Log Analytics ingestion: Up to 5-minute delay before logs appear in queries - Event Hub: Near real-time (faster than Log Analytics) for immediate streaming to SIEM - Storage Account: Long-term archival with even longer retrieval times - Delay is NORMAL and expected: Not a configuration problem - Failure condition: Expecting real-time alerts from Log Analytics; delays cause missed immediate responses

Examples

Example 1 — [Success] Using Event Hub for real-time, Log Analytics for retention Admin configures diagnostic settings: high-risk sign-in logs → Event Hub (real-time SIEM alerts) AND → Log Analytics (historical queries for compliance). Incident happens at 9:00am. SIEM alerts at 9:00:02am (Event Hub near real-time). Log Analytics query shows the event at 9:03am. Alerting on critical events is fast, retention is long.

Example 2 — [Blocked] Expecting Log Analytics for real-time alerts Admin configures sign-in logs → Log Analytics only and sets up alert to trigger within 1 minute. Attacker brute-forces accounts at 9:00am. Alert doesn't fire until 9:04-9:05am due to Log Analytics ingestion delay. By then, attacker already gained access. Root cause: Log Analytics has 5-minute ingestion delay — not suitable for immediate alerting; Event Hub is needed for real-time SIEM integration.

Key Mechanisms

- Core function: Diagnostic settings in Entra ID control the collection and routing of audit logs, sign-in logs, and other monitoring data to various destinations like Log Analytics workspaces, Storage Accounts, or Event Hubs. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Using Event Hub for real-time, Log Analytics for retention - Decision clue: Organizations use diagnostic settings to centralize identity logs, meet compliance retention requirements, enable security monitoring, and integrate with existing logging infrastructure.

Review Path

**How to do it in Entra/Azure:**

**Configure Diagnostic Settings:**

1. **Navigate to Diagnostic Settings:** - Azure Portal → Entra ID → Monitoring → Diagnostic settings

2. **Create Diagnostic Setting:** ```powershell # Configure diagnostic settings via PowerShell Connect-AzAccount # Create Log Analytics workspace if needed $resourceGroup = "security-monitoring-rg" $workspaceName = "identity-logs-workspace" $location = "East US" $workspace = New-AzOperationalInsightsWorkspace -ResourceGroupName $resourceGroup -Name $workspaceName -Location $location # Configure diagnostic setting for Entra ID $diagnosticSettingParams = @{ Name = "EntraID-to-LogAnalytics" ResourceId = "/providers/Microsoft.AADIAM/diagnosticSettings" WorkspaceId = $workspace.ResourceId Enabled = $true Category = @( @{ Category = "SignInLogs" Enabled = $true RetentionPolicy = @{ Enabled = $true Days = 90 } }, @{ Category = "AuditLogs" Enabled = $true RetentionPolicy = @{ Enabled = $true Days = 365 } }, @{ Category = "RiskyUsers" Enabled = $true RetentionPolicy = @{ Enabled = $true Days = 180 } } ) } Write-Host "Diagnostic settings configured for Entra ID logs" ```

**Best Practices:** 1. Send logs to multiple destinations for redundancy 2. Configure appropriate retention periods for compliance 3. Enable all relevant log categories 4. Monitor diagnostic setting health 5. Use Log Analytics for advanced querying 6. Implement alerting on critical events 7. Regular review of log collection costs 8. Test log delivery and accessibility

Explanation

Azure Workbooks provide interactive reporting and visualization capabilities for Entra ID data, combining multiple data sources into rich visual reports. Workbooks enable custom dashboards for security monitoring, compliance reporting, and operational insights using KQL queries against Log Analytics data.

Examples

Example 1 — [Success] Workbook reveals anomaly pattern Security team uses custom workbook showing sign-in patterns. Dashboard highlights: user X usually signs in 9-5, but anomalies show sign-in at 3am, high-risk location, 100 API calls. Team immediately investigates, finds compromise. Quick response because visual pattern was obvious in workbook.

Example 2 — [Blocked] Raw logs without visualization missed incidents Logs exist but no workbooks. Raw CSV files exported monthly. Team manually reviews and misses patterns. Compromised account generates unusual activity for 2 weeks before anyone notices by accident. Root cause: No visual dashboard to highlight anomalies; relying on manual log review is error-prone.

Key Mechanisms

- Core function: Azure Workbooks provide interactive reporting and visualization capabilities for Entra ID data, combining multiple data sources into rich visual reports. - Category fit: This concept belongs to identity protection and monitoring and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Workbook reveals anomaly pattern - Decision clue: Organizations use workbooks for security monitoring dashboards, compliance reporting, executive briefings, and operational insights into identity systems.

Review Path

**How to do it in Entra/Azure:**

**Create Custom Workbooks:**

1. **Access Azure Workbooks:** - Azure Portal → Monitor → Workbooks → New

2. **Create Identity Security Workbook:** ```kql // Example KQL queries for identity workbook // Sign-in success rate by application SigninLogs | where TimeGenerated > ago(30d) | summarize TotalSignins = count(), SuccessfulSignins = countif(ResultType == 0) by AppDisplayName | extend SuccessRate = round((SuccessfulSignins * 100.0) / TotalSignins, 2) | order by TotalSignins desc | take 20 // Risk events by user SigninLogs | where TimeGenerated > ago(7d) and RiskLevelDuringSignIn != "" | summarize RiskEvents = count() by UserPrincipalName, RiskLevelDuringSignIn | order by RiskEvents desc // Geographic sign-in distribution SigninLogs | where TimeGenerated > ago(30d) and ResultType == 0 | summarize SigninCount = count() by Location | order by SigninCount desc | take 15 // Failed sign-ins by error code SigninLogs | where TimeGenerated > ago(7d) and ResultType != 0 | summarize FailureCount = count() by ResultType, ResultDescription | order by FailureCount desc ```

**Best Practices:** 1. Use template workbooks as starting points 2. Create role-based workbook access 3. Schedule automated report generation 4. Include interactive filters for date ranges 5. Combine multiple data sources effectively 6. Optimize queries for performance 7. Create executive summary views 8. Regular review and updates of dashboards