Microsoft MD-102: Identity, Access and Conditional Access — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #md-102 #certification #exam-prep #study-guide

Part of the Microsoft Endpoint Administrator Associate MD-102 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Identity, Access, and Conditional Access in Microsoft 365 establishes how users, devices, and apps are authenticated and authorized to corporate resources. Azure AD Conditional Access (CA) evaluates signals such as user and device state, location, and risk to enforce controls like MFA, compliant device, app protection, and session restrictions. Risk-based policies from Azure AD Identity Protection automate remediation for compromised users and risky sign-ins. Primary Refresh Tokens (PRTs) deliver seamless single sign-on on Azure AD joined devices, while Enterprise State Roaming preserves productive user experiences across devices. Privileged Identity Management enforces just-in-time elevation for administrators. Finally, well-structured Azure AD group strategy is fundamental for targeting in both Intune and Conditional Access with precision.

Conditional Access: conditions, grant controls, named locations, and MFA strategy

Conditional Access evaluates conditions and applies grant/session controls to produce a yes/no decision at token issuance. CA policies are evaluated after primary authentication and before an access token is issued.

Key conditions you must master:

• User and group: Scope who the policy targets. Use include/exclude logic to pilot and to carve out break-glass accounts.
• Cloud apps or actions: Select specific apps (e.g., Exchange Online, SharePoint Online, custom enterprise apps) or user actions (register security info).
• Device platform and device state: Filter by OS, and require device compliance or hybrid Azure AD join to meet Zero Trust device requirements. Device compliance is signaled by Intune and requires the device to be evaluated and marked compliant.
• Locations: Use named locations to include/exclude by country/region or IP ranges. Mark trusted network egress as “trusted” to relax controls when appropriate.
• Client apps: Distinguish modern auth clients (browser, modern Office clients) from legacy protocols (IMAP/POP/SMTP/ActiveSync basic). To block only legacy authentication while allowing modern auth, use the Client apps condition plus a Block grant control for legacy clients.
• Sign-in risk and user risk: Ingest risk signals from Identity Protection to trigger step-up or block decisions at sign-in time or based on account compromise.

Grant controls define what must be satisfied for access:

• Require multi-factor authentication
• Require device to be marked as compliant
• Require hybrid Azure AD joined device
• Require password change (risk remediation)
• Require terms of use
• Require approved client app and/or app protection policy (for MAM without enrollment)

Session controls shape post-auth behavior:

• Sign-in frequency and persistent browser session
• Conditional Access App Control (via Microsoft Defender for Cloud Apps) for real-time session inspection
• Disable resilience defaults where high-assurance is required

Policy lifecycle best practices:

• Start with report-only to validate impact
• Use policy templates for common scenarios (e.g., block legacy auth, protect admin roles)
• Always include emergency access accounts that bypass CA
• Combine “require device compliance” with Intune compliance policies to enforce OS, encryption, AV, and jailbreak/root checks

Named locations and trusted IP ranges:

• Named locations can be countries/regions (based on IP-to-geo) or specific IPv4/IPv6 CIDR ranges. Marking a named location as trusted enables use as an exclusion or to relax controls (e.g., bypass MFA in trusted offices). Only public egress IPs are effective; NATed private IPs are not visible externally.
• Identity Protection can treat trusted named locations as lower risk for unfamiliar sign-in detections. Maintain an authoritative list of corporate egress IPs and keep it current to avoid false positives.

MFA strategy—per-user MFA vs Conditional Access MFA:

• Per-user MFA (legacy) statically enforces MFA at the user object and supports “skip MFA for trusted IPs” only through its classic settings. It lacks contextual evaluation and granular targeting, and collides with CA prompts.
• Conditional Access MFA is the recommended approach. It applies MFA based on conditions such as app sensitivity, device state, and risk. It integrates with Identity Protection for risk-based prompts and supports modern authentication clients.
• Migration guidance: Disable/enforce “Disabled” for per-user MFA, implement CA-based MFA policies, and rely on the centralized Authentication Methods policy for method registration and enforcement (e.g., Authenticator, FIDO2, SMS). Use system-preferred MFA and number matching to harden push approvals.

Identity Protection, user and sign-in risk, and the role of PRT in seamless SSO

Azure AD Identity Protection (AIP) calculates probabilistic risk with machine learning and Microsoft threat intelligence:

• Sign-in risk evaluates each authentication in real time (e.g., unfamiliar sign-in properties, atypical travel, malware-linked IP, anonymous IP).
• User risk reflects the likelihood an identity is compromised (e.g., leaked credentials, repeated anomalous sign-ins).

Policies:

• Sign-in risk policy: For medium/high sign-in risk, enforce “Require MFA” or “Block access.” This is ideal for step-up at the moment of risky authentications.
• User risk policy: For medium/high user risk, enforce “Require password change” or “Block access.” This remediates compromised identities by forcing a secure password reset via SSPR/MFA.
• Integrations: Configure CA policies with “Sign-in risk” or “User risk” conditions for precise control per app. Exclude break-glass accounts. Use named trusted locations to reduce false positives.
• Licensing and audit: Identity Protection requires Azure AD Premium P2. Use the risk detections and investigation workflow to confirm, dismiss, or remediate risks, and export logs to a SIEM.

Primary Refresh Token (PRT) and seamless SSO on Azure AD joined devices:

• The PRT is a device-bound, user-scoped refresh token minted during device sign-in (Azure AD joined or hybrid Azure AD joined). It resides in the OS credential stack and is protected by TPM when available.
• The PRT enables SSO to Azure AD–integrated apps via the Web Account Manager (WAM) and MSAL, eliminating repeated prompts. When the initial sign-in satisfied MFA, the PRT carries an MFA claim that can fulfill CA “require MFA” without a new prompt until sign-in frequency expires or policy changes.
• Renewal and security: PRT is periodically renewed and can be nonce-challenged to assert device presence. Revoking device registration or disabling the user invalidates subsequent token issuance.
• Relation to Seamless SSO: Azure AD Seamless SSO (Kerberos-based via Azure AD Connect) primarily benefits domain-joined machines on the corporate network using PHS/PTA. Azure AD joined devices rely on PRT for SSO; you do not need Seamless SSO for AADJ devices to achieve SSO to cloud resources.

Enterprise State Roaming, PIM, and group strategy for precise targeting

Enterprise State Roaming (ESR):

• ESR synchronizes supported Windows settings and certain app settings for Azure AD users across Azure AD joined and hybrid Azure AD joined devices. Examples include personalization, language, and some Windows app settings; not documents or arbitrary files.
• Enable ESR in Azure AD tenant settings and scope to all or selected users. Data is encrypted in transit and at rest in Azure; keys are tenant-scoped. ESR reduces reconfiguration time during device replacement or Autopilot provisioning and complements, but does not replace, profile management solutions.

Privileged Identity Management (PIM) for just-in-time admin access:

• PIM (Azure AD P2) makes users eligible rather than permanently assigned to privileged roles (e.g., Global Administrator, Intune Administrator, Security Administrator) or privileged access groups (PAGs).
• Activation can require MFA, justification, ticket numbers, and approval, and can be time-limited with enforced start/end. It generates immutable audit records and alerting for excessive activation.
• Use PIM to reduce standing privilege, limit blast radius, and meet compliance. For Intune, make administrators eligible for the Intune Administrator role or a PAG that is granted scoped Intune RBAC. Require approval for high-impact roles and limit activation to working hours.

Azure AD groups for targeting in Intune and CA:

• Assigned groups: Static membership, ideal for piloting and when attributes are insufficient. Administratively simple and deterministic.
• Dynamic user groups: Membership calculated from user attributes (e.g., department, usageLocation, jobTitle). Best for user-scoped policies, app assignments, and license governance. Requires Azure AD Premium P1.
• Dynamic device groups: Membership based on device attributes (e.g., deviceOSType, deviceOwnership, enrollmentProfileName, deviceCategory). Best for device-scoped policies and app deployments.
• Intune targeting guidance:
  • Use user groups for user-based policies (e.g., app protection policies, Office app assignments) and device groups for device-based profiles (e.g., configuration, compliance).
  • Prefer Intune device filters for high-precision scoping across “All devices” assignments to reduce group sprawl and evaluation delays.
  • For Conditional Access, scope policies to users and workload identities; use device filters within CA when you need to narrow enforcement by device properties, and require “device compliant” or “hybrid joined” to enforce device posture.
• Hygiene: Avoid using nested groups that cause unpredictable delays in dynamic evaluation. Monitor membership processing and design fallback exclusions for break-glass or service accounts.

Putting it together: secure modern access patterns

A robust pattern for cloud-first endpoints:

• Block legacy authentication using a CA policy with the Client apps condition scoped to legacy protocols and a Block grant control.
• Enforce CA-based MFA with policy scoping by sensitivity (e.g., require MFA for Exchange/SharePoint and all admin portals). Eliminate per-user MFA to prevent conflicts.
• Require device compliance for desktop platforms with session controls for sign-in frequency. For mobile BYOD, require approved client apps and app protection policies without enrollment.
• Leverage Identity Protection: require MFA for medium sign-in risk, block high sign-in risk, and require password change for medium/high user risk.
• Use named locations to reduce friction on trusted corporate networks while still enforcing device compliance and session controls as needed.
• Ensure Azure AD joined devices obtain PRT for seamless SSO, supported by Intune compliance and Defender for Endpoint signals when applicable.
• Govern admin access with PIM and run periodic access reviews.

Practical Problem Scenario

Fabrikam, Inc. is rolling out Azure AD joined Windows 11 laptops with Intune management to a global workforce. Security requires blocking legacy auth, enforcing MFA based on risk, mandating compliant devices for Microsoft 365 access, enabling SSO, and minimizing user friction from frequent prompts. Administrators must elevate only when necessary. Users should retain desktop personalization across new devices.

1. Implement Conditional Access baseline

• Create a “Block legacy auth” CA policy: target all users, exclude two break-glass accounts, target all cloud apps, set Client apps to legacy protocols, and grant Block. Why: This precisely blocks only legacy protocols while preserving modern auth access.

2. Require MFA and device compliance for Microsoft 365

• Create “M365 access requires compliant device or MAM” CA policy: target all users, include Exchange Online and SharePoint Online, require device to be marked as compliant for Windows/macOS; for iOS/Android, require approved client app and app protection policy. Set session control sign-in frequency to 14 days. Why: Balances security and usability, enforcing Zero Trust on managed endpoints and MAM for BYOD without enrollment.

3. Enable risk-based protection with Identity Protection

• Configure Sign-in risk policy: for medium and above, require MFA; for high, block access.
• Configure User risk policy: for medium and above, require password change using SSPR+MFA. Why: Automates real-time and account-compromise remediation to reduce incident response time.

4. Establish named locations

• Define named IP ranges for Fabrikam’s datacenter and regional offices and mark them as trusted. Why: Decreases unnecessary MFA prompts from known egress points and improves risk signal accuracy.

5. Ensure seamless SSO via PRT on Azure AD joined devices

• Enroll devices with Windows Autopilot (Azure AD join) and Intune. Verify PRT issuance using dsregcmd /status and ensure time sync and TPM are healthy. Why: PRT provides device-bound SSO, satisfies CA MFA claims when applicable, and eliminates repeated prompts.

6. Configure Intune compliance and targeting with Azure AD groups

• Create dynamic device groups per platform and ownership, and apply compliance policies (encryption, minimum OS, Defender status). Use Intune device filters to refine “All devices” assignments for configuration profiles and Win32 apps. Why: Ensures only compliant devices receive access while minimizing group sprawl and evaluation lag.

7. Govern privileged access with PIM

• Make Helpdesk eligible for Intune Help Desk Operator and Endpoint Security Manager roles; make Cloud Ops eligible for Intune Administrator. Require MFA, justification, and 4-hour activation windows with approval for higher roles. Why: Reduces standing privilege, enforces least privilege, and provides auditable activations.

8. Enable Enterprise State Roaming

• Turn on ESR for all Azure AD users. Communicate which settings roam and validate sync on pilot devices. Why: Preserves user personalization across device replacements, improving productivity during lifecycle events.

This design uses Conditional Access for contextual enforcement, Identity Protection for automated risk remediation, PRT for frictionless SSO on Azure AD joined devices, Intune and dynamic groups for precise policy targeting, PIM for just-in-time admin, and ESR for a consistent user experience—all aligned with Zero Trust and operational efficiency.

← Endpoint Security and Microsoft Defender · All domains · Co-management and Hybrid Environments →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →