Identity and Access Management in Practice with Microsoft Entra ID

Identity and Access Management (IAM) is the discipline of deciding who or what can act, on which resource, under which conditions, and how that decision is proven afterwards. In cloud-hosted platforms, IAM is not a single control but a chain: an identity is authenticated, a policy evaluates context, a token is issued with claims, and a resource trusts that token because it trusts the issuer. Microsoft Entra ID

is Microsoft’s cloud identity and access platform, and it implements this chain for users, groups, applications and administrative roles across 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 integrated third-party services.

This guide builds the mental model first, then walks through a single bounded workflow: creating a security group, assigning it to an application role, and validating that the assignment behaves as expected before it is removed again. Every step is chosen because it produces observable evidence you can check, not because it is a memorised sequence of clicks. The guide assumes a non-production tenant or test environment, because IAM changes affect who can reach what, and mistakes here are consequential even when reversible.

#Learning Objectives

• Explain the core Entra ID objects (tenant, identity, group, role assignment, application registration) and how they relate.
• Describe the trust boundary between an identity provider, a token and a relying application.
• Design a bounded, reversible access-assignment change with explicit success evidence.
• Diagnose common assignment and propagation failures using observable signals.
• Connect a safe lab exercise to production permission, security and escalation practice.

#Prerequisites

• Use an isolated or non-production validation environment; do not perform this exercise against a production tenant.
• Confirm the Entra ID licence tier and your assigned administrative role before attempting any change, since directory role and feature availability vary by tier and are not addressed here in detail.
• Familiarity with basic directory concepts (users, groups) and REST
  The KBY Lexicon

  REST

  REST defines resource-oriented, stateless APIs built on a uniform interface; understanding its constraints clarifies scaling, caching and safe validation of state-changing calls.

  Read Full Context
  -style API thinking is assumed; deep PowerShell or Graph API experience is not required.

#Content

#

The identity chain: from directory object to trust decision

An Entra ID tenant is a dedicated, isolated directory instance. Inside it, a user or service principal is a directory object with attributes and memberships. When that identity signs in, Entra ID authenticates it (verifying who it is) and then, separately, authorises it (deciding what it may do) against the resource being requested. Authorisation in Entra ID is expressed through role assignments and, for applications, through app roles or scopes embedded in a token. This separation matters: a successful sign-in proves identity, not permission, and treating the two as the same thing is a common source of misconfiguration.

#

Groups as an indirection layer

Assigning permissions directly to individual users creates a maintenance and audit burden that grows linearly with headcount. Entra ID groups exist to break that dependency: a group is assigned a role or an application relationship once, and membership changes are then the only thing that needs to move. The trust boundary this creates is important to see clearly — the application or resource trusts the group’s role assignment, and the group’s membership list becomes the actual access-control surface. A membership change to that group is therefore a privilege change, even though it looks like a simple list edit.

#

Application registrations and app roles

When an application integrates with Entra ID, it does so through an application registration, which defines the application’s identity in the directory, and a corresponding service principal, which represents that application inside the tenant for authorisation purposes. App roles defined on the registration (for example, “Reader” or “Reports.Viewer”) can be assigned to users, groups or other service principals. The resource application later reads these role claims from the token it receives and enforces them itself — Entra ID issues the claim, but it does not enforce resource-level logic. This is a material assumption: if the resource application does not correctly check the role claim, the assignment is cosmetic.

#

Propagation, caching and why evidence matters

Role and group assignments do not always take effect instantly for an already-active session. Existing tokens remain valid until they expire or are explicitly revoked, and some directory changes propagate through caches with short but non-zero delay. This is why validation after a change must check actual evidence (a fresh token’s claims, a sign-in log entry) rather than assuming success from the absence of an error message in the admin console.

#Examples

#

Worked example: assigning a group to an application role

Setup: a test application registration named “Graduate-Lab-App” already exists in a non-production tenant, with a custom app role called “Lab.Reader” defined in its manifest. A group named “iam-lab-readers” exists with one test member.

Action: in the Entra admin centre, under Enterprise Applications, the “Graduate-Lab-App” service principal’s “Users and groups” blade is used to add an assignment, selecting the “iam-lab-readers” group and the “Lab.Reader” role.

Expected evidence: the assignment appears in the “Users and groups” list with status “Active” and role “Lab.Reader”. The Entra ID sign-in log (Identity > Monitoring & health > Sign-in logs) shows a subsequent sign-in from the test member with an application match against “Graduate-Lab-App”.

Interpretation: the presence of the assignment confirms the directory-side configuration is correct. It does not, by itself, confirm the application enforces the role — that must be checked separately by inspecting the token’s roles claim (for example, via a JWT decoder against a token obtained through the application’s own sign-in flow) and confirming “Lab.Reader” is present. This two-part check — directory assignment plus token content — is the minimum evidence needed to trust the change.

#Exercises

#

Exercise: bounded group-to-role assignment with rollback

Objective: Practise assigning and then fully removing a group-based app role assignment, producing evidence at each stage.

Setup: In a non-production tenant where you hold at least the Application Administrator or Cloud Application Administrator role, confirm the test application and test group described above exist, or create equivalents scoped only to your lab tenant.

Steps:

1. Record the current assignment state (screenshot or exported list) of the application’s “Users and groups” blade — this is your rollback baseline.
2. Add the group assignment with the target app role, as described in the worked example.
3. Confirm the assignment is listed as “Active” in the admin centre.
4. Obtain a token for a test member of the group and confirm the expected role claim is present.

Expected evidence: a visible “Active” assignment entry, and a token containing the expected role claim.

Pass condition: both the directory assignment and the token claim are confirmed present.

Stop condition: if the assignment does not appear as “Active” within a few minutes, or if you are unsure which tenant you are operating in, stop and do not proceed to further changes; escalate to your lab administrator rather than retrying blindly.

Cleanup: remove the group assignment from the application, confirm it no longer appears in “Users and groups”, and confirm a newly obtained token for the test member no longer contains the role claim.

#Validation Guidance

Validation in IAM work means confirming both the control-plane state (what the directory says) and the effective state (what a real token or sign-in shows). Checking only the admin centre risks trusting a configuration that is not actually enforced; checking only a token without knowing the assignment risks missing why access exists. Always pair a directory-side check with a token- or log-side check before considering an IAM change verified.

#Common Mistakes

• Assuming console success means enforcement: the admin centre confirming an assignment does not confirm the resource application checks it — always inspect the token or application behaviour directly.
• Assigning to individuals instead of groups: this appears simpler in a lab but does not transfer to production practice, where it becomes an audit and offboarding liability.
• Ignoring token lifetime: testing with a stale, already-issued token after making a change can produce a false negative, since the old token does not carry the new claim.
• Confusing authentication success with authorisation: a successful sign-in only proves identity; the role or scope claim must be separately confirmed.

#Key Takeaways

• Entra ID separates authentication (who) from authorisation (what), expressed through role assignments and token claims.
• Groups are an indirection layer; membership changes are privilege changes and should be treated with equivalent care.
• Application registrations define app roles, but enforcement depends on the resource application reading the claim correctly.
• Valid evidence for an IAM change requires both a directory-side check and a token- or log-side check.
• Every lab assignment exercise should have a recorded rollback baseline and a confirmed cleanup step before it is considered closed.

#Production Bridge

In production, the same assignment workflow requires additional controls this lab intentionally excludes: Privileged Identity Management (PIM) for time-bound, approved elevation rather than standing assignment; Conditional Access policies that constrain sign-in context; and change review before any group used for application access is modified, since that group is effectively a permissions boundary. Anyone performing this workflow outside a lab should confirm their own role is scoped to the minimum required (Cloud Application Administrator rather than Global Administrator, where possible), and should know the escalation path — typically a directory or identity platform team — if an assignment behaves unexpectedly or a token contains unexpected claims. Treat any group used for real application access as a security boundary, not an administrative convenience, and document who approved its use before relying on it operationally.