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 Azure AD 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 Azure AD 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 → Azure AD 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, Azure AD Premium, 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, Azure AD Premium, 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 "Azure AD 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 "Azure AD 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): - Azure AD 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 "Azure Active Directory" → 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-azure-active-directory

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. Azure AD registration adds personal devices (BYOD), Azure AD join connects corporate devices, and Hybrid Azure AD join 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: - Azure AD Registered: Personal devices with basic management (iOS, Android, Mac, Windows) - Azure AD Joined: Cloud-only corporate devices with full management - Hybrid Azure AD 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 Azure AD": 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. Azure AD 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. Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 and troubleshooting Conditional Access involves systematic validation of policy effectiveness, identifying issues with access decisions, and resolving authentication problems. This includes using Azure AD tools like the What If analyzer, sign-in logs analysis, and report-only mode to ensure policies work as intended without negatively impacting user experience.

Examples

Example 1: You create a What If test for a finance user from the corporate network accessing Excel. Conditional Access evaluates: Location = corporate (trusted) → Device = compliant → Result = Allow (no additional auth). User gains instant access. Example 2: Same user attempts access from an anonymous proxy IP. Policy evaluates: Location = anonymous IP → Risk signal triggered → Result = Block or require password + MFA. Exam trap: Report-only mode logs impact but DOES NOT ENFORCE policies—enable mode fully to enforce access decisions.

Key Mechanisms

- Core function: Testing and troubleshooting Conditional Access involves systematic validation of policy effectiveness, identifying issues with access decisions, and resolving authentication problems. - 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: You create a What If test for a finance user from the corporate network accessing Excel. - Decision clue: Ensuring security policies work correctly before full deployment, minimizing user disruption during policy changes, maintaining business continuity while implementing security controls, meeting compliance audit requirements, optimizing policy performance and user experience.

Review Path

**How to test and troubleshoot (Azure Portal + PowerShell):** 1. Navigate to Azure AD → Security → Conditional Access → What If 2. Select test user, cloud app, location, device state 3. Click "What If" → Review which policies apply and outcomes 4. For failures: Azure AD → Sign-in logs → Filter by error → Check Conditional Access tab 5. Analyze failure reason: policy blocked, MFA failed, device not compliant, etc. 6. Deploy new policies in "Report-only" first to monitor impact without enforcement 7. Review What If results for emergency access accounts—they must be EXCLUDED from all policies 8. Test from various locations/devices to validate policy logic

Explanation

User risk policies in Azure AD Identity Protection automatically respond to detected user account compromises by requiring users to change passwords or perform additional verification. These policies analyze user behavior patterns, leaked credentials, and other risk signals to identify when user accounts may be compromised and enforce appropriate remediation actions.

Examples

Example 1: Risk detection flags a user account because their credentials appeared in a leaked database. User risk policy is triggered: Risk level = high → Require password change → User completes password reset → Risk dismissed → Normal access restored. Example 2: Same user attempts to sign in before completing password change. Policy enforces: User risk = high → Access blocked until remediation → User is notified and completes password reset. Exam trap: User risk DIFFERS from sign-in risk. User risk is about account compromise; sign-in risk is about THIS login attempt being suspicious.

Key Mechanisms

- Core function: User risk policies in Azure AD Identity Protection automatically respond to detected user account compromises by requiring users to change passwords or perform additional verification. - 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: Risk detection flags a user account because their credentials appeared in a leaked database. - Decision clue: Protecting against credential theft and account takeovers, automating incident response for compromised accounts, reducing administrative overhead for security teams, maintaining user productivity while ensuring security, meeting compliance requirements for identity protection.

Review Path

**Configure user risk policy (Azure Portal):** 1. Azure AD → Security → Identity Protection → User risk policy 2. Assignments: Include all users, exclude emergency access accounts 3. Conditions: Select risk levels (High, Medium+High, or all levels) 4. Controls: Block access OR Allow + require password change OR Allow + require MFA 5. Enforce: Set to "On" (not "Report-only" for production) 6. Test in report-only first to understand impact 7. Monitor: Azure AD → Risky users → Review risk level and remediation status

Explanation

Sign-in risk policies in Azure AD Identity Protection evaluate each authentication attempt in real-time to detect potentially malicious sign-in activities. These policies analyze contextual information like location, device, IP address, and behavioral patterns to identify suspicious sign-ins and automatically enforce appropriate security controls like MFA or access blocking.

Examples

Example 1: User signs in from their usual location on their registered device. Sign-in risk policy evaluates: Location = trusted, Device = known, Time = business hours → Risk score = low → Allow access. User logs in normally. Example 2: Same user's credentials are attempted from an anonymous proxy in a different country at 3 AM. Sign-in risk policy evaluates: Location = anonymous IP (high risk), Device = unknown, Time = unusual → Risk score = high → Access blocked + notification sent. Exam trap: Sign-in risk is EVALUATED AT AUTH TIME, unlike user risk which is discovered afterward. Also, sign-in risk triggers on THIS login; if same user logs in differently later, risk reassesses independently.

Key Mechanisms

- Core function: Sign-in risk policies in Azure AD Identity Protection evaluate each authentication attempt in real-time to detect potentially malicious sign-in activities. - 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: User signs in from their usual location on their registered device. - Decision clue: Preventing account takeovers during the authentication process, reducing false positives compared to static location rules, enabling secure access from new devices and locations, automating real-time threat response, maintaining user productivity while enhancing security.

Review Path

**Configure sign-in risk policy (Azure Portal):** 1. Azure AD → Security → Identity Protection → Sign-in risk policy 2. Assignments: All users, exclude emergency access accounts 3. Conditions: Risk levels (High, Medium, Low) 4. Controls: Block access OR Allow + require MFA 5. Deploy in report-only to observe patterns first 6. Monitor: Azure AD → Sign-in logs → Filter by Conditional Access status 7. Analyze false positives: Trusted locations, devices, user feedback 8. Tune: Adjust risk thresholds based on organization tolerance

Explanation

MFA registration policies ensure users register for multi-factor authentication methods when they pose acceptable risk levels. These policies work in conjunction with user risk and sign-in risk policies to create a comprehensive security framework. The policy can require users to register for MFA during sign-in based on group membership and risk assessment.

Examples

Example 1: New user signs in for first time, triggers MFA registration policy. User is prompted: 'Register for multi-factor authentication now.' Completes registration → Sets up Microsoft Authenticator app → MFA enrollment confirmed → Can proceed with work. Example 2: User attempts to skip MFA registration when policy requires it. Policy enforcement: Registration mandatory → User cannot proceed without completing setup. User contacts IT, completes MFA registration → Full access restored. Exam trap: MFA registration policy is NOT the same as MFA requirement policy. Registration policy = 'you must SET UP MFA'; MFA requirement policy = 'you must USE MFA at login.' A user can be registered but not yet required to use it.

Key Mechanisms

- Core function: MFA registration policies ensure users register for multi-factor authentication methods when they pose acceptable risk levels. - 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: New user signs in for first time, triggers MFA registration policy. - Decision clue: Organizations use MFA registration policies to ensure comprehensive MFA coverage across all users while maintaining user experience.

Review Path

**Configure MFA registration (Azure Portal):** 1. Azure AD → Security → Authentication methods → Registration campaign 2. Enable: 'Microsoft Authenticator registration campaign' 3. Snooze duration: Set grace period before enforcement 4. Target users: All users or specific groups 5. Exclude: Emergency access accounts MUST be excluded 6. Deploy and monitor: Enrollment completion % over time 7. Follow-up: Send notifications for non-registered users 8. Audit: Reports → Authentication method registrations

Explanation

Risk investigation and remediation in Microsoft Entra ID Protection involves analyzing risk detections, investigating suspicious activities, and taking appropriate remediation actions. This includes reviewing sign-in logs, analyzing risk events, correlating threat intelligence, and implementing automated or manual remediation responses to protect user accounts and organizational resources.

Examples

Example 1: System detects impossible travel risk (user in New York at 10 AM, then London at 11 AM). You investigate: Check sign-in logs → Confirm 2nd login is from VPN → Determine legitimate business travel → Dismiss risk as false positive → Update location baseline. Example 2 — Confirmed Compromise: Leaked credentials detected for user@domain.com. Investigation reveals: Password found in dark web dump, no legitimate explanation → Confirm compromise → Force password reset → Revoke refresh tokens → Block user until reset complete → User resets password → Verify no suspicious file access during compromise window. Exam trap: Risk dismissal means 'this was NOT a real threat.' Risk confirmation means 'this WAS a real threat and the user is compromised.' Confirm only when you have evidence; dismiss when you prove it's false positive.

Key Mechanisms

- Core function: Risk investigation and remediation in Microsoft Entra ID Protection involves analyzing risk detections, investigating suspicious activities, and taking appropriate remediation 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: System detects impossible travel risk (user in New York at 10 AM, then London at 11 AM). - Decision clue: Security teams use risk investigation to understand attack patterns, validate threat intelligence, reduce false positives, and implement appropriate security responses.

Review Path

**Investigate and remediate risks (Azure Portal + PowerShell):** 1. Navigate to Azure AD → Security → Identity Protection → Risky users OR Risk detections 2. Review high-risk detections first 3. For each risk: - Click to view details (user, time, location, type) - Check user's sign-in log for context - Search for file access, email forwarding changes - Interview user if needed (legitimate travel? device theft?) 4. Decision point: - If legitimate: Click 'Dismiss risk' - If compromised: Click 'Confirm user as compromised' 5. After confirmation: - Force password reset (Set-AzureADUserPassword or portal) - Revoke refresh tokens (Invoke-MgInvalidateUserRefreshToken) - Review and revoke suspicious app consents - Reset high-impact application passwords 6. Document the investigation for compliance audit trail 7. Adjust conditional access or sign-in risk policies if pattern detected

Explanation

Azure role assignments are the mechanism used to grant permissions to users, groups, service principals, and managed identities to access Azure resources. Role assignments consist of three components: security principal (who), role definition (what permissions), and scope (where). Azure provides built-in roles like Owner, Contributor, Reader, and supports custom roles for specific needs.

Examples

Example 1: You need to grant a developer team access to a resource group for VM management. Create role assignment: Principal = 'Developers' group, Role = 'Virtual Machine Contributor', Scope = '/subscriptions/sub-id/resourceGroups/dev-rg'. Team can now create/manage VMs in that RG only. Example 2: A developer attempts to delete the resource group (RG deletion requires higher Contributor role at RG or subscription level). Their Virtual Machine Contributor role ONLY includes VM-specific actions, NOT resource group deletion. Access denied. Exam trap: Role assignment scope is INHERITED DOWNWARD. A subscription-level assignment applies to all RGs below it. But RG-level assignment does NOT apply to subscription scope. Scope inheritance is one-way: down the hierarchy.

Key Mechanisms

- Core function: Azure role assignments are the mechanism used to grant permissions to users, groups, service principals, and managed identities to access 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: You need to grant a developer team access to a resource group for VM management. - Decision clue: Organizations use role assignments to implement least privilege access, ensure separation of duties, maintain compliance requirements, and automate access management through Infrastructure as Code.

Review Path

**Create role assignments (Azure Portal):** 1. Navigate to resource/RG/subscription → Access Control (IAM) 2. Click 'Add role assignment' 3. Select Role (e.g., Contributor, Reader, custom role) 4. Assign access to: User, Group, Service Principal, or Managed Identity 5. Select member(s) by name or email 6. Review + assign 7. Verify in 'Role assignments' tab

**Check what someone can do:** Azure IAM → Access Control → Select a user → View assignments → Shows all roles and scopes.

Explanation

Custom Azure roles allow organizations to create tailored role definitions that provide specific permissions beyond what built-in roles offer. Custom roles are defined using JSON templates that specify allowed and denied actions, assignable scopes, and role properties. They enable fine-grained access control and help implement the principle of least privilege.

Examples

Example 1: You create a custom role 'VM Snapshot Manager' that allows creating/deleting snapshots and reading VMs, but NOT deleting VMs or modifying their settings. Assign to backup team → They can manage snapshots for disaster recovery without access to VM configuration. Example 2: Same team member attempts to restart a VM (action not in custom role). Access denied—the role doesn't include 'Microsoft.Compute/virtualMachines/restart/action'. Member must request additional role if restart capability is needed. Exam trap: Custom role 'NotActions' (denied actions) override 'Actions' (allowed). If you allow 'Microsoft.Compute/*' but deny 'Microsoft.Compute/virtualMachines/delete', delete is blocked even though the wildcard includes it. NotActions wins.

Key Mechanisms

- Core function: Custom Azure roles allow organizations to create tailored role definitions that provide specific permissions beyond what built-in roles offer. - 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: You create a custom role 'VM Snapshot Manager' that allows creating/deleting snapshots and reading VMs, but NOT deleting VMs or modifying their settings. - Decision clue: Organizations create custom roles when built-in roles are too broad or don't match specific job functions.

Review Path

**Create custom role (Azure Portal or PowerShell):**

**Portal Method:** 1. Azure portal → Manage → Custom roles 2. Click 'Create custom role' 3. Name and description 4. Start from template or scratch 5. Add actions (e.g., 'Microsoft.Storage/storageAccounts/*/read') 6. Add NotActions if needed 7. Set assignable scopes 8. Create and assign to principal

**PowerShell Method:** $customRole = @{ Name = 'Custom VM Manager' Description = 'Manage VMs in RG' Actions = @('Microsoft.Compute/virtualMachines/read', 'Microsoft.Compute/virtualMachines/start/action') NotActions = @('Microsoft.Compute/virtualMachines/delete') AssignableScopes = @('/subscriptions/sub-id/resourceGroups/rg-name') } New-AzRoleDefinition -Role $customRole

Explanation

Managed identities provide Azure services with an automatically managed identity in Azure Active Directory. This eliminates the need to store credentials in code or configuration files. There are two types: system-assigned (lifecycle tied to the resource) and user-assigned (standalone resource that can be assigned to multiple Azure resources).

Examples

Example 1 (System-Assigned): Enable system-assigned managed identity on Azure VM. VM automatically gets identity in Azure AD. Assign Storage Blob Data Reader role to identity's principal ID. VM application code uses DefaultAzureCredential() to authenticate—no connection strings needed. Blobs accessed securely. Example 2 (User-Assigned): Create user-assigned managed identity 'AppIdentity'. Assign to App Service A, App Service B, and Container Instance C. Assign Key Vault Secrets User role to identity. All three services use same identity to read secrets—no credential duplication. Example 3: App Service with managed identity tries to access storage blob without assigned role. Managed identity exists, but no RBAC role granted. Access denied—identity is authenticated but not authorized. Exam trap: System-assigned identity DELETES with the resource. User-assigned persists after resource deletion. System = simpler, user-assigned = more flexible/shareable.

Key Mechanisms

- Core function: Managed identities provide Azure services with an automatically managed identity in Azure Active Directory. - 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 (System-Assigned): Enable system-assigned managed identity on Azure VM. - Decision clue: Eliminating hardcoded credentials in applications, securing connections between Azure services, implementing Zero Trust principles, reducing credential management overhead, enabling secure CI/CD pipelines, meeting compliance requirements for secrets management.

Review Path

**Create managed identity (Azure Portal):**

System-Assigned: 1. Go to Azure resource (VM, App Service, etc.) 2. Settings → Identity → System assigned 3. Toggle Status = On 4. Save 5. Note the Object (Principal) ID

User-Assigned: 1. Create resource → Managed Identity 2. Select subscription, RG 3. Name the identity 4. Create 5. Assign to resources: Resource → Identity → User assigned → Add

Then assign roles to the identity's principal ID using IAM.

Explanation

Using managed identities to access Azure resources involves configuring applications and services to authenticate using the managed identity instead of explicit credentials. This provides secure, credential-free access to Azure services like Key Vault, Storage, SQL Database, and other Azure resources through Azure RBAC permissions.

Examples

Example 1: Azure Function with user-assigned managed identity. Code uses DefaultAzureCredential() to access Key Vault. Managed identity is authenticated → Role 'Key Vault Secrets User' assigned → Function reads secrets without connection strings or stored passwords. Example 2: App Service connects to SQL Database using managed identity for AAD authentication. Connection string: 'Server=myserver.database.windows.net;Authentication=Active Directory Default'. No password needed; identity's AAD tokens handle auth. Example 3: Container Instance has managed identity but no role assignment to storage account. Code tries to read blobs. Managed identity is authenticated but NOT authorized (no RBAC role) → Access denied. Need to assign 'Storage Blob Data Reader' role first. Exam trap: Authentication (identity verified) ≠ Authorization (permission granted). Managed identity handles auth; RBAC handles authorization. Both needed.

Key Mechanisms

- Core function: Using managed identities to access Azure resources involves configuring applications and services to authenticate using the managed identity instead of explicit 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: Azure Function with user-assigned managed identity. - Decision clue: Securing application connections to Azure services, eliminating credential storage and rotation concerns, implementing least-privilege access principles, enabling secure DevOps practices, meeting compliance requirements, reducing operational overhead for credential management.

Review Path

**Use managed identity in application code:**

**C# / .NET Example:** var client = new SecretClient(new Uri(kvUri), new DefaultAzureCredential()); var secret = await client.GetSecretAsync('my-secret');

**PowerShell from VM/Function:** Connect-AzAccount -Identity $secret = Get-AzKeyVaultSecret -VaultName 'MyVault' -Name 'MySecret'

**Prerequisite:** Assign 'Key Vault Secrets User' role to managed identity.

Explanation

Configuring Azure Key Vault access involves setting up authentication and authorization mechanisms to securely store and retrieve secrets, keys, and certificates. This includes configuring access policies or RBAC permissions, managed identities, service principals, and implementing proper security practices for secrets management.

Examples

Example 1 (RBAC): Create Key Vault with RBAC enabled. Assign 'Key Vault Secrets User' role to an app's managed identity. App uses DefaultAzureCredential() to authenticate. Queries Key Vault → Identity verified + role checked → Secret returned. Example 2 (Legacy Access Policy): Create Key Vault with access policies. Add policy: Principal = user@domain.com, Permissions = {get, list}. User queries Key Vault → Policy checked → Secret returned. Example 3: App has managed identity but Key Vault using legacy access policies (not RBAC). No policy entry for app's identity. Even though identity is authenticated, authorization fails (policy blocks it). Need to add access policy for app's principal ID. Exam trap: RBAC and access policies are MUTUALLY EXCLUSIVE for most operations. You enable one or the other, not both. Microsoft recommends RBAC for new vaults.

Key Mechanisms

- Core function: Configuring Azure Key Vault access involves setting up authentication and authorization mechanisms to securely store and retrieve 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 (RBAC): Create Key Vault with RBAC enabled. - Decision clue: Centralizing secrets management across applications, eliminating hardcoded credentials, implementing secrets rotation strategies, meeting compliance requirements for data protection, enabling secure CI/CD processes, providing audit trails for secrets access.

Review Path

**Configure Key Vault (Azure Portal):**

1. Create Key Vault → Select 'Azure role-based access control' (RBAC recommended) 2. Access Control (IAM) → Add role assignment 3. Select role (Key Vault Secrets User for read, Secrets Officer for write) 4. Assign to: Managed Identity, User, Service Principal 5. Verify in Access Control (IAM) tab 6. Application code uses DefaultAzureCredential() to authenticate

**Legacy (Access Policies):** Key Vault → Access Policies → Add Access Policy → Select principal, permissions → Save

Explanation

Microsoft Entra Private Access provides secure, Zero Trust access to private applications and resources without requiring a traditional VPN. It enables users to access on-premises and cloud-based private applications through a cloud-based gateway with per-app access controls and enhanced security monitoring.

Examples

Example 1: Remote worker needs access to internal SharePoint site. Private Access deployed: User installs Private Access client → Conditional Access policy checks device compliance → Per-app access rule for SharePoint grants access → User connects through cloud gateway → Tunnel encrypted end-to-end → Internal SharePoint accessed securely. Example 2: Same user's device fails compliance check (not patched, no antivirus). Conditional Access evaluates before tunnel creation → Device fails check → Access blocked → User prompted to remediate device → After compliance fixed, access re-evaluated. Example 3: Contractor needs access to ONLY one app (expense reporting tool). Private Access allows per-app configuration. Contractor's access rule: App = 'Expense Tool' ONLY, other apps = blocked. Contractor can't accidentally access other internal resources. Exam trap: Private Access is NOT VPN. It's per-app access with Conditional Access + cloud gateway. VPN = 'connect to network'; Private Access = 'connect to SPECIFIC app through cloud.' Different mental model.

Key Mechanisms

- Core function: Microsoft Entra Private Access provides secure, Zero Trust access to private applications and resources without requiring 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: Remote worker needs access to internal SharePoint site. - Decision clue: Replacing traditional VPN solutions, implementing Zero Trust network access, securing remote work environments, providing granular application access, reducing IT overhead for remote access management, meeting compliance requirements for private application access.

Review Path

**Deploy Private Access (Entra Admin Center):**

1. Entra → Private Access → Create app segments 2. Define apps: Add on-premises/cloud apps you want to protect 3. Set access rules: Who can access which app segment 4. Configure Conditional Access for Private Access 5. Deploy Private Access Client to user devices 6. Users authenticate → CA evaluated → App access controlled → Tunnel established

Explanation

Traffic forwarding profiles in Microsoft Entra Global Secure Access define how network traffic is routed and secured. They specify which traffic should be forwarded through Global Secure Access (Microsoft's cloud gateway), enabling unified security policies, threat protection, and compliance monitoring across all network traffic types.

Examples

Example 1: Create forwarding profile for 'corporate-apps' that includes all traffic to internal web apps. Configure: Protocol = HTTPS, Source = all users, Destination = internal app IPs/domains. Traffic automatically routed through cloud gateway, evaluated against CA policies, then forwarded to apps. Example 2: User accesses app not in forwarding profile. Traffic goes direct (not through gateway) if app is excluded. If policy requires gateway forwarding for ALL apps, and user tries to access excluded app, that app becomes unreachable (intended security boundary). Example 3: Split-tunneling policy: All corporate traffic through gateway, all internet traffic direct. Forwarding profile includes only corporate IP ranges. User's YouTube traffic bypasses gateway (faster), but corporate app traffic goes through gateway (secured). Exam trap: Traffic forwarding is about ROUTING, not blocking. A forwarding profile says 'route this traffic through the gateway'; it doesn't inherently block. Blocking happens at CA policies or app rules.

Key Mechanisms

- Core function: Traffic forwarding profiles in Microsoft Entra Global Secure Access define how network traffic is routed and secured. - 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: Create forwarding profile for 'corporate-apps' that includes all traffic to internal web apps. - Decision clue: Implementing Zero Trust network access, securing all network traffic with unified policies, replacing traditional VPN segmentation, enabling granular traffic control, meeting compliance requirements for traffic monitoring, optimizing network performance with selective routing.

Review Path

**Configure traffic forwarding (Entra Admin Center):**

1. Global Secure Access → Traffic forwarding profiles 2. Create new profile (e.g., 'Corporate Apps') 3. Define traffic rules: - Destination: App IPs/domains/ports - Protocol: TCP/UDP, ports - Source: Users/groups/devices 4. Routing action: Forward through gateway 5. Apply Conditional Access to forwarding 6. Monitor: Traffic logs, policy effectiveness

Explanation

Conditional Access integrated with Global Secure Access enables policies to protect network traffic based on user, device, location, and risk signals. These policies evaluate every network connection attempt and can block, allow, or require additional authentication based on configured conditions, ensuring only compliant users access protected resources.

Examples

Example 1: CA policy: 'Block non-compliant devices from private app access.' Device is compliant → CA evaluation passes → Global Secure Access tunnel allowed → App access granted. Example 2: Device is non-compliant (missing security patches). CA evaluates: Device status = non-compliant → Policy blocks → Tunnel denied → User sees 'device must be compliant' message. Example 3: CA policy: 'Require MFA for high-risk locations.' User in high-risk location attempts private app access. CA evaluates: Location = high-risk → Trigger MFA → User completes MFA → Access granted. Exam trap: Global Secure Access CA policies evaluate at TUNNEL level, not app level. A user might have CA block at tunnel, meaning NO private apps accessible. App-level policies (like SaaS Conditional Access) are different.

Key Mechanisms

- Core function: Conditional Access integrated with Global Secure Access enables policies to protect network traffic based on user, device, location, and risk signals. - 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: CA policy: 'Block non-compliant devices from private app access.' Device is compliant → CA evaluation passes → Global Secure Access tunnel allowed → App access granted. - Decision clue: Protecting network access with risk-based policies, ensuring device compliance before allowing access, implementing granular network security controls, meeting compliance requirements for protected resource access, reducing breach surface by controlling tunnel access.

Review Path

**Create CA policy for Global Secure Access:**

1. Azure AD → Conditional Access → New policy 2. Assignments: - Users: Select target group - Cloud apps: Select 'Global Secure Access' 3. Conditions: - Device platforms: Windows, iOS, macOS - Device compliance: Mark as required - Locations: Define trusted locations - Risk levels: User/sign-in risk thresholds 4. Grant Controls: - Allow or Block - Require device compliance - Require MFA if high-risk 5. Enable and deploy to report-only first

Explanation

Global Secure Access clients are lightweight applications deployed to user devices that enable secure, cloud-based access to private resources and network traffic protection. These clients route protected traffic through Microsoft's cloud gateway while maintaining local user experience, and can be managed centrally through Mobile Device Management (MDM) solutions.

Examples

Example 1: Deploy Windows GSA client via Intune to all remote workers. Client automatically starts with Windows, routes corporate app traffic through cloud gateway per forwarding profiles, applies CA policies, and reports device compliance status. Example 2: Manage iOS GSA client: Define allowed apps in policy → iOS devices download and install client → Client enforces per-app routing → Only defined apps access private resources. Example 3: Client detects user device non-compliant (no antivirus). Client blocks all private resource traffic → Displays compliance warning → User must fix device → Client re-evaluates → Traffic flows after compliance met. Exam trap: GSA client is NOT a VPN app. VPN = all traffic redirected. GSA client = per-app/traffic-profile routing. User can use Internet normally while GSA client protects only specified traffic.

Key Mechanisms

- Core function: Global Secure Access clients are lightweight applications deployed to user devices that enable secure, cloud-based access to private resources and network traffic protection. - 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: Deploy Windows GSA client via Intune to all remote workers. - Decision clue: Deploying cloud-based network security to remote workers, centralizing security policy enforcement across devices, replacing traditional VPN clients with Zero Trust alternatives, enabling secure access from any device, providing compliance monitoring and reporting.

Review Path

**Deploy GSA client (Intune):**

1. Intune → Apps → All Apps → Add application 2. Select 'Global Secure Access' or search Microsoft app 3. Assign to device groups (all remote workers) 4. Configure app settings: - Forwarding profiles to apply - CA policies to enforce - Device compliance requirements 5. Deploy and monitor enrollment 6. Verify client installation and policy application on devices

**Management:** Intune dashboard → Monitor client deployment status, policy compliance, device health.

Explanation

Configuring Internet Access through Global Secure Access provides organizations with cloud-based traffic protection, threat intelligence, and web filtering. It routes user internet traffic through Microsoft's cloud gateway where it's inspected for threats, filtered based on policies, and monitored for compliance before reaching public internet resources.

Examples

Example 1: Organization enables Internet Access forwarding. User browses public websites → Traffic routed through cloud gateway → URL filtering checks category → Blocked categories rejected, allowed categories pass through → Safe browsing experience. Example 2: User attempts to access malicious site. Gateway threat intelligence identifies URL as phishing → Access blocked → User sees warning → Security team notified. Example 3: Implement web filtering policy: Block social media during work hours. Forwarding profile includes all internet traffic. CA policy: Time-based rule blocks social sites 9-5. User can access Facebook at 6 PM (outside policy window) but not during business hours. Exam trap: Internet Access forwarding is OPTIONAL traffic type. Private Access = private apps, Internet Access = public web. You can enable both, one, or neither. They're separate forwarding profiles.

Key Mechanisms

- Core function: Configuring Internet Access through Global Secure Access provides organizations with cloud-based traffic protection, threat intelligence, and web filtering. - 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: Organization enables Internet Access forwarding. - Decision clue: Protecting user devices from internet threats, implementing web filtering and content policies, reducing reliance on proxy appliances, gaining cloud-based visibility into user internet traffic, meeting compliance requirements for web access logging.

Review Path

**Enable Internet Access (Entra Admin Center):**

1. Global Secure Access → Internet access 2. Enable Internet Access forwarding 3. Configure traffic rules: - All traffic or specific apps - Exceptions (domains bypass filtering) 4. Define filtering policies: - Block categories: Adult, gambling, malware - Allow categories: Business, news 5. Time-based rules (optional) 6. Monitor: Traffic logs, threat detection alerts

Explanation

Assigning managed identities to Azure resources enables those services to authenticate to other Azure services without storing credentials. Once assigned, the resource has an identity in Azure AD with which it can request access tokens and authenticate to dependent services through Azure RBAC role assignments.

Examples

Example 1: Assign user-assigned managed identity to App Service. In code, use 'new DefaultAzureCredential()' to authenticate. App Service requests token from Azure AD using its managed identity → App Service is authenticated → Requests Key Vault secret → Token presented → Role (Key Vault Secrets User) verified → Secret returned. Example 2: Assign system-assigned managed identity to Azure Function. Azure Function environment automatically has identity. Code doesn't need to configure anything—DefaultAzureCredential just works. No connection strings, no secrets in code. Example 3: Managed identity assigned to VM but no role granted for SQL Database. VM tries to connect to SQL using managed identity. Authentication succeeds (identity verified) but authorization fails (no SQL Database role). Need to assign 'SQL DB Reader' role to identity's principal ID. Exam trap: Assigning identity ≠ granting permissions. Assignment = 'this resource has an identity'; permissions = 'this identity can do what.' Two separate steps, both required.

Key Mechanisms

- Core function: Assigning managed identities to Azure resources enables those services to authenticate to other Azure services without storing 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: Assign user-assigned managed identity to App Service. - Decision clue: Eliminating hardcoded credentials in Azure services, enabling secure service-to-service communication, implementing zero-trust authentication, reducing credential management overhead, securing CI/CD pipelines, enabling audit trails for service access.

Review Path

**Assign managed identity to resource:**

1. Go to Azure resource (App Service, Function, VM, etc.) 2. Identity → System assigned (or User assigned) 3. Toggle Status = On → Save 4. Copy the Object (Principal) ID 5. Go to target service (SQL, Key Vault, Storage) 6. Access Control (IAM) → Add role assignment 7. Select role (appropriate for target service) 8. Assign to: Select the managed identity 9. Review and assign 10. Application code can now use DefaultAzureCredential()

Explanation

Configuring managed identity access to resources involves setting up RBAC role assignments that grant specific permissions to the managed identity for the resources it needs to access. This establishes the authorization (what the identity can do) after the identity itself has been assigned to a service.

Examples

Example 1: App Service with managed identity needs to read Key Vault secrets. Assign role 'Key Vault Secrets User' to the managed identity's principal ID at the Key Vault scope. App Service code requests secret → Authenticated with identity → Authorized with role → Secret returned. Example 2: Azure Function needs to read/write blobs in storage account. Assign role 'Storage Blob Data Contributor' to function's managed identity at storage account scope. Function can now read AND write blobs without connection strings. Example 3: Container Instance with managed identity tries to access SQL Database. No role assigned. Authentication succeeds (identity recognized) but authorization fails (no SQL role). Need to assign 'SQL Database Reader' or 'SQL Database Contributor' role. Exam trap: Role scope matters. A role at the RG level grants broader access than at resource level. Be specific about scope for least privilege.

Key Mechanisms

- Core function: Configuring managed identity access to resources involves setting up RBAC role assignments that grant specific permissions to the managed identity for the resources it needs to 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: App Service with managed identity needs to read Key Vault secrets. - Decision clue: Establishing fine-grained access controls for managed identities, implementing least-privilege access principles, enabling secure cross-service communication, reducing need for connection strings and credentials, meeting compliance requirements for access auditing.

Review Path

**Assign roles to managed identity:**

**Via Azure Portal:** 1. Resource (SQL DB, KV, Storage) → Access Control (IAM) 2. Add role assignment 3. Select role (appropriate for resource type) 4. Assign to: Managed Identity 5. Select specific managed identity 6. Review and assign

**Via PowerShell:** $identity = Get-AzUserAssignedIdentity -ResourceGroupName 'rg' -Name 'identity' New-AzRoleAssignment -ObjectId $identity.PrincipalId -RoleDefinitionName 'Storage Blob Data Reader' -Scope '/subscriptions/sub-id/resourceGroups/rg-name'

Explanation

Service principals are the identity mechanism for applications and services in Azure AD. When an application needs to authenticate to Azure services or access organizational resources, a service principal is created in Azure AD. Service principals can be assigned roles and permissions, making them the primary way applications authenticate securely.

Examples

Example 1: DevOps pipeline needs to deploy Azure resources. Create service principal (app registration) → Assign 'Contributor' role to SP at subscription scope → Configure Azure Pipelines to use SP credentials → Pipeline authenticates as SP → Deployments execute with assigned permissions. Example 2: Third-party SaaS application needs access to tenant's data via Microsoft Graph API. Create service principal → Grant Microsoft Graph API permissions (Application permissions) → Admin consents → App uses client ID + secret to authenticate → Accesses authorized resources. Example 3: Application with service principal tries to access resource it doesn't have role for. SP authenticates successfully but RBAC authorization fails (no role assigned). Access denied. Need to assign role to SP's object ID. Exam trap: Service Principal = identity. Credentials (secret/certificate) = how it proves identity. App Registration = metadata in portal. Service Principal = actual identity object. Three related but distinct concepts.

Key Mechanisms

- Core function: Service principals are the identity mechanism for applications and services in Azure AD. - 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: DevOps pipeline needs to deploy Azure resources. - Decision clue: Enabling applications to authenticate to Azure services securely, implementing service-to-service communication without user credentials, automating infrastructure deployments with automated authentication, implementing least-privilege access for applications, integrating third-party applications with Azure resources.

Review Path

**Create and configure service principal:**

1. Azure portal → App registrations → New registration 2. Name the app, set redirect URI if needed 3. Create 4. Go to Certificates & secrets → New client secret (or upload cert) 5. Assign roles: Go to resource → Access Control (IAM) → Add role assignment - Role: Appropriate role - Assign to: Service Principal - Select the app 6. Application can now authenticate using client ID + secret 7. Monitor: Azure AD → App registrations → Sign-in logs → View authentication events

Explanation

Configuring workload identity with certificates and secrets involves creating secure credentials for service principals and managed identities. Service principals can authenticate using client secrets (passwords) or certificates. Workload identity federation allows applications outside Azure (like GitHub Actions) to authenticate using identity tokens without storing Azure credentials.

Examples

Example 1 (Client Secret): Create service principal, add client secret (password), store secret securely in CI/CD system. Pipeline authenticates: client_id + secret → Azure AD → Token issued → Resources accessed. Example 2 (Certificate): Service principal authenticated with X.509 certificate instead of secret. Certificate deployed to app server. App uses certificate to authenticate → No password needed. Example 3 (Workload Identity Federation): GitHub Actions repository needs to deploy to Azure. Create workload identity federation: GitHub subject → Federate with Azure app registration. GitHub Actions uses OpenID Connect token (no Azure secrets stored in GitHub) → Azure AD validates GitHub token → Issues token to GitHub → Deployment proceeds. Exam trap: Secret = password (expirable, higher risk, easier). Certificate = X.509 cert (harder to manage, longer lifetime). Federation = external token (no shared secret). Choose based on security posture and operational model.

Key Mechanisms

- Core function: Configuring workload identity with certificates and secrets involves creating secure credentials for service principals and managed identities. - 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 (Client Secret): Create service principal, add client secret (password), store secret securely in CI/CD system. - Decision clue: Securing application authentication in CI/CD pipelines, eliminating shared secrets in version control, implementing certificate-based authentication for compliance, enabling external applications to authenticate securely, reducing credential management overhead.

Review Path

**Configure credentials for service principal:**

**Client Secret:** 1. App registrations → Your app → Certificates & secrets 2. New client secret → Description, expiry 3. Copy secret value (shown only once) 4. Store in secure vault (Key Vault, GitHub secrets, etc.)

**Certificate:** 1. Generate X.509 certificate (openssl, PowerShell) 2. App registrations → Certificates & secrets → Upload 3. Upload public key part 4. Deploy private key to application securely 5. Configure app to use certificate for auth

**Workload Identity Federation (GitHub example):** 1. App registrations → Certificates & secrets → Federated credentials 2. Add credential → GitHub → Configure: - Organization: your-org - Repository: your-repo - Entity type: Environment / Branch / etc. - Subject identifier: ref:refs/heads/main 3. GitHub Actions can now authenticate without stored secret 4. In workflow: Use Azure Login Action → Authenticates via federation

Explanation

Enterprise applications represent instances of SaaS or on-premises applications integrated with Azure AD. Configuration includes user and group assignments, single sign-on (SSO) settings, user provisioning automation, conditional access policies, and application-specific claims mapping. Enterprise applications enable organizations to manage access to business-critical applications through Azure AD.

Examples

Example 1: Configure Salesforce as enterprise app. Add users/groups → Enable SAML SSO → Users sign in with Azure AD credentials → Auto-provisioned in Salesforce. Example 2: Enterprise app configured to require Conditional Access. User from non-compliant device attempts access. CA evaluates: Device non-compliant → MFA required OR access blocked depending on policy. User must remediate device. Example 3: Provision/deprovision automation: User added to 'Salesforce Users' group in Azure AD → Automatic provisioning adds user account in Salesforce and assigns license. User removed from group → Automatic deprovisioning deactivates Salesforce account. Exam trap: Enterprise app = application instance object, NOT the same as app registration (which is for custom apps). Don't confuse assignment (who can use app) with consent (user authorizing permissions).

Key Mechanisms

- Core function: Enterprise applications represent instances of SaaS or on-premises applications integrated with Azure AD. - 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: Configure Salesforce as enterprise app. - Decision clue: Enabling SSO for business-critical applications, automating user provisioning and deprovisioning workflows, centralizing application access management, implementing conditional access for SaaS apps, managing application-specific configuration at scale.

Review Path

**Configure enterprise app (Azure portal):**

1. Enterprise applications → All applications 2. Click app or click 'New application' to add 3. Users and groups → Add user/group → Assign 4. Single sign-on → Select protocol (SAML/OIDC) 5. Configure attributes: - Map Azure AD attributes to app claims - Email, Display Name, roles, etc. 6. Configure provisioning (if supported): - Provisioning mode: Automatic - Admin credentials for app - Scope: Which users/groups to provision 7. Conditional Access (if needed): - Create CA policy targeting the app 8. Test and monitor sign-ins

Explanation

Entra roles (also called Azure AD roles) provide administrative access to manage applications, users, and organizational settings within Azure AD. Application-related roles include Application Administrator, Application Developer, and Cloud Application Administrator. These roles control who can create, modify, and manage applications and their permissions.

Examples

Example 1: Assign 'Application Administrator' role to an IT admin. Admin can create app registrations, manage enterprise apps, assign users, configure SSO, manage permissions. Example 2: User with no Entra roles tries to access app registrations. Portal shows: 'You don't have permission to view this section.' User needs at least 'Application Developer' or 'Application Administrator' role. Example 3: Assign 'Cloud Application Administrator' role to app owner (not global admin). Owner can manage their apps' users, assignments, and settings but NOT create new apps or manage other apps. Exam trap: Entra roles ≠ Azure RBAC roles. Entra roles = administrative control of Azure AD (users, apps, policies). Azure RBAC = administrative control of Azure resources (VMs, storage, etc.). Different role systems; don't confuse.

Key Mechanisms

- Core function: Entra roles (also called Azure AD roles) provide administrative access to manage applications, users, and organizational settings within Azure AD. - 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: Assign 'Application Administrator' role to an IT admin. - Decision clue: Delegating application management responsibilities, implementing least-privilege administrative access, enabling app owners to manage their applications' users and settings, controlling who can create and modify application registrations.

Review Path

**Assign Entra roles (Azure AD):**

1. Azure AD → Roles and administrators 2. Search and select role (e.g., Application Administrator) 3. Click role → Add assignments 4. Search user/group to assign role 5. Assign 6. Verify in user properties → Assigned roles

**Recommended practice:** - Use Cloud Application Administrator for app owners (fewer privileges) - Use Application Administrator only when needed for broader control - Avoid Global Administrator for application-only tasks

Explanation

Microsoft Entra Application Proxy provides secure remote access to on-premises web applications through Azure AD authentication and authorization. It uses lightweight connectors installed on-premises that establish outbound connections to Azure, enabling users to access apps through a cloud-based URL without exposing on-premises infrastructure to the internet.

Examples

Example 1: Deploy Application Proxy connector on-premises. Publish internal SharePoint site through proxy. Users access 'https://sharepoint.company.com' (proxy URL) → Connector intercepts → Routes through Azure → Sharepoint accessed securely. Users see proxy URL, not internal IP. Example 2: Users from untrusted network attempt app access through proxy. Conditional Access policy blocks: Location = untrusted + Device = non-compliant → Access denied. User must remediate or use trusted network. Example 3: Multi-connector deployment for high availability. Deploy 2 connectors on-premises in different locations. Proxy balances traffic across connectors. Single connector failure doesn't block access. Exam trap: Application Proxy ≠ VPN. Proxy = per-app access through cloud gateway. VPN = full network access. Proxy is more secure for specific apps.

Key Mechanisms

- Core function: Microsoft Entra Application Proxy provides secure remote access to on-premises web applications through Azure AD authentication and authorization. - 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: Deploy Application Proxy connector on-premises. - Decision clue: Providing secure remote access to on-premises web applications, eliminating VPN requirements for app access, implementing conditional access for on-premises apps, reducing on-premises firewall complexity, enabling secure hybrid-cloud scenarios.

Review Path

**Deploy Application Proxy:**

1. Install connector: - Download connector installer from portal - Run as system/high-privilege account on-prem - Connector registers with Azure AD - Restart connector service

2. Publish on-premises app: - Azure portal → Application Proxy → Add application - Internal URL: http://internal-app.local - External URL: https://app.company.com (or auto-generated) - Configure SSO settings (pass-through, header-based, etc.) - Assign users/groups

3. Configure access: - Users/groups → Add assignments - Conditional Access → Target the published app

4. Monitor: - Application Proxy dashboard → Connector health - Sign-in logs → Track app access attempts

Explanation

Integrating SaaS applications with Azure AD enables single sign-on, user provisioning automation, and centralized access control for cloud-based business applications. Integration involves configuring SSO protocols (SAML, OIDC), mapping user attributes, setting up automated provisioning, and assigning users and groups to control access.

Examples

Example 1: Integrate Slack with Azure AD. User signs in to Slack → Redirected to Azure AD login → Authenticates with Azure AD credentials → SAML assertion returned → Slack validates assertion → User logged in. Example 2: Enable provisioning for ServiceNow. User added to 'ServiceNow Users' group in Azure AD → SCIM provisioning automatically creates ServiceNow account → User attributes (email, name) synced. Example 3: User from competitor company (external) attempts Slack login. Azure AD checks: User's domain ≠ company domain → Access denied. Only company domain users allowed. Exam trap: SaaS app integration involves multiple parts: SSO (authentication), attribute mapping (user data), provisioning (account creation), assignment (access control). All are needed for full functionality.

Key Mechanisms

- Core function: Integrating SaaS applications with Azure AD enables single sign-on, user provisioning automation, and centralized access control for cloud-based 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: Integrate Slack with Azure AD. - Decision clue: Enabling single sign-on for cloud business applications, automating user onboarding and offboarding, implementing conditional access for SaaS apps, centralizing user management, meeting compliance requirements for SaaS access control.

Review Path

**Integrate SaaS app (Azure portal):**

1. Enterprise applications → New application 2. Search app in Azure AD gallery (e.g., Slack, Salesforce) 3. Add → Configure Single sign-on - SAML (most common) - Set Assertion Consumer Service URL, Issuer URI 4. Manage users and groups → Assign users/groups 5. Enable provisioning (if supported): - Provisioning mode: Automatic - Admin credentials for app - Configure attribute mappings 6. Test: Click 'Test this application' as test user 7. Deploy: Assign production users

Explanation

Managing application access involves assigning individual users, groups, and application-specific roles to control who can access applications and what actions they can perform within those applications. Group-based assignment provides scalability, while role-based assignment enables granular permission controls within applications.

Examples

Example 1 (Group Assignment): Create 'Salesforce Managers' group → Add 10 manager users → Assign group to Salesforce enterprise app → All 10 managers auto-provisioned, SSO enabled, accounts created. Single assignment, scales to group size. Example 2 (Role Mapping): Salesforce app has roles: Admin, User, Viewer. Map Azure AD groups to Salesforce roles: 'Salesforce Admins' → Admin role, 'Salesforce Users' → User role. User added to group → Role auto-assigned in Salesforce. Example 3: User not assigned to app or group. Attempts to access → 'Access denied, contact admin.' Need to be explicitly assigned (user or group) or access won't work. Exam trap: Assignment scope: User (direct) = highest granularity, Group = operational, or inherited via app default. Group assignment is preferred for maintainability.

Key Mechanisms

- Core function: Managing application access involves assigning individual users, groups, and application-specific roles to control who can access applications and what actions they can perform within those 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 (Group Assignment): Create 'Salesforce Managers' group → Add 10 manager users → Assign group to Salesforce enterprise app → All 10 managers auto-provisioned, SSO enabled, accounts created. - Decision clue: Scaling application access management to large user populations, implementing role-based access control within applications, automating permission updates as group membership changes, simplifying administration of user app access.

Review Path

**Manage app assignments (Azure portal):**

1. Enterprise application → Users and groups 2. Add user/group: - Click 'Add user/group' - Select users or groups - Assign role (if app supports roles) - Assign 3. For group-based assignment: - Create security group in Azure AD - Add users to group - Assign group to app - All group members get app access

4. For role mapping: - App's 'Provisioning' → Attribute Mappings - Map Azure AD groups to app roles - User group membership → Role auto-assigned

5. Monitor: Users and groups tab shows all assignments

Explanation

User and admin consent controls determine how applications can request access to organizational resources. User consent allows users to authorize applications to access their data. Admin consent enables administrators to grant permissions that apply organization-wide or to individual users. Consent policies can restrict which applications users can consent to, requiring admin approval for sensitive permissions.

Examples

Example 1 (User Consent): User installs Office add-in, which requests 'Read user profile' permission (low-risk). User consent setting allows users to consent → User clicks 'Allow' → App gets permission. Example 2 (Admin Consent Required): SaaS app requests 'Read all users' data' (high-risk). Admin consent setting requires admin for sensitive permissions → User can't consent alone → Admin must review and approve. Example 3 (Admin Preapproved): Admin reviews custom app, approves access to Microsoft Graph 'Read user mail' → Admin grants consent → All users can use app without prompting. Users don't see consent screen. Exam trap: User consent ≠ admin consent. User consent = user approving for themselves. Admin consent = admin granting for organization (or specific users). Two different flows; understand which applies.

Key Mechanisms

- Core function: User and admin consent controls determine how applications can request access to 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 (User Consent): User installs Office add-in, which requests 'Read user profile' permission (low-risk). - Decision clue: Controlling application access to sensitive organizational data, preventing malicious applications from requesting dangerous permissions, implementing governance over third-party application access, balancing user experience with security requirements.

Review Path

**Configure consent settings (Azure portal):**

1. Azure AD → Enterprise applications → Consent and permissions 2. User consent settings: - Allow: Users can consent to low-risk permissions - Require: All permissions need admin consent - Disabled: Apps can't request permissions 3. Admin consent request settings: - Enable/disable admin consent workflow - Who receives admin consent requests (admin role) 4. Application consent policies: - Define which apps/publishers users can consent to - Restrict to verified publishers if needed

**Monitor consent:** - Enterprise applications → Permissions - Review consented permissions - Revoke permissions if needed

Explanation

Application collections in Azure AD allow organizations to group and organize enterprise applications for easier management and user discovery. Collections can be used to create logical groupings (by department, project, or function), customize the My Apps experience, and implement access policies at the collection level.

Examples

Example 1: Create 'Finance Department' collection → Add all finance-related apps (QuickBooks, SAP, expense tools). Finance users see collection with their apps, other users don't. Admin manages collections independently. Example 2: Create 'New Employee Onboarding' collection with essential apps (email, teams, payroll). Assign to onboarding group. New hires see guided list of apps they need. Example 3: User not in collection's target group. Attempts to access collection → 'Access denied.' Collections can be assigned to specific groups, limiting visibility. Exam trap: Collections are organizational tools, NOT security boundaries. Security is handled via assignments (users/groups). Collections are for UX/organization, assignments control access.

Key Mechanisms

- Core function: Application collections in Azure AD allow organizations to group and organize enterprise applications for easier management and user discovery. - 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: Create 'Finance Department' collection → Add all finance-related apps (QuickBooks, SAP, expense tools). - Decision clue: Improving user experience by organizing related applications, simplifying app discovery for large user populations, grouping apps by department or project, creating guided onboarding experiences, simplifying application management and governance.

Review Path

**Create and manage collections (Azure portal):**

1. My Apps → Collections → Create collection 2. Name and description (e.g., 'Finance Department') 3. Add apps: Search and select apps to include 4. Assign to groups (optional): - Users in group see this collection - Leave empty = all users see it 5. Publish 6. Users see collection in My Apps portal

**Best practices:** - Use collections to organize by department, project, or function - Don't create too many (cognitive overload) - Include all necessary apps for a workflow in one collection - Update collection ownership for large collections

Explanation

App registrations represent custom applications developed by your organization or third parties that need to authenticate with Azure AD and access organizational resources. Planning app registrations involves deciding authentication flows, permissions needed, credential types, and how the application will be deployed. App registrations must be created before an application can authenticate to Azure AD.

Examples

Example 1: Plan web app registration: Needs to access Microsoft Graph (delegated) and SQL Database (Azure RBAC). Create app registration → Add permissions → Configure redirect URI for OAuth flow → Issue client secret for backend → Deploy. App can authenticate and access resources. Example 2 (Multi-tenant): Develop SaaS app for multiple organizations. Create app registration as multi-tenant → Organizations consent to permissions → App can be used across tenants. Each organization has separate data isolation. Example 3: Desktop app tries to authenticate but not registered. App has no identity in Azure AD → Authentication fails. Exam trap: App registration (metadata) ≠ service principal (actual identity instance). Registration = blueprint; service principal = actual identity created when app used. Single registration can have multiple service principals (one per tenant).

Key Mechanisms

- Core function: App registrations represent custom applications developed by your organization or third parties that need to authenticate with Azure AD and 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: Plan web app registration: Needs to access Microsoft Graph (delegated) and SQL Database (Azure RBAC). - Decision clue: Planning and creating identities for custom applications, enabling applications to authenticate to Azure AD and access organizational resources, managing application permissions and consent, controlling application access to sensitive data.

Review Path

**Create app registration (Azure portal):**

1. Azure portal → App registrations → New registration 2. Name: App name 3. Supported account types: Single-tenant or multi-tenant 4. Redirect URI: Select platform (Web, SPA, Desktop) - For web: https://app.company.com/auth/callback - For SPA: http://localhost:3000 5. Create 6. In app registration: - Copy Application (client) ID - Copy Directory (tenant) ID 7. Configure permissions: - API permissions → Add permissions → Microsoft Graph - Select Delegated or Application scopes - Grant admin consent 8. Create credentials: - Certificates & secrets → New client secret (for web backend) - Copy secret value (shown only once) 9. Configure additional settings: - Owner: Assign owner for governance - Branding: Upload logo/company details 10. Application ready to use; deploy to app, configure SDK

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 ```

**Azure AD OAuth App Governance:** ```powershell # Connect to Azure AD 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 Azure AD 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 Azure AD 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 Azure AD tenant $connectedOrgParams = @{ displayName = "Partner Company Azure AD" 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 Azure AD 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