Microsoft Entra ID Conditional Access What If

原文：Microsoft Entra ID Conditional Access What If — theDXT (Daniel Keer)

An underrated feature of Entra ID Conditional Access is the What If tool. The Conditional Access What If tool can help you troubleshoot or design Conditional Access policies.

Typically, when building a Conditional Access policy, you target a test user and then expand testing using report-only mode. Testing can be difficult if the workflow is complex or uncommon. Fortunately, the Conditional Access What If tool lets you simulate logins and policy impacts to test or troubleshoot without logging in multiple times or waiting for changes to propagate and the Entra sign-in logs to populate.

In this post, I will show you step by step how to use the Conditional Access What If tool.

The Process

• Login to the Microsoft Entra admin center.
• Click on Entra ID > Conditional Access.

• Click on Policies.

• Click on What if.

• Now we need to configure all the settings for the What If tool.

• For identity type, select whether to test Users, Guest or external users, Workload identities, or Agent identities.

In my example, I will select Users.

• Select the identity to simulate a login for.

Depending on which identity type you selected, your options will differ.

In my example, I will select my user account.

• For target resource, select what you want to test: Cloud apps, User actions, or Authentication context.

Depending on which target resource you selected, your options will differ.

In my example, I will select Cloud apps.

• Select the cloud app resource you want to simulate a login to.

If you have a Conditional Access policy targeting Office 365 or Microsoft Admin Portals, these are application groups. Unfortunately, we can’t select groups in the What If tool.

• For the Office 365 application group, some of the included applications are the following:
  • Office 365 Exchange Online App ID 00000002-0000-0ff1-ce00-000000000000
  • Office 365 SharePoint Online App ID 00000003-0000-0ff1-ce00-000000000000
  • Microsoft Office 365 Portal App ID 00000006-0000-0ff1-ce00-000000000000

A full list of all the applications included in the Office 365 group is available from Microsoft here.

• For the Microsoft Admin Portals application group, some of the included applications are the following:
  • Azure Portal App ID c44b4083-3bb0-49c1-b47d-974e53cbdf3c
  • Microsoft Office 365 Portal App ID 00000006-0000-0ff1-ce00-000000000000

A full list of all the applications included in the Microsoft Admin Portals group is available from Microsoft here.

In my example, I will select Office 365 Exchange Online.

• Select the device platform you want to simulate.

In my example, I will select Windows.

• Select the client app you want to simulate.

In my example, I will select Mobile apps and desktop clients – Modern authentication clients.

The following sign-in conditions settings are optional.

• Authentication Flow.

• Insider risk.

• Sign-in risk.

• User risk.

• IP address and Country.

If you want to test a country policy, you don’t need to use a real IP address, you can enter 127.0.0.1 or any random IP address. The IP address really only matters when you are testing or troubleshooting an IP address in a Conditional Access named location.

• Device filters.

• Once you configure your settings, click on What if to simulate the login and see the results.

• The Policies that will apply tab will show each policy that applied to the simulated login using the settings you configured.

• The Policies that will not apply tab shows each policy that did not apply to that simulated login and explains why.

In my example, the policy CA003 – All Apps – Block Countries – Exclude Canada – All Users is applying to my user. If I edit the sign-in conditions to include the IP 127.0.0.1 and the Country Canada, then when I rerun the What If tool, I can see that my account did not hit policy CA003 – All Apps – Block Countries – Exclude Canada – All Users.

If I look at the Policies that will not apply, I can see that the policy CA003 – All Apps – Block Countries – Exclude Canada – All Users did not apply because the location condition is now matched.

What the What If Tool Actually Evaluates

The What If tool runs your saved Conditional Access policies through the same evaluation engine a real sign-in would use, but against conditions you supply by hand instead of ones collected from a device and a network. For every policy it answers three questions: did the policy match, did it grant or block, and if it granted, which session controls such as sign-in frequency, app-enforced restrictions or a persistent browser session would have been applied.

It is a policy-evaluation simulator, not a sign-in simulator. It does not authenticate anyone, does not check MFA registration state and does not mint a token. That distinction matters during troubleshooting: if the question is "why was this user blocked", What If tells you which policy did it. If the question is "why did MFA not fire", the answer usually lives outside What If, in the authentication methods policy or the sign-in logs.

Reading the Results: Applied vs Not Applied

The result pane has two tabs and both deserve equal attention.

• Policies that will apply lists every policy that matched the simulated sign-in together with its grant controls. When more than one policy applies, their requirements combine: the user must satisfy the union of the grants, and a single block in this list wins outright.
• Policies that will not apply lists every policy that was skipped and, crucially, why. This is the most useful tab in practice because it tells you exactly which condition failed to match. "Not assigned to user", "Application condition not matched", "Location condition not matched" and "Client app condition not matched" each point somewhere different to look.

When a sign-in is unexpectedly allowed, the interesting question is not which policy blocked it — none did — but which policy should have and why it did not. Work the "will not apply" tab from the top.

Worked Example: Troubleshooting an Unexpected Block

Suppose a contractor reports that Outlook works but the SharePoint web interface is blocked on a managed laptop in the office. Reproduce that sign-in in What If with these conditions:

Identity type   : Users
Identity        : contractor@contoso.com
Target resource : Cloud apps -> Office 365 SharePoint Online
Device platform : Windows
Client app      : Browser
IP address      : 203.0.113.10   (the office public egress)
Country         : Canada

Run the simulation and open Policies that will apply. If a policy that targets all cloud apps with a block grant and no location exclusion appears, the fix is on the policy, not on the user. Then switch to Policies that will not apply and confirm that the intended exclusion policy did not match — perhaps the office egress IP belongs to a named location that the policy you found does not reference. The two tabs together let you prove the diagnosis before you change anything, which is the whole point of the feature.

Limitations You Must Know

• No application-group selection. Policies that target the Office 365 or Microsoft Admin Portals application groups must be tested by picking an individual app inside the group, such as Exchange Online, because the tool cannot select the group itself.
• Current policy state only. What If evaluates policies exactly as they are saved right now. It cannot replay history, so it is not a substitute for sign-in logs when you are investigating something that already happened.
• Device state is simulated loosely. You can choose a platform and a client app, but you cannot assert with full fidelity that a device is compliant, hybrid-joined or Entra-joined. Policies that depend on device compliance or device filters may behave differently from a real device.
• Authentication strength and MFA detail are approximate. The tool tells you that an authentication-strength grant applies; it does not prove the user can satisfy it.
• You must be able to read the policies. An administrator without permission to view Conditional Access policies will not get meaningful results.

Treat What If as a fast design and first-line triage tool and confirm anything security-critical against a real sign-in and its log entry.

What If vs Report-Only Mode vs Sign-In Logs

The mature workflow is a loop: design the policy, sanity-check it in What If, run it in report-only against real traffic, review the report-only results in the route of audit and sign-in logging, then enforce and keep watching the logs for unexpected blocks. Note that entitlement-driven access granted through access packages is a separate control plane and is not evaluated by What If at all.

Practical Checklist Before You Enforce

• Simulate at least three identities per policy: a target user, an excluded user and a break-glass account.
• Test both a matching and a non-matching location to prove the named-location exclusions actually work.
• Test every client app you really use — browser, modern-auth mobile and desktop clients, and legacy auth, because legacy clients do not understand MFA grants.
• Confirm the policy is not shadowed by a broader all-cloud-apps policy that also matches.
• Keep at least one account excluded from every policy and verify that exclusion in What If rather than on paper.
• Record the What If result in the change ticket; the "will not apply" reasons are strong evidence for a change review.

Frequently Asked Questions

Can I run What If from PowerShell? There is no first-class cmdlet for the What If engine. Automation instead targets the policy objects themselves, for example through Microsoft Graph, while What If stays an interactive admin-center tool.

Does What If cover workload identities? Yes. The identity type selector includes workload identities and agent identities, so you can simulate service-principal-style sign-ins against policies that target them. When the same identity is federated to a third party such as Cloudflare Access, test the sign-in path through that integration separately, because What If only sees the Entra-side evaluation.

Why does my country-based policy not match? When you only want to test a country condition, enter any routable-looking IP such as 127.0.0.1 and pick the country. The IP value only matters when you are testing a named location that contains specific addresses.

Should I delete report-only policies after testing? No. Keep them in report-only mode so the evidence survives, and store the What If simulations alongside them in your change record.

That’s all it takes to use the Microsoft Entra ID Conditional Access What If tool to test and troubleshoot Conditional Access policies.

If you want to read more about the Conditional Access What If tool, here is the Microsoft documentation.