IT Toolbox
Guide

How to analyze a Conditional Access policy

This BAOI guide provides a structured method for analyzing an access policy without multiplying unnecessary changes.

TopicMicrosoft 365 →
⌚ About 2 min read
View my favorites
Microsoft 365. Intermediate. 15-30 min

This BAOI guide provides a structured method for analyzing an access policy without multiplying unnecessary changes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Set perimeter

    Identify the equipment, service, affected users and start time.

  2. 2

    Collect Elements

    Record the exact messages, logs and useful settings.

  3. 3

    Test methodically

    Start with the basic dependencies before the application components.

  4. 4

    Apply correction

    Change only the identified parameter or component.

  5. 5

    Validate

    Rewrite the full scenario and document the result.

À retenir

  • Keep the initial values for a backwards.
  • Avoid multiple simultaneous changes.
  • Compare with a functional configuration when possible.
← All les guides
Technical deep dive

Intune / Conditional Access: read the exact decision before excluding

Technical checkpoints

  • A non-compliant device can fail a compliance rule, device-state evaluation or sync delay; read the exact failing setting.
  • AADSTS53003 generally means access was blocked by Conditional Access; Sign-in logs show applied policies and their result.
  • The What If tool simulates user, app, platform, location and conditions without changing policy.

Read the sign-in

Open the exact sign-in and compare Grant Controls, Conditions and device state.

Entra ID > Sign-in logs > Conditional Access
Intune > Devices > Compliance > Per-setting status

Topic-specific pitfalls

  • Adding a broad exclusion for testing can create a security gap and hide the actual non-compliant setting.
  • A policy in Report-only does not have the same effect as Enabled; read the mode.

How to validate

  • The compliance setting passes and the new sign-in shows intended policies as Success/Not applied.
  • No unjustified temporary exclusion remains active.

Operational diagnosis

Conditional Access analysis starts with the sign-in event, not the policy editor. The sign-in log shows which policies were evaluated, matched, skipped or failed and why.

Step-by-step checks

  1. Open the exact sign-in event and confirm user, application, resource, device, location and authentication context.
  2. Review the Conditional Access tab for every evaluated policy, including not-applied reasons.
  3. Use the What If tool to reproduce expected targeting but treat the real sign-in event as final evidence.
  4. Check grant/session controls, authentication strength and device/compliance claims before changing exclusions.

Useful verification commands

Run only the commands that match the platform you are troubleshooting and capture the output before making a configuration change.

dsregcmd /status

How to validate the fix

Repeat the sign-in with the intended identity/device context and verify the expected policy is applied with the intended grant/session result.

Evidence to keep

Keep sign-in correlation/request ID, policy names, result, failure reason and relevant device/authentication claims.

Related BAOI resources: IT tools · procedures · IT dictionary.

♡ 0