Conditional Access Policies

What it is

Conditional Access is the policy engine of Zero Trust in Microsoft Entra ID. A policy is an if then statement: if a sign in matches these assignments and conditions, then apply these controls. It lets you require MFA only when it matters, allow only healthy devices to reach sensitive apps, and block risky situations.

Conditional Access needs Microsoft Entra ID P1. The free alternative, security defaults, applies a fixed baseline and cannot be customised.

How it works

The parts of a policy

Exclusions take precedence over inclusions. If a user is in both an included group and an excluded group, the policy does not apply to that user. When several policies apply, they are all enforced, and a block overrides any grant.

Conditions in detail

• Locations use named locations, which are either country or region lists, or IP address ranges. Only IP ranges can be marked as trusted. A countries location can resolve a user's country from the IP address, or from GPS coordinates through the Authenticator app.
• Device platforms include Windows, macOS, iOS and Android.
• Client apps separate browsers and modern authentication clients from legacy protocols.
• Filter for devices targets devices by attributes, for example extensionAttribute1 -eq "PAW".

Grant controls

You can require all of the selected controls, or one of them. Legacy authentication protocols such as POP3 and IMAP cannot show MFA prompts, so a policy should block legacy authentication.

Designing a privileged access workstation policy

To allow administrators to reach the Azure portal only from privileged access workstations, with a device attribute PAW, create a policy that targets the administrator roles and the Azure management app, and blocks access on all devices except those matching the filter. The mistake is to block devices that match the filter, which would block the workstations you want to allow.

Templates, report only and emergency accounts

• Templates give ready made policies for common needs, such as requiring MFA for administrators, blocking legacy authentication or requiring MFA for risky sign ins.
• Report only mode evaluates a policy and records what it would have done without enforcing it, so you can test before turning it on.
• Always exclude emergency access accounts from policies that could block them, so a mistake cannot lock every administrator out.

Testing and troubleshooting

A user who is unexpectedly prompted or blocked is usually caught by a different policy than the one you expected, or is excluded from the one you expect.

SigninLogs
| where ConditionalAccessStatus == "failure"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ConditionalAccessPolicies

Choosing the design

A worked scenario

A company wants all administrators to use phishing resistant MFA. An administrator starts from a template and adjusts it: it targets the directory roles, applies to all cloud apps, requires the Phishing resistant MFA strength, and excludes two emergency access accounts. It is first set to report only. After a week, the sign in logs and the insights workbook show that a break glass account would have been affected, and it is added to the exclusions. The policy is then set to On. Later a contractor reports being blocked, and What If shows that a country block policy applies.