MFA and Conditional Access in M365

Multifactor Authentication (MFA) is a security mechanism that requires users to present two or more verification factors to gain access to a resource. The three categories of factors are: - Something you know (password, PIN) - Something you have (phone, hardware token, authenticator app) - Something you are (biometrics like fingerprint or facial recognition)

MFA significantly reduces the risk of account compromise because an attacker must obtain multiple factors, not just a password.

Conditional Access (CA) is a policy-based engine in Azure Active Directory (Azure AD) that evaluates signals (user, device, location, app, risk) and enforces access decisions. CA policies are "if-then" statements: if a condition is met, then apply an access control (grant access, require MFA, block access). CA allows granular control over who can access what, under what conditions.

When a user attempts to sign in, Azure AD checks whether MFA is required (either by a per-user setting or a CA policy). If MFA is needed, the authentication flow proceeds as follows: 1. User enters password. Azure AD validates it against the user's stored hash. 2. Azure AD checks the user's MFA state (enabled, enforced, or disabled). 3. If MFA is required, Azure AD sends a challenge to the user's registered verification method (phone call, SMS, push notification, or OATH token). 4. The user completes the second factor. For example, with Microsoft Authenticator, the user receives a push notification, taps "Approve," and enters a number that appears on the sign-in screen. 5. Azure AD verifies the response and issues an access token if successful.

Default MFA verification methods include:

Per-user MFA is a legacy configuration where MFA is enabled or enforced for each user individually. Microsoft recommends using Conditional Access policies to require MFA instead, as it offers more granularity and integration with risk-based signals.

A Conditional Access policy consists of: - Assignments: Who (users/groups), What (cloud apps), Where (locations, IP ranges), When (time), and What device (platform, state). - Access controls: Grant (require MFA, require compliant device, require hybrid Azure AD joined device, require approved client app, require app protection policy) or Block. - Session controls: Enforce app restrictions, use app control for continuous access evaluation.

When a user attempts to access a resource, Azure AD evaluates all applicable CA policies. The evaluation process: 1. Collect signals: user identity, device state, location (IP address), application being accessed, risk level (if Azure AD Identity Protection is enabled). 2. Evaluate policies: Each policy's conditions are checked. If all conditions are met, the policy's access controls are applied. 3. Enforce controls: If multiple policies apply, the most restrictive combination is enforced. For example, if one policy requires MFA and another requires a compliant device, the user must meet both. 4. Result: Access is granted, blocked, or requires additional verification.

To configure a Conditional Access policy in the Azure portal: 1. Navigate to Azure Active Directory > Security > Conditional Access. 2. Click "New policy." 3. Assign a name, select users/groups, cloud apps, conditions (device platforms, locations, client apps, sign-in risk, etc.). 4. Under Access controls, choose Grant or Block, and configure any required grant controls. 5. Set policy to "Report-only" initially to test impact, then "On" for enforcement.

To verify MFA registration status via PowerShell:

Get-MsolUser -UserPrincipalName user@domain.com | Select-Object StrongAuthenticationRequirements, StrongAuthenticationMethods

To check CA policy results:

Get-AzureADMSConditionalAccessPolicy | Format-List

Common exam traps:

A multinational company with 10,000 employees wants to require MFA for all cloud app access, but exempt users connecting from the corporate headquarters (trusted IP range). The solution: Create a CA policy targeting all users and all cloud apps, with a condition to exclude the corporate IP range. For users outside the office, MFA is enforced. The policy is set to "Report-only" for two weeks to monitor impact, then enabled. Common issues: Users forget to register MFA methods; administrators must run a registration campaign using Azure AD Identity Protection's MFA registration policy. Performance: No noticeable latency; CA evaluation adds <100ms to sign-in.

A healthcare organization must comply with HIPAA by blocking legacy authentication protocols (POP, IMAP, SMTP) that do not support MFA. They create a CA policy targeting all users and the Office 365 Exchange Online app, with a condition for client apps: select "Exchange ActiveSync" and "Other clients" (legacy). The access control is set to Block. This prevents any legacy protocol from accessing mailboxes. Misconfiguration: If the policy inadvertently blocks modern clients (e.g., Outlook for Windows uses modern auth), administrators must ensure the client apps condition excludes modern authentication clients. Common mistake: Forgetting to exclude service accounts that still rely on legacy protocols for on-premises integrations.

A financial services firm uses Azure AD Premium P2 to implement risk-based CA. They configure a policy that requires MFA when sign-in risk is medium or higher, and blocks access when risk is high. Another policy requires a password change when user risk is high. This automates responses to compromised credentials. Scale: With 50,000 users, Identity Protection processes millions of sign-in events daily. Administrators must tune risk thresholds and review risky users weekly. Common failure: Overly aggressive policies cause false positives, locking out legitimate users. Mitigation: Use report-only mode initially and adjust thresholds.