Troubleshooting with the sign-in logs

Service dependencies and audience reporting — two causes invisible from the error code.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Troubleshooting Conditional Access — Microsoft's method

Source: Troubleshooting sign-in problems with Conditional Access

· doc date 2026-03-24 · retrieved 2026-07-28

The official Conditional Access error codes

This is Microsoft's own list. Codes appear in the browser prefixed with AADSTS — e.g.

AADSTS53002.

53009 was missing from our earlier catalogue and belongs in the app-protection-policy

diagnosis path.

Broader codes (50076, 50079, 50072, 50158, 50173 and so on) come from the general

Microsoft Entra authentication and authorization error codes

reference rather than this page. The agent should treat the six above as the *canonical CA

set* and everything else as adjacent — see .

Configurations Microsoft says not to use

Explicitly listed as "Don't use the following configurations":

For all users, all resources:

• Block access — blocks the entire organisation.
• Require device to be marked as compliant — for users who haven't enrolled devices this

blocks all access including access to the Intune portal. An admin without an enrolled

device is blocked from getting back in to change the policy.

• Require Microsoft Entra hybrid joined device — blocks everyone without a hybrid joined

device.

• Require app protection policy — blocks everyone if no Intune policy exists. An admin

without a client app carrying an Intune app protection policy is **blocked from Intune and

Azure portals**.

For all users, all resources, all device platforms:

• Block access — blocks the entire organisation.

The recursive trap in three of these — the policy blocks the portal you would use to undo

the policy — is exactly what makes them Critical in our lockout model.

The diagnostic path

1. Read the error page. Browser sign-ins usually carry detailed text describing the

problem and suggesting a solution. More details reveals troubleshooting information

useful for searching the sign-in logs or opening a support case.

1. Entra admin center → Entra ID → Monitoring & health → Sign-in logs. Requires at least

Reports Reader.

1. Filter by: Correlation ID (best, when you have it) · Conditional Access (scope to

failures) · Username · Date · Resource.

1. Open the sign-in → Conditional Access tab. This shows the specific policy or policies

that caused the interruption. The Troubleshooting and support tab often states the

reason outright.

1. Select the Policy Name to drill into the policy configuration.
2. Other tabs — Basic Info, Location, Device Info, Authentication Details, Additional

Details — carry the client, user and device values used in the assessment.

Why a policy did or didn't apply

Select the ellipsis to the right of a policy in the sign-in event. The left side shows

details collected at sign-in; the right side shows whether those details satisfied the

policy's requirements.

**Conditional Access policies only apply when all conditions are satisfied or not

configured.**

That sentence resolves most "why didn't my policy apply?" questions.

When the sign-in event isn't enough

• Sign-in diagnostic: Basic info → Troubleshoot Event.
• What If tool to simulate.
• For a support case, include the request ID, time and date from the sign-in event.

Service dependencies — a top cause of confusing blocks

Users are blocked because cloud apps depend on resources that a Conditional Access policy

blocks.

Microsoft's example: the application is Azure portal, but the resource being called

is Azure Resource Manager. A policy targeting one and not the other produces a block that

looks unrelated to the app the user opened.

Fix: review the sign-in log for both the application and the resource called, then

include all of them in the policy.

Agent rule: whenever a user says "the policy doesn't target that app, so it can't be the

cause", check the resource field, not the application field.

Audience reporting

When a user signs in to something like Teams, they are requesting access to **multiple

resources** — Teams chat, Outlook calendar, Excel documents. The user thinks they are

signing in to Teams; Conditional Access applies across all of it. A restriction on SharePoint

(or specific SharePoint sites) will fire during what looks like a Teams sign-in.

Audience appears under the Resource section for all enabled and report-only policies,

visible after selecting a policy on the Conditional Access tab. Use it to explain why a

policy applied — the policy matched one of the audiences in the list.

This is the single best answer to "why is a SharePoint policy blocking Teams?"

If you are locked out

Microsoft's stated options, in order:

1. Find another admin who isn't blocked yet — they can disable the offending policy.
2. If no admin in the organisation can update the policy, submit a support request.

Microsoft support reviews and, after confirming, updates the Conditional Access policies

preventing access.

The agent should state option 2 plainly. It is the real answer when break-glass does not

exist, it is slow, and saying so is the strongest possible argument for having break-glass

accounts configured before they are needed.