Learning Identity and Access Management Through a Safe Microsoft Entra ID Lab

#Introduction

Microsoft Entra documentation describes Microsoft Entra as an identity and network access product family used to secure access to an organisation’s resources. Identity and Access Management (IAM) is the discipline of deciding who and what can reach those resources, and under what conditions. For a graduate or early-career practitioner, the risk in learning IAM is not the concepts themselves but the temptation to practise on a live tenant, where a misapplied policy can lock out real people. This guide works through one deliberately bounded workflow: creating a small, identifiable security group, attaching a report-only Conditional Access policy to it, validating the result through sign-in evidence, and then removing everything cleanly. Every step is scoped so that a mistake affects only the lab artefacts you created, never a production population.

#Learning Objectives

• Explain the relationship between a Microsoft Entra ID tenant, users, groups and Conditional Access policies.
• Create and verify a cloud-only security group intended for a bounded validation exercise.
• Attach a Conditional Access policy in report-only mode and interpret the resulting sign-in evidence.
• Distinguish observed evidence from inferred conclusions when reviewing policy behaviour.
• Roll back every change made during the exercise and confirm the tenant returns to its prior state.

#Prerequisites

• An isolated or non-production Microsoft Entra ID tenant, with no real end-user population depending on it.
• Confirmed product version, licence tier and your own permissions before applying any change.
• An account holding directory roles sufficient for group management and Conditional Access administration in that tenant, following the principle of least privilege rather than a broad administrative role.
• The Microsoft Graph PowerShell SDK installed and authenticated interactively for the duration of the exercise.
• At least one designated break-glass or emergency-access account excluded from any policy you create.

#Content

#

Core Concepts

A tenant is the dedicated, isolated directory instance that represents one organisation in Microsoft Entra ID. Users and groups live inside that tenant, and groups let an administrator manage many identities as a single, named unit rather than one at a time. A security group used for access control should have a narrow, self-explanatory purpose; a group named for a specific exercise or project is easier to audit than one with a vague name. Conditional Access is the mechanism that evaluates sign-in attempts against a policy’s conditions, such as group membership, and either grants, blocks or restricts access accordingly. Report-only mode is a deliberate safety feature: it records what a policy would have done without actually enforcing it, which is why this guide uses it throughout.

#

The Bounded Workflow

The exercise has three parts. First, create a dedicated security group containing only test identities you control. Second, create a Conditional Access policy scoped exclusively to that group, left in report-only state so no sign-in is actually blocked. Third, generate a sign-in from a test account in the group and read the resulting log entry to confirm the policy evaluated as intended. Because the policy never targets ‘All users’ and never leaves report-only mode during this exercise, the blast radius is contained to identities you deliberately placed inside the lab group.

#

Implementation Steps

After authenticating with the minimum scopes required, create the lab security group and confirm it exists exactly once by querying its display name. Before adding any new policy, list existing Conditional Access policies to check that nothing already governs the lab group in a way that would confuse your results. Create the new policy referencing only the lab group’s object identifier, and leave its state as report-only. Sign in with a test account that is a member of the group, then review the sign-in log for that attempt. The commands and their expected outputs are recorded in this guide’s technical reference so that each step has an observable outcome before you move to the next.

#

Expected Output

A correctly executed exercise produces three pieces of observable evidence: a group query returning exactly one object with the intended display name, a policy list showing the new policy with a report-only state, and a sign-in log entry for the test account showing that policy as evaluated. None of these outcomes require inference; each is a directly observed record. If any of the three is missing or ambiguous, treat the exercise as unvalidated rather than assuming success.

#

Safety and Scope Boundaries

Keep the policy scoped to the lab group for the entire exercise; never widen it to ‘All users’ even temporarily. Confirm a break-glass account is excluded before the policy exists, not after. Treat directory role names and required permissions as environment-specific: confirm the exact roles available in your tenant rather than assuming the names in this guide are current. These boundaries exist because Conditional Access changes affect authentication itself, and an overly broad or misconfigured policy can prevent legitimate sign-in, which is why UNI-024 treats least privilege and residual risk as part of correctness, not as an afterthought.

#

Escalation

Stop and escalate to a tenant administrator with Conditional Access rights if any sign-in outside the lab group is affected, if the policy list shows an unexpected overlapping policy you did not create, or if a command fails with a permission error you cannot immediately explain. Escalation is a normal, expected outcome of careful lab work, not a sign of failure.

#Examples

Consider a lab group named for a specific validation cycle, containing two or three test accounts created solely for this exercise. A Conditional Access policy scoped to that group, in report-only mode, requiring multi-factor authentication, lets you observe how the policy would have behaved without ever restricting a real sign-in. Reviewing the resulting log entry shows the policy’s report-only result alongside the conditions it evaluated, giving you a concrete, inspectable example of policy logic rather than a theoretical description.

#Exercises

First, repeat the workflow using a second, differently scoped policy condition, such as requiring a compliant device instead of multi-factor authentication, and compare the resulting log evidence. Second, deliberately misname the group during creation, notice the mismatch when you query it by the intended display name, and correct it before proceeding, treating the correction itself as a validation step. Third, once you are confident in the evidence, perform the full rollback described later in this guide and confirm through a fresh query that no lab artefacts remain.

#Validation Guidance

Validation in this exercise means comparing what you observed against what you expected at each of the three stages: group creation, policy creation, and sign-in evaluation. A single, uniquely named group returned by a filtered query is a pass condition for stage one. A policy listed with a report-only state and a scope limited to the lab group is a pass condition for stage two. A sign-in log entry showing that policy evaluated against the test account, without evidence of accounts outside the lab group being affected, is a pass condition for stage three. If any stage fails, resolve it before proceeding rather than layering further changes on unconfirmed evidence.

#Common Mistakes

• Scoping the Conditional Access policy to ‘All users’ instead of the lab group, which removes the safety boundary this exercise depends on.
• Moving a policy out of report-only mode before reviewing any sign-in evidence.
• Forgetting to exclude a break-glass account before a policy exists.
• Assuming a group was created successfully without querying it, particularly after a retried command.
• Deleting the lab group while a Conditional Access policy still references it, rather than removing the policy first.

#Key Takeaways

The rollback boundary for this exercise is fixed and small: disable or delete the Conditional Access policy, delete the lab security group, and re-query both to confirm the tenant matches its pre-exercise state. Treat that boundary as non-negotiable regardless of how the exercise goes. Once you can reliably produce and validate the three pieces of evidence described above, in a tenant you are permitted to change, the safe next decision is to extend the same pattern to one additional, still-bounded condition rather than expanding scope, permissions or population all at once. Any step beyond this lab, including work against a shared or production tenant, should go through your organisation’s change management process rather than being attempted as a personal extension of this exercise.