Stackvora.tech

Azure AD Conditional Access: Top 5 Policies to Deploy Today

Azure Active Directory (Azure AD) Conditional Access (CA) acts as a policy enforcement engine, evaluating specified conditions (user, device, location,…

Azure Active Directory (Azure AD) Conditional Access (CA) acts as a policy enforcement engine, evaluating specified conditions (user, device, location, application, risk) to make an access decision. This granular control is crucial for securing cloud resources and is a foundational component of a Zero Trust architecture. Effectively configured CA policies can mitigate a significant percentage of identity-related attacks by enforcing Multi-Factor Authentication (MFA), restricting access based on device health, or blocking outdated authentication methods.

This article details five essential Azure AD Conditional Access policies that every organization should consider deploying immediately. These policies address common security vulnerabilities and align with Microsoft's security best practices, providing a strong security baseline.

1. Require MFA for Administrative Roles

Administrators possess elevated privileges that, if compromised, could lead to significant breaches. Requiring MFA for these accounts is non-negotiable. This policy targets Azure AD built-in roles and custom roles with administrative permissions, ensuring an additional layer of verification even if primary credentials are stolen.

Policy Configuration Details:

  • Users and groups: Select "Directory roles" and choose "Global Administrator," "Exchange Administrator," "SharePoint Administrator," "User Administrator," "Authentication Administrator," "Privileged Role Administrator," "Security Administrator," "Conditional Access Administrator," "Cloud Application Administrator," and any other custom administrative roles.
  • Cloud apps or actions: "All cloud apps."
  • Conditions:
    • Device platforms: "Any device."
    • Locations: "Any location" (or "Any location" excluding "Trusted locations" if defined).
    • Client apps: "All client apps" (ensure "Mobile apps and desktop clients" and "Browsers" are selected).
  • Grant: "Grant access," "Require multi-factor authentication."
  • Session: "Sign-in frequency" -> "Every time" (or a short duration like 1 hour if user experience is critical, but "Every time" is most secure for admins).
  • Enable policy: "On."

# Example using Azure AD PowerShell (MS Graph module) to list admin roles
# Connect-MgGraph -Scopes "RoleManagement.Read.All"
# Get-MgDirectoryRole | Where-Object { $_.DisplayName -like "*Admin*" } | Select-Object Id, DisplayName, Description

# For CA policy creation, it's typically done via the Azure Portal or using JSON/YAML ARM templates.
# Example Policy structure (simplified for conceptual understanding):
# {
#   "displayName": "MFA for Admins",
#   "state": "enabled",
#   "conditions": {
#     "users": {
#       "includeRoles": [ "Directory Role ID for Global Administrator", "..." ]
#     },
#     "applications": {
#       "includeApplications": [ "All" ]
#     },
#     "clientAppTypes": [ "all" ]
#   },
#   "grantControls": {
#     "operator": "OR",
#     "builtInControls": [ "mfa" ]
#   }
# }

Note: Always exclude an emergency access account (break-glass account) from all CA policies. This account should be highly secured, monitored, and used only in emergencies. Ensure it's a cloud-only account and not synchronized from on-premises AD.

2. Require MFA for All Users Accessing Cloud Apps

Extending MFA to all users for all cloud applications dramatically reduces the risk of credential stuffing, phishing, and brute-force attacks. While administrative accounts are high-value targets, standard user accounts are often easier to compromise and can serve as pivot points for attackers to gain deeper access.

Policy Configuration Details:

  • Users and groups: "All users."
  • Cloud apps or actions: "All cloud apps."
  • Conditions:
    • Device platforms: "Any device."
    • Locations: "Any location" (or "Any location" excluding "Trusted locations" for a more nuanced approach).
    • Client apps: "All client apps."
  • Grant: "Grant access," "Require multi-factor authentication."
  • Session: "Sign-in frequency" -> Consider a longer duration like "Every 90 days" for better user experience, or "Every time" for maximum security.
  • Enable policy: "On."

Trade-off: While highly secure, requiring MFA for every single sign-in can impact user productivity. Evaluate your organization's risk tolerance and user experience requirements when setting the sign-in frequency.

3. Block Legacy Authentication Protocols

Legacy authentication protocols (e.g., SMTP AUTH, POP3, IMAP4, older versions of Office clients that don't support modern authentication) do not support MFA and are highly susceptible to credential theft and brute-force attacks. Disabling these protocols is a critical security measure.

Policy Configuration Details:

  • Users and groups: "All users" (or specific groups for phased rollout).
  • Cloud apps or actions: "All cloud apps."
  • Conditions:
    • Client apps: Select "Exchange ActiveSync clients" and "Other clients." Ensure "Browser" and "Mobile apps and desktop clients" are not selected.
  • Grant: "Block access."
  • Enable policy: "On."

Important consideration: Before enabling this policy, ensure all your users and applications are using modern authentication. Monitor sign-in logs for "Client app" -> "Other clients" or "Exchange ActiveSync" to identify any remaining legacy authentication usage. Communicate widely with users and application owners about this change, as it can break older applications or devices. Consider a phased rollout starting with test groups.

4. Require Compliant Device for Accessing Company Resources (e.g., Exchange Online, SharePoint Online)

Requiring devices to be compliant with your organization's security policies ensures that access to sensitive data is only granted from healthy, managed endpoints. Device compliance policies are typically defined in Microsoft Intune or a third-party MDM solution, dictating requirements like OS version, encryption, antivirus status, and patch levels.

Policy Configuration Details:

  • Users and groups: "All users" (or specific groups with access to sensitive resources).
  • Cloud apps or actions: Select critical applications like "Office 365 Exchange Online," "Office 365 SharePoint Online," "Microsoft Teams," or "All cloud apps" if applicable.
  • Conditions:
    • Device platforms: Select specific platforms your organization supports (e.g., "Windows," "iOS," "Android," "macOS").
    • Client apps: "Mobile apps and desktop clients" and "Browsers."
  • Grant: "Grant access," "Require device to be marked as compliant."
  • Enable policy: "On."

Prerequisites: This policy requires devices to be either Azure AD Joined (for Windows 10/11) or Hybrid Azure AD Joined, and enrolled in an MDM solution (like Intune) that reports device compliance back to Azure AD. Ensure your device compliance policies in Intune are well-defined and rigorously tested before deploying this CA policy.

5. High-Risk Sign-ins Require Password Change or MFA

Leveraging Azure AD Identity Protection, this policy detects suspicious sign-in attempts (e.g., impossible travel, anonymous IP addresses, atypical locations) and automatically enforces a remediation action. This is a dynamic and proactive defense against compromised identities.

Policy Configuration Details:

  • Users and groups: "All users" (excluding emergency access accounts).
  • Cloud apps or actions: "All cloud apps."
  • Conditions:
    • User risk: "High" or "Medium and above" (based on your organization's risk tolerance).
    • Sign-in risk: "High" or "Medium and above."
  • Grant: "Grant access," "Require multi-factor authentication" AND "Require password change." (The "Require password change" option is available only for "User risk," not "Sign-in risk").
  • Enable policy: "On."

Azure AD Identity Protection Licensing: This policy requires an Azure AD Premium P2 license. Without it, the "User risk" and "Sign-in risk" conditions will not be available. Deploying this policy in "Report-only" mode first is highly recommended to understand its impact and potential false positives before enforcing it.

Common Pitfalls and Troubleshooting

  • Over-blocking: Starting with overly broad "Block access" policies without sufficient testing can lock out users. Always use "Report-only" mode first.
  • Emergency Access Accounts: Forgetting to exclude break-glass accounts can lead to a complete lockout of your tenant if CA policies are misconfigured or external services are down.
  • Exclusions vs. Inclusions: Be precise. If you include "All users" and then try to exclude a single user, make sure the exclusion takes precedence and is correctly configured.
  • Legacy Authentication: Not thoroughly checking sign-in logs before blocking legacy authentication can break critical applications or devices. Use the sign-in logs to identify users/apps still relying on it. Filter by "Client app" and review "Other clients" and "Exchange ActiveSync".
  • Licensing: Features like Identity Protection risk conditions require Azure AD Premium P2. Without the correct license, these options won't be available or functional.
  • Policy Order and Evaluation: Azure AD evaluates all applicable Conditional Access policies. A single "Block" policy will override "Grant" policies. Understand the Conditional Access policy evaluation order.
  • Testing: Always test new policies thoroughly with a small group of users before rolling out to production. Use the "What If" tool in the Conditional Access blade to simulate policy outcomes for specific users and conditions.

Back to the knowledge base · Ask the AI assistant