Conditional Access Baselines That Stop 99% of Attacks

Establishing a robust Conditional Access (CA) policy framework is fundamental to modern identity security, moving beyond traditional perimeter-based…

Establishing a robust Conditional Access (CA) policy framework is fundamental to modern identity security, moving beyond traditional perimeter-based defenses. Instead of assuming trust within the network, CA evaluates various signals—user, device, location, application, and risk—in real-time to make access decisions. This article outlines a set of essential CA baselines designed to mitigate the vast majority of identity-related attack vectors, focusing on practical implementation details for Azure AD Conditional Access.

Foundation: The "All Users, All Cloud Apps" Policy

The cornerstone of any effective Conditional Access strategy is a policy that targets all users and all cloud applications for Multi-Factor Authentication (MFA). This simple yet powerful policy drastically reduces the success rate of credential stuffing, phishing, and password spray attacks by introducing a second factor of authentication.

Policy Configuration:

• Users: "All users"
• Cloud apps or actions: "All cloud apps"
• Conditions: None (start broad, refine later)
• Grant: "Require multi-factor authentication"
• Enable policy: "On"

Exclusions: Critically, this policy must exclude your designated break-glass accounts. These are highly privileged emergency accounts, typically cloud-only, that bypass MFA and other CA policies to ensure access in an identity system outage. They must be monitored meticulously (e.g., via Azure AD Identity Protection or SIEM alerts) for any sign-in activity.

# Example Azure AD Graph PowerShell for policy creation (simplified)
# Note: Azure AD Graph API is deprecated. Use Microsoft Graph API for production.
# This is illustrative of policy scope.

Connect-MsolService

# Define policy conditions and grant controls
$conditions = New-Object -TypeName Microsoft.Open.AzureAD.Model.ConditionalAccessConditionSet
$conditions.Users = New-Object -TypeName Microsoft.Open.AzureAD.Model.ConditionalAccessUserCondition
$conditions.Users.IncludeUsers = @("All") # All users
$conditions.Applications = New-Object -TypeName Microsoft.Open.AzureAD.Model.ConditionalAccessApplicationCondition
$conditions.Applications.IncludeApplications = @("All") # All cloud apps

$grantControls = New-Object -TypeName Microsoft.Open.AzureAD.Model.ConditionalAccessGrantControls
$grantControls.Operator = "OR"
$grantControls.BuiltInControls = @("Mfa") # Require MFA

# Create the policy (requires specific tenant GUIDs for exclusions in practice)
New-MsolConditionalAccessPolicy -DisplayName "CA001: Require MFA for All Users to All Cloud Apps" `
    -Conditions $conditions `
    -GrantControls $grantControls `
    -State "Enabled"

Trade-off: While comprehensive, this policy can initially cause user friction. Implement it in "Report-only" mode first to gauge impact before full enforcement. Roll out in phases if your organization is large or has complex user groups.

Blocking Legacy Authentication Protocols

Legacy authentication protocols (e.g., POP, IMAP, SMTP AUTH, Basic authentication for Exchange ActiveSync) do not support modern authentication methods, including MFA. This makes them prime targets for brute-force and password spray attacks. Attackers frequently use these protocols to bypass MFA policies.

Policy Configuration:

• Users: "All users"
• Cloud apps or actions: "Office 365 Exchange Online" (or "All cloud apps" for broader coverage, but specific for Exchange is often sufficient as a first step)
• Conditions: "Client apps" -> "Configure" -> "Yes"
• Client apps: Select "Exchange ActiveSync clients" and "Other clients (e.g., POP, IMAP, SMTP, older Office clients)"
• Grant: "Block access"
• Enable policy: "On"

This policy specifically targets applications using these older protocols. Modern clients (Outlook for Microsoft 365, Teams, etc.) use modern authentication (OAuth 2.0) and will not be affected. Note that disabling legacy authentication at the tenant level (e.g., via Exchange Online PowerShell) is also recommended for a complete block, as Conditional Access only evaluates connections attempting to access AAD-protected resources.

# Exchange Online PowerShell to disable Basic Auth tenant-wide (supplementary control)
# Connect to Exchange Online PowerShell first
# Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com

# Disable Basic Auth for specific protocols
Set-AuthenticationPolicy -Identity DefaultAuthPolicy -AllowBasicAuthPOP $false
Set-AuthenticationPolicy -Identity DefaultAuthPolicy -AllowBasicAuthIMAP $false
Set-AuthenticationPolicy -Identity DefaultAuthPolicy -AllowBasicAuthSMTP $false
Set-AuthenticationPolicy -Identity DefaultAuthPolicy -AllowBasicAuthMAPI $false
Set-AuthenticationPolicy -Identity DefaultAuthPolicy -AllowBasicAuthRPC $false
Set-AuthenticationPolicy -Identity DefaultAuthPolicy -AllowBasicAuthOfflineAddressBook $false
Set-AuthenticationPolicy -Identity DefaultAuthPolicy -AllowBasicAuthWebServices $false
# To disable Basic Auth for Exchange ActiveSync:
# Set-CASMailbox -Identity user@yourdomain.com -ActiveSyncBlockLegacyAuth:$true
# Or for all users: Get-CASMailbox -ResultSize unlimited | Set-CASMailbox -ActiveSyncBlockLegacyAuth:$true

# Verify policy settings
Get-AuthenticationPolicy | Format-List

Require Compliant/Hybrid Azure AD Joined Devices for Privileged Roles

For administrative users or users accessing sensitive applications, requiring a device to be either Hybrid Azure AD Joined (for on-premises AD integrated environments) or Azure AD Compliant (managed by Intune or a third-party MDM) significantly elevates security. This ensures that only devices meeting your organization's security posture (e.g., OS patch level, disk encryption, antivirus status) can access critical resources.

Policy Configuration (Example for Admin Roles):

• Users: Select "Directory roles" -> "Global Administrator", "Application Administrator", "Cloud Application Administrator", etc. (all relevant admin roles)
• Cloud apps or actions: "All cloud apps" or specific sensitive admin portals (e.g., "Azure management", "Microsoft Admin Portals")
• Conditions: None (unless specific locations or device platforms are also required)
• Grant:
  • "Require multi-factor authentication" (always for admins)
  • "Require device to be marked as compliant" OR "Require Hybrid Azure AD joined device" (choose one based on your environment)
  • For multiple controls, use "Require one of the selected controls" if both are acceptable, or "Require all the selected controls" for stricter enforcement.
• Enable policy: "On"

Device States:

Risk-Based Conditional Access (Azure AD Identity Protection Integration)

Azure AD Identity Protection provides automated detection and remediation for identity-based risks. Integrating its risk signals into Conditional Access allows for dynamic access decisions based on the likelihood of a compromise.

Policy Configuration (Example: High Risk Sign-in Block):

• Users: "All users"
• Cloud apps or actions: "All cloud apps"
• Conditions:
  • Sign-in risk: "High"
• Grant: "Block access"
• Enable policy: "On"

Policy Configuration (Example: Medium Risk Sign-in Requires MFA):

• Users: "All users"
• Cloud apps or actions: "All cloud apps"
• Conditions:
  • Sign-in risk: "Medium"
• Grant: "Require multi-factor authentication"
• Enable policy: "On"

Identity Protection detects risks like impossible travel, unfamiliar sign-in properties, malware-linked IPs, password spray, and leaked credentials. By integrating these signals, you can automatically enforce stricter controls or block access when a sign-in attempt exhibits suspicious behavior. This is available with Azure AD Premium P2 licenses.

Location-Based Conditional Access

While IP-based controls aren't a panacea (VPNs, proxies), they add a valuable layer, especially for blocking known malicious geographies or restricting access to corporate networks only.

Policy Configuration (Example: Block Access from Malicious Countries):

• Users: "All users"
• Cloud apps or actions: "All cloud apps"
• Conditions:
  • Locations: "Configure" -> "Yes"
  • Include: "Any location"
  • Exclude: "Selected locations" -> Select named locations representing your corporate network IP ranges.
  • Location type: "Any location" (for blocking unknown/risky locations) OR "Selected locations" based on "Country/Region" (e.g., known threat source countries).
• Grant: "Block access"
• Enable policy: "On"

Named locations in Azure AD allow you to define trusted IP ranges (e.g., your office networks, VPN egress IPs). You can then create policies that allow access only from these trusted locations, or conversely, block access from untrusted ones.

Caveat: Be cautious with broad location-based blocks, especially for remote workforces or users who travel. Combine with risk-based policies for a more flexible approach.

Common Pitfalls and Troubleshooting

• Over-blocking: Starting too aggressively can lock out legitimate users, including yourself. Always use "Report-only" mode first.
• Break-glass accounts: Forgetting to exclude break-glass accounts can lead to a complete lockout during an outage. Ensure they are well-documented and secured.
• Legacy authentication: Simply blocking legacy auth in CA might still allow connections if not disabled tenant-wide in Exchange Online, as CA only intercepts AAD authentication attempts.
• Policy order/interaction: CA policies are evaluated sequentially. A "block" policy will always override a "grant" policy. Ensure your policy logic doesn't inadvertently bypass intended controls.
• Testing: Thoroughly test all policies with various user types (admin, standard user, guest), device types (managed, unmanaged), and locations.
• Incomplete exclusions: If you exclude "All users" from the MFA policy for specific apps, ensure that those apps don't become a bypass vector for other security policies.
• Licensing: Many advanced CA features (like Identity Protection integration and device compliance) require Azure AD Premium P2 licenses. Ensure your users are appropriately licensed.

By systematically implementing these baseline Conditional Access policies, organizations can significantly strengthen their identity security posture, effectively preventing the vast majority of credential-based attacks and moving towards a Zero Trust security model.