Diagnosing Identity and Access Management with Microsoft Entra ID

Identity and Access Management (IAM) is the discipline of deciding who can act as whom, and what that identity is permitted to do, across a set of systems that do not inherently trust one another. Microsoft Entra ID

is Microsoft’s cloud identity and access platform, and it sits at the centre of this decision for organisations using Microsoft 365

The KBY Lexicon

Microsoft 365

Microsoft 365 defined at plain and technical depth, with architecture, operational relevance, an example and a common misunderstanding for practitioners.

Read Full Context

, Azure and many third-party applications. Understanding how it authenticates a user, issues a token, and enforces conditions on that token is the foundation for diagnosing almost every access problem you will encounter as a junior administrator.

This guide builds that foundation from first principles before asking you to do anything in a live tenant. You will learn the core objects Entra ID manages, how a sign-in request flows through the system, where trust boundaries sit, and why each diagnostic step produces the evidence it does. A bounded, non-destructive exercise follows, with explicit pass, stop and cleanup conditions, so you can practise diagnosis safely before any exposure to production permissions.

#Learning Objectives

• Explain the core Microsoft Entra ID objects involved in an access decision: users, groups, applications (service principals) and Conditional Access
  The KBY Lexicon

  Conditional Access

  Conditional Access evaluates identity, device and network signals at sign-in to grant, block or challenge access; safe use requires report-only validation and a tested rollback path.

  Read Full Context
  policies.
• Trace the cause-and-effect path of a sign-in request from authentication to token issuance to resource access.
• Identify the trust boundaries between the identity provider, the relying application and the resource being accessed.
• Diagnose a bounded access failure using sign-in logs as evidence, and distinguish observation from inference.
• Apply safe validation and rollback practices before touching any production identity configuration.

#Prerequisites

• Access to an isolated or non-production Microsoft Entra ID tenant for validation; do not practise diagnostic changes in a production tenant.
• Confirmation of your current role permissions and the Entra ID service tier before applying any change, since some diagnostic features (such as detailed sign-in logs) depend on licence tier.
• Basic familiarity with the concept of a directory (a store of identity objects) and a token (a signed claim about who a user is and what they are allowed to do).

#Content

#

What Microsoft Entra ID Actually Manages

Microsoft Entra ID is described by Microsoft as part of a broader identity and network access product family concerned with securing access to resources. At its core, it manages a directory of identity objects: users, groups, devices and applications (represented internally as service principals). When a user or an application wants to access a protected resource, Entra ID does not grant access directly. It authenticates the requester, evaluates any applicable Conditional Access policies, and then issues a security token asserting who the requester is and, where relevant, what they are allowed to do. The resource (for example, a SharePoint site or an API) is responsible for honouring that token’s claims. This separation is a trust boundary: Entra ID vouches for identity, but each resource enforces its own authorisation logic on top of that assertion.

#

The Sign-In Path, Step by Step

A typical interactive sign-in follows a predictable sequence, and each step is a place where something can fail and leave distinct evidence:

1. Discovery: the client application locates the correct tenant endpoint. A misconfigured tenant ID or authority URL fails here, before any credential is even checked.
2. Authentication: the user proves their identity, typically with a password and a second factor. Failures here produce an authentication-stage error in the sign-in log.
3. Conditional Access evaluation: Entra ID checks policies that may require, for example, a compliant device or a specific network location. A block here is a policy decision, not an authentication failure, and the log distinguishes the two.
4. Token issuance: if the previous steps succeed, Entra ID issues a token containing claims about the user and, if applicable, group membership or application roles.
5. Resource authorisation: the target application or API reads the token and decides, using its own logic, whether the specific action is permitted.

Because each stage produces distinct evidence, a graduate’s first diagnostic instinct should be to identify which stage failed before speculating about why. Conflating an authentication failure with an authorisation failure is one of the most common and most time-consuming diagnostic mistakes.

#

Trust Boundaries and Why They Matter

Three boundaries matter most when diagnosing IAM issues in Entra ID. First, the boundary between the identity provider (Entra ID) and the relying application: the application trusts Entra ID’s token but is responsible for validating its signature and expiry itself. Second, the boundary between a user’s directory identity and their effective access, which is shaped by group membership, role assignments and Conditional Access, meaning a user can be a valid identity yet still be denied a specific action. Third, the boundary between a human identity and an application identity (service principal), which often carries different, broader, or more static permissions than any individual user and therefore warrants closer scrutiny during least-privilege review.

#

Worked Example: Diagnosing a Blocked Sign-In

Consider a scenario in a non-production tenant: a test user reports they cannot access a test application. The graduate’s task is to determine why, using only observable evidence.

Step 1 — Observation. Open the sign-in logs for the affected user and application in the Microsoft Entra admin center. The log entry shows a status of “Failure” with an interrupt reason attributed to Conditional Access. This is an observation: a recorded fact from the system, not yet an explanation.

Step 2 — Inference. The log detail identifies the specific policy that applied, and its grant control (for example, “require compliant device”). From this, you can infer that the failure is a policy enforcement, not a credential problem, because authentication succeeded and the interrupt occurred at the Conditional Access stage.

Step 3 — Interpretation. Checking the test device’s compliance state in Intune (or the relevant device management console) shows it is marked non-compliant. This corroborates the inference: the user’s credentials were valid, but the device did not satisfy the policy’s condition.

Expected evidence and its meaning: a Conditional Access failure reason in the sign-in log, cross-referenced with device compliance state, is sufficient evidence to conclude the cause without needing to touch the user’s credentials or reset any password — a common but unnecessary first response that treats every failure as an authentication problem.

#Examples

#Exercises

#

Exercise: Trace a Conditional Access Block in a Non-Production Tenant

Objective: practise distinguishing authentication failure from Conditional Access enforcement using only sign-in log evidence.

Setup: in an isolated or non-production Entra ID tenant, using an account with at least Reports Reader or Security Reader role, locate an existing test Conditional Access policy (or ask a mentor to create a low-impact one, such as a report-only policy) and identify a test user affected by it.

Steps:

1. Open Entra admin center > Identity > Monitoring & health > Sign-in logs.
2. Filter by the test user and the relevant application over the last 24 hours.
3. Open a failed or report-only sign-in event and record the interrupt reason and applied policy name.
4. Cross-reference the named policy’s conditions against the test user’s known device or location context.

Expected evidence: a sign-in log entry showing a Conditional Access interrupt reason with a named policy, and a plausible match between that policy’s condition and the test context.

Pass condition: you can state, with the log entry as evidence, which specific policy condition was not met, and distinguish this from an authentication failure.

Stop condition: if you cannot view sign-in logs due to licensing or permission limits, stop and escalate to a mentor rather than attempting to expand your own permissions.

Cleanup: no configuration changes were made in this exercise; no cleanup is required beyond closing the log view.

#Validation Guidance

Validation in IAM diagnosis means confirming your explanation against independent evidence, not merely restating the log message. For the worked example and exercise above, validation succeeds when the Conditional Access interrupt reason, the named policy’s documented condition, and the test context (device compliance, location or risk state) all agree. If any of the three disagree, treat your explanation as unconfirmed and gather further evidence rather than proceeding to a fix.

#Common Mistakes

• Symptom: assuming any “Failure” status means bad credentials. Cause: not reading the interrupt reason field. Diagnosis: compare the failure stage against the table above. Correction: read the specific interrupt reason before acting. Recovery: none needed if no change was made yet.
• Symptom: resetting a user’s password to fix a Conditional Access block. Cause: conflating authentication and policy enforcement stages. Diagnosis: the log shows authentication succeeded prior to the interrupt. Correction: address the policy condition (for example, device compliance), not the credential. Recovery: revert any unnecessary password reset and inform the user.
• Symptom: treating a service principal’s broad permissions as equivalent to a user’s. Cause: not recognising the human/application trust boundary. Diagnosis: review the app registration’s assigned API permissions separately. Correction: apply least-privilege review to service principals explicitly. Recovery: escalate any over-broad grant for review before removal in production.

#Key Takeaways

• Entra ID authenticates and issues tokens; resources authorise actions independently — these are separate trust boundaries.
• Every sign-in failure stage (discovery, authentication, Conditional Access, token issuance, resource authorisation) produces distinct, identifiable evidence.
• Diagnosis should move from observation to inference to corroborated interpretation, never straight to a fix.
• Service principals and human identities carry different risk profiles and deserve separate least-privilege scrutiny.
• Non-production validation, explicit permission confirmation and stop conditions are prerequisites for any real diagnostic work, not optional extras.

#Production Bridge

In production, diagnosing Entra ID access issues requires at minimum a Reports Reader, Security Reader or equivalent least-privilege role; avoid using Global Administrator for routine diagnosis. Any configuration change (policy edit, role assignment, or app registration change) is state-changing and must be preceded by a recorded scope, a rollback plan (for example, exporting the current policy JSON before editing), and a defined stop condition if unexpected sign-in impact appears. Escalate to a senior identity administrator before modifying any Conditional Access policy, service principal permission, or privileged role assignment that affects users beyond your own test account. Never use production credentials or real user data while practising diagnosis in a lab tenant.