Conditional access policies

Conditional Access (CA) is a feature in Microsoft Azure Active Directory (Azure AD) that allows organizations to control access to resources based on specific conditions. It is an intelligent policy engine that automates decisions and enforcements about access. These policies are widely used to enhance security without sacrificing user productivity.

Conditional Access is essential in hybrid and cloud environments where securing access based on user identity, device state, location, and risk detection is crucial.

---

Why Use Conditional Access?

With rising threats from compromised credentials, phishing, and remote work, you can’t rely on a password alone. Conditional Access allows you to enforce access based on:

• User roles or groups
• Applications
• Location
• Device compliance
• Sign-in risk level
• Multi-Factor Authentication (MFA) enforcement
• Session controls (limited session time, etc.)

---

Step 1: Prerequisites

To use Conditional Access, ensure:

• You have Azure AD Premium P1 or P2 license
• You are an admin in Azure AD
• Your users are registered in Azure AD (not external-only or local-only in B2C)

Note: Conditional Access is primarily available in Azure AD (not Azure AD B2C), but Azure AD can be used as an identity provider in B2C to bring Conditional Access enforcement into B2C-based apps.

---

Step 2: Access the Conditional Access Portal

1. Sign in to Azure Portal
2. Go to Azure Active Directory > Security > Conditional Access
3. Click + New policy

---

Step 3: Name the Policy

Give the policy a meaningful name.

Example: "Require MFA for Admins" or "Block legacy authentication".

Avoid generic names like “Policy1.”

---

Step 4: Assign the Policy to Users or Groups

Under Assignments > Users or workload identities:

• Select:
  • All users (for general enforcement)
  • Specific groups (e.g., IT Admins, HR Department)
  • Directory roles (e.g., Global Admins)
• You can exclude specific users from the policy if needed for testing or break-glass accounts

Example:

• Include: “All users”
• Exclude: “BreakGlassAdmin”

---

Step 5: Choose Cloud Apps or Actions

Under Cloud apps or actions:

• Choose the applications this policy applies to
• Examples:
  • Microsoft Teams
  • SharePoint Online
  • Exchange Online
  • Any enterprise app registered in Azure

Optionally, choose User Actions, like Register security information.

---

Step 6: Define Conditions

You can define multiple conditions that must be met to trigger the policy. These include:

1. Sign-in Risk

• Use Microsoft’s Identity Protection to assess real-time sign-in risk (e.g., leaked credentials, suspicious IP)
• Options:
  • High
  • Medium
  • Low

2. Device Platforms

• Target Windows, iOS, Android, or macOS

3. Locations

• Block or allow based on location (IP-based named locations)
• Example: Block access from “Unknown Countries”

4. Client Apps

• Differentiate between:
  • Browser
  • Mobile apps and desktop clients
  • Legacy authentication clients (which don’t support MFA)

5. Device State

• Require that devices be:
  • Azure AD joined
  • Hybrid Azure AD joined
  • Intune compliant

---

Step 7: Configure Access Controls

You can grant or block access:

1. Grant Access

Require one or more of the following:

• Require MFA
• Require device to be marked as compliant
• Require Hybrid Azure AD joined device
• Require approved client app
• Require app protection policy

You can require multiple controls and choose whether:

• All selected controls are required
• Only one is required

2. Block Access

Useful for:

• High-risk sign-ins
• Legacy authentication protocols
• Access from specific countries

---

Step 8: Configure Session Controls (Optional)

Session controls allow you to:

• Limit persistent browser sessions
• Enforce sign-in frequency
• Use Conditional Access App Control for real-time monitoring and control (via Microsoft Defender for Cloud Apps)

---

Step 9: Enable the Policy

You have three options:

• Report-only: Logs the policy’s behavior without enforcing it (ideal for testing)
• On: Activates the policy
• Off: Keeps it disabled

It’s recommended to start with report-only mode, analyze logs, and then enable.

---

Step 10: Test the Policy

Before enforcing for all users:

1. Apply it to a test group
2. Attempt different access scenarios:
   • Normal login from compliant device
   • Login from an untrusted country
   • Legacy client attempt
   • High-risk sign-in simulation

Use Sign-in logs from:

• Azure Active Directory > Sign-in logs
• View “Conditional Access Status” and “Policy Details”

---

Step 11: Monitor and Adjust

Regularly review logs and adjust:

• Who the policy applies to
• Which apps or conditions are targeted
• Session duration and reauthentication frequency

Use tools like:

• Azure Monitor
• Microsoft Sentinel
• Workbooks and Dashboards

---

Common Use Case Examples

1. Require MFA for All Users

• Conditions: All users, all cloud apps
• Grant access: Require MFA

2. Block Legacy Authentication

• Conditions: Client app = legacy
• Control: Block access

3. Require Compliant Device for Finance App

• Users: Finance Group
• Apps: SAP, Oracle app
• Grant: Require compliant device

4. Block Access Outside Corporate Network

• Locations: Exclude “Head Office IP range”
• Block access elsewhere

---

Best Practices

• Start with Report-Only Mode
• Exclude break-glass accounts from all CA policies
• Enforce MFA via Conditional Access, not user settings
• Combine with Identity Protection for risk-based CA
• Use multiple layers: MFA, compliant device, and sign-in risk
• Avoid excessive CA overlap to reduce complexity
• Name policies clearly and consistently