A Practical First Workflow for Identity and Access Management with Microsoft Entra ID

Identity and access management (IAM) is the discipline of proving who is requesting access to a system and then deciding, consistently and verifiably, what that identity is permitted to do next. Microsoft Entra ID

is Microsoft’s cloud-based identity and access product, and Microsoft Learn describes the broader Microsoft Entra family as the identity and network access product set used to secure access to an organisation’s resources. For a graduate or early-career practitioner, the discipline matters more than any single product: every access decision rests on a directory of identities, a set of rules about what those identities can reach, and evidence that the rules behaved as intended.

This guide builds one bounded IAM workflow in Microsoft Entra ID: creating a pilot security group, attaching a Conditional Access policy to that group in report-only mode, and reading the resulting sign-in evidence before any access behaviour is actually enforced. The workflow is deliberately narrow so that every step has an observable outcome you can inspect, roll back and explain. It assumes you are working in an isolated or non-production Microsoft Entra ID tenant, that you have confirmed your assigned administrative role and the tenant’s licence tier before making any change, and that no real user, production credential or production data is involved at any stage.

#Learning Objectives

• Explain, in first-principles terms, how a tenant, directory, identity and group relate to an access decision.
• Identify the trust boundaries and data flow between a sign-in, Conditional Access evaluation and resource access.
• Build a bounded, reversible pilot using a security group and a report-only Conditional Access policy.
• Interpret sign-in and policy evidence to validate whether the workflow behaved as designed.
• Recognise common configuration mistakes and know when to stop rather than proceed.

#Prerequisites

• Access to an isolated or non-production Microsoft Entra ID tenant, not a production directory.
• Confirmation of the current Microsoft Entra ID licence tier and your assigned administrative role before applying any change.
• A basic understanding of what a directory, a user account and a group are in any identity system.
• Comfort running PowerShell commands interactively and reading structured command output.

#Content

#

What Identity and Access Management Actually Verifies

Identity and access management rests on two separable questions that are easy to blur together. Authentication answers ‘is this the identity it claims to be?’, typically through a password, a certificate or a multifactor challenge. Authorisation answers a different question: given that this is who they claim to be, what is this identity allowed to do right now? Microsoft Entra ID separates these concerns deliberately. A successful sign-in produces a token, but conditions attached to that sign-in, such as device, network location or group membership, can still change what the token is allowed to do. Treating authentication and authorisation as one step is a common early mistake, because it hides where a control such as Conditional Access actually intervenes.

#

Core Microsoft Entra ID Components and Dependencies

A Microsoft Entra ID tenant is a boundaried instance of the directory: every user, group and policy in this guide lives inside one tenant and does not automatically apply to any other. Users and groups are directory objects; a group used correctly is not just a distribution list but a reusable scope that other objects, such as a Conditional Access policy, can point at instead of naming individuals one by one. Application registrations and their service principals represent software requesting access on behalf of a user or itself, a distinct kind of identity worth naming even though this guide does not configure one. Roles determine what an identity may administer, and Microsoft Entra ID directory roles are not the same system as Azure resource role-based access control, a distinction shown below.

Confirm the current minimum administrative role required to manage Conditional Access policies against Microsoft Learn’s role reference before relying on this guide’s role name, because minimum role requirements have been revised between releases.

#

Trust Boundaries and Data Flow

Three trust boundaries matter for this workflow. The tenant boundary keeps this pilot’s objects out of any other directory. The administrative role boundary limits who can create or change a Conditional Access policy, which is why confirming your assigned role before starting is a prerequisite rather than a formality. The policy scope boundary is the one most often crossed by accident: a Conditional Access policy’s include and exclude conditions define exactly which users, groups, applications and locations it evaluates, and an unbounded scope such as ‘All users’ turns a pilot into an organisation-wide change. Data flow follows the same order every time: a sign-in is authenticated, the token request is evaluated against every applicable Conditional Access policy, each policy’s decision, or in report-only mode its would-be decision, is written to the sign-in log, and only afterwards is a token issued or refused. Reading the sign-in log after evaluation, not before, is what gives you real evidence instead of an assumption.

#Examples

The worked example builds the pilot described in this guide’s opening and interprets the evidence at each step, using the Microsoft Graph PowerShell SDK against a non-production tenant. Step one connects to Microsoft Graph with only the scopes this workflow needs. The output is an interactive sign-in prompt followed by confirmation of the granted scopes; if the confirmed scopes are narrower than requested, your account’s role does not hold sufficient privilege, and you should stop before continuing. Step two runs an inventory command against every existing Conditional Access policy. The output is a list of policy objects, each with a DisplayName and a State such as enabled, disabled or enabledForReportingButNotEnforced. Read this list before creating anything new; a broad existing policy that already covers your test account can make the pilot’s evidence misleading. Step three creates the pilot security group. The output is a new group object containing an Id and the DisplayName IAM-Lab-Pilot-Group; this Id is the value every later step, including rollback, refers back to, so record it. Step four creates the pilot Conditional Access policy, scoped only to the pilot group’s Id, requiring multifactor authentication, and set explicitly to enabledForReportingButNotEnforced. The State field in that returned object is the single most important piece of evidence here, because it confirms the policy cannot yet enforce anything even if every other setting were wrong. Step five, after a test sign-in from an account that is a member of the pilot group, opens that sign-in’s entry in the sign-in logs and reads the Conditional Access detail. The evidence is a report-only result, typically shown as would have succeeded, would have failed or not applied, attributed to the pilot policy by name. A result that is present, correctly attributed and consistent with requiring multifactor authentication is the pass condition for the whole example; an absent or misattributed result means the scope, membership or policy state needs re-checking before you trust anything else.

#Exercises

#

Exercise: Build and Interpret a Report-Only Conditional Access Pilot

Objective: reproduce the worked example independently and produce your own sign-in evidence, in a non-production tenant, without enforcing any access change.

Setup: confirm you are in an isolated or non-production tenant; confirm your assigned role and licence tier; identify one test user account you are permitted to use that is not a shared or production identity.

1. Connect to Microsoft Graph with the scopes listed in the worked example and confirm the granted scopes match what was requested.
2. Inventory existing Conditional Access policies and note any that already include your test account or an ‘All users’ scope.
3. Create the pilot security group and add only the test account as a member.
4. Create the pilot Conditional Access policy, scoped only to the pilot group, in report-only mode, requiring multifactor authentication.
5. Sign in as the test account, then locate that sign-in in the sign-in logs and read the Conditional Access report-only result.

Expected evidence: a returned policy object with State equal to enabledForReportingButNotEnforced, and a sign-in log entry showing a report-only result attributed to the pilot policy.

Pass condition: the report-only result is present, attributed to the pilot policy, and consistent with a multifactor authentication requirement for the test account only.

Stop conditions: stop immediately and roll back if the policy’s State is anything other than enabledForReportingButNotEnforced, if its scope includes more than the pilot group, or if any account outside the intended test account is affected.

Cleanup: remove the pilot Conditional Access policy, remove the pilot security group, confirm both no longer appear in their respective inventories, then disconnect the Microsoft Graph session.

#Validation Guidance

• Re-read the pilot policy’s State field directly from the policy inventory command rather than trusting a script’s success message alone.
• Confirm the pilot group’s membership list matches exactly the accounts you intended to include, no more and no fewer.
• Cross-check the sign-in log’s report-only result against the multifactor requirement you configured, not just its presence.
• Repeat the test sign-in more than once, ideally at different times, before treating a single clean result as representative.

#Common Mistakes

• Scoping the pilot policy to ‘All users’ or ‘All cloud apps’ instead of the pilot group, which converts a bounded test into a tenant-wide change.
• Treating a clean report-only result as proof that access is already protected, when report-only mode enforces nothing.
• Generating test evidence from the administrator account that created the policy, which is often excluded or treated differently from an ordinary user.
• Skipping the pre-change policy inventory, so the pilot’s evidence is confused by an existing, overlapping policy.

#Warnings and Safety Considerations

This guide assumes an isolated or non-production tenant because the assignment for this guide did not specify organisational safety controls, and that assumption is made explicit here rather than left implicit. Conditional Access is a tenant-wide control surface: a policy that is correctly built but incorrectly scoped can still affect every user in a tenant the moment its State changes from report-only to enabled. Treat the group-scoping step as the single highest-risk decision in this workflow, confirm it twice, and never widen a pilot’s scope inside a production tenant without a change process, an exclusion for break-glass accounts, and a rollback plan already agreed.

#Production Bridge

Moving this workflow into a production tenant changes what is at stake without changing the mental model. The administrative role you use should be the minimum role that can complete the task, ideally activated just-in-time through Privileged Identity Management rather than held permanently. Before enabling any policy beyond report-only mode, confirm that at least one break-glass account is excluded from the policy’s scope and is not a member of the pilot group, so a misconfiguration cannot lock every administrator out simultaneously. Escalation in production means pausing, not guessing: if report-only evidence is ambiguous, if the policy inventory shows an unexpected overlap, or if any sign-in log entry is not fully understood, the correct action is to leave the policy in report-only mode and raise it with the tenant’s identity administration team before making any further change. The skill that transfers from this bounded lab exercise to production work is not the specific cmdlet syntax, which changes between SDK versions, but the sequence itself: inventory first, scope narrowly, prove with report-only evidence, and only then enforce.

#Key Takeaways

• Authentication proves who is asking; Conditional Access and authorisation decide what that identity may still do, and the two should never be treated as one step.
• A Conditional Access policy’s scope, not just its grant controls, is the boundary most likely to turn a safe pilot into an unsafe change.
• Report-only mode produces evidence without enforcing anything, and that evidence is only trustworthy once you have confirmed group membership, policy State and log attribution together.
• Every state-changing step in this workflow has a matching rollback step, and cleanup is not optional once the exercise is complete.

Once your report-only evidence for the pilot group looks the way you expect, across more than one sign-in, the next safe decision is to keep the same narrow group scope, move the policy’s State from report-only to enabled for that group alone, and repeat the same sign-in evidence check before considering any wider rollout. If evidence is missing, inconsistent or attributed to the wrong policy, the correct action is to leave the policy in report-only mode, or remove it using the rollback steps above, rather than proceeding on assumption.