2.2 Authentication Methods, MFA, and Conditional Access Policy Design

2.2 Authentication Methods, MFA, and Conditional Access Policy Design

Authentication forms the gateway to organizational resources. Modern identity security requires transitioning away from weak, password-only authentication toward robust Multi-Factor Authentication (MFA), passwordless mechanisms, and context-aware Conditional Access policies.

Authentication Methods Hierarchy

Microsoft Entra ID structures authentication methods along a security spectrum based on resistance to credential theft, Man-in-the-Middle (MitM) relay, and social engineering attacks:

[ HIGHEST SECURITY ]
  |  1. Phishing-Resistant MFA  --> FIDO2 Security Keys, Entra CBA, Windows Hello for Business
  |  2. Passwordless MFA        --> Microsoft Authenticator (Number Matching + Push)
  |  3. Standard MFA            --> Authenticator OTP, Software Tokens
  |  4. Weak MFA                --> SMS Text, Voice Call
[ LOWEST SECURITY ]

1. FIDO2 Security Keys (Fast IDentity Online)

FIDO2 security keys (e.g., YubiKey, Feitian) implement WebAuthn and CTAP2 standards to provide phishing-resistant MFA. When authenticating, the security key cryptographically binds the authentication assertion to the specific domain origin (URL) in the browser address bar. Even if an attacker lures a user to a proxy phishing site (e.g., login.microsoft.attacker.com), the FIDO2 key detects the domain mismatch and refuses to sign the authentication challenge.

• Requires physical touch or biometric scan plus a secret PIN stored on the hardware key.
• Ideal for high-privilege administrators, targeted executives, and strict compliance environments.

2. Microsoft Authenticator Passwordless

Eliminates passwords by replacing them with phone sign-in. During sign-in:

1. The user enters their username.
2. The browser displays a unique two-digit number.
3. A push notification arrives on the user's mobile device displaying the app name and geographic map location.
4. The user enters the matching two-digit number into the Authenticator app and completes biometric verification (Face ID / fingerprint) or device PIN.

3. Certificate-Based Authentication (CBA)

Entra ID native Certificate-Based Authentication (CBA) enables organizations to authenticate users directly against X.509 client certificates issued by an enterprise Public Key Infrastructure (PKI) or Active Directory Certificate Services (ADCS). CBA eliminates the need for federated infrastructure (such as AD FS):

• Client certificates can be hosted on hardware smartcards or physical PIV/CAC cards.
• Entra ID maps certificate fields (e.g., Principal Name, Subject Alternative Name RFC822) directly to tenant user accounts.

4. Self-Service Password Reset (SSPR) Configuration

SSPR allows users to reset their own passwords without helpdesk intervention. Key security settings include:

• Registration Enforcement: Forces users to register SSPR methods upon next sign-in.
• Methods Required: Configurable to require 1 or 2 methods to reset a password.
• Password Writeback: Requires Microsoft Entra Connect or Entra Cloud Sync. When a user resets their password in the cloud, SSPR writes the new password hash synchronously back to on-premises Active Directory Domain Services, ensuring hybrid identity consistency.

---

MFA Implementation & Authentication Strengths

Legacy per-user MFA (enabling MFA status to Enabled or Enforced on user objects) is deprecated because it enforces static, inflexible prompts regardless of context. Modern architecture uses Conditional Access policies combined with Authentication Strengths (Entra ID P2 feature).

Authentication Strengths allow administrators to specify exactly which authentication combinations are acceptable for accessing specific resources:

• Built-in MFA Strength: Password + any secondary factor (SMS, voice, push notification).
• Built-in Passwordless MFA Strength: Microsoft Authenticator Phone Sign-in, FIDO2, Windows Hello.
• Built-in Phishing-Resistant MFA Strength: FIDO2 Security Keys, Windows Hello for Business, Certificate-Based Authentication.

---

Conditional Access Policy Architecture

Conditional Access operates as the central Zero Trust decision engine ("if-then" rule processor). It evaluates real-time signals before granting access to resources.

+-------------------------------------------------------------------------+
|                           SIGNAL EVALUATION                             |
|  - Users & Groups      - Locations (IP / GPS)   - Device Compliance     |
|  - Cloud Applications  - Client Apps            - User & Sign-in Risk   |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                        CONDITIONAL ACCESS ENGINE                        |
|                   (Evaluates All Matching Policies)                     |
+-------------------------------------------------------------------------+
                                    |
         +--------------------------+--------------------------+
         |                                                     |
         v                                                     v
+------------------------------+             +----------------------------+
|       GRANT CONTROLS         |             |       SESSION CONTROLS     |
| - Block Access               |             | - Sign-in Frequency        |
| - Require MFA                |             | - Persistent Browser       |
| - Require Compliant Device   |             | - App Control (Defender)   |
| - Require Auth Strength      |             | - Continuous Access (CAE)  |
+------------------------------+             +----------------------------+

Conditional Access Components Breakdown

1. Assignments:
   • Users & Groups: Specific users, groups, or directory roles included or excluded.
   • Target Resources: Scopes policy to Cloud Apps (e.g., Azure Management, Office 365), User Actions (e.g., "Register security information"), or Authentication Contexts.
2. Conditions:
   • User Risk & Sign-in Risk: Triggers based on Entra ID Protection risk score thresholds.
   • Device Platforms: iOS, Android, Windows, macOS, Linux.
   • Locations: Named locations defined by IPv4/IPv6 ranges (Trusted IPs) or geographic countries.
   • Client Apps: Browser, Mobile/Desktop apps, and Legacy authentication clients.
   • Filter for Devices: Evaluates rules against device properties (e.g., device.isCompliant -eq true).
3. Grant Controls:
   • Block Access: Hard denial of access.
   • Grant Access with Requirements: Require MFA, Require Compliant Device, Require Hybrid Entra Joined Device, Require Approved App, Require Authentication Strength.
   • Operator Logic: Require all selected controls (AND) vs Require one of the selected controls (OR).
4. Session Controls:
   • Sign-in Frequency: Forces re-authentication after specified time intervals (e.g., every 8 hours).
   • Persistent Browser Session: Prevents or forces persistent cookies.
   • Continuous Access Evaluation (CAE): Enforces real-time token revocation upon critical events (account disabled, password changed, IP address modified) without waiting for token expiration.

---

Essential Policy Design Patterns

1. Require MFA for All Administrative Roles

• Scope: Target Users -> Directory Roles (Select all 40+ directory admin roles).
• Target Resources: All Cloud Apps.
• Grant: Require Phishing-Resistant MFA Strength.
• CRITICAL REQUIREMENT: Exclude Emergency Access ("Break-Glass") Accounts to prevent accidental global tenant lockout during identity provider anomalies.

2. Block Legacy Authentication

Legacy authentication protocols (POP3, IMAP4, SMTP, MAPI, older Office clients) cannot process interactive MFA challenges. Threat actors heavily target legacy endpoints to execute password-spray attacks.

• Conditions: Client Apps -> Select Other clients (Legacy authentication).
• Grant: Block Access.

3. Require Compliant Device or Hybrid Join for Corporate Data

• Target Resources: Office 365, Azure Management.
• Conditions: Exclude Trusted Corporate Locations.
• Grant: Require Device to be Marked as Compliant OR Require Microsoft Entra Hybrid Joined Device.

---

Conditional Access Evaluation Flow

Understanding how Entra ID processes multiple overlapping policies is vital for passing the AZ-500 exam:

---

Report-Only Mode Testing

Deploying new Conditional Access policies directly into active enforcement risks blocking valid business workflows. Report-only mode allows administrators to test policy impact safely:

• The engine evaluates sign-in events against report-only policies and logs the result without enforcing block or MFA challenges.
• Administrators inspect results in Sign-in Logs (under the Report-only tab) and the Conditional Access Insights and Reporting Workbook in Azure Monitor to verify success/failure ratios before toggling policy state to On.