Lab 02 — Microsoft Entra Identity Lifecycle: Users, Groups, and SSPR Readiness

azure administrator series

Download Lab 02 scripts and workshop

ZIP SHA-256: 04212c1da5eaa3d7d448e4efa20cd623422290188c338b71350753b77ddaf1b2

Validation: baseline, fault, recovery, repeated recovery, and cleanup passed. Licensing changes, guest redemption, and SSPR reset remain guided and not live-tested.

Two employees appear in the directory. Both profiles look correct. Yet the onboarding group contains only one of them. Can you find the missing membership, restore it safely, and prove that nothing else changed?

This workshop continues the azure administrator series, a sequence of practical labs aligned with Microsoft Azure Administrator (AZ-104). It combines Azure CLI, Microsoft Graph PowerShell, and visual checkpoints in the Microsoft Entra admin center.

Previous: Lab 01 — Scoped Azure RBAC. Workshop index: Azure Workshopz.

What you will build

Create two fictional cloud-only users, Avery and Jordan, and an assigned-membership security group. Populate the group, establish a baseline, deliberately remove Jordan, diagnose the difference, and restore only the missing membership.

Both accounts remain disabled throughout. They receive no Azure roles, directory roles, application assignments, or licenses. The group is not mail-enabled, dynamic, or role-assignable. This is an administrative membership validation failure, not an application-access or sign-in demonstration.

The package contains the walkthrough, stage scripts, challenge, progressive hints, separate solution, eight knowledge checks with explanations, sanitized evidence, and a validation report. Keep the private run manifest outside this package.

AZ-104 alignment and honest boundaries

The AZ-104 study guide includes managing Entra users and groups, user properties, licensing, external users, and SSPR under identity and governance. This lab practices the first three identity-administration activities directly and introduces the remaining areas with guided exercises. It is independent training material, not an official Microsoft course or a promise of complete exam coverage.

Area	This release
Cloud-only users and fictional profile properties	Live creation, inspection, and cleanup
Assigned security-group membership	Live baseline, fault, recovery, repeat recovery
License inventory	Read-only inventory; no subscribed SKUs returned
License assignment and removal	Guided examples only — not live-tested
External-user invitation and redemption	Guided walkthrough only — not live-tested; no invitations sent
SSPR	Readiness inspection only — no reset or policy change; not live-tested end to end

Plan 60–90 minutes including reading, portal checkpoints, and cleanup. No Azure compute or paid service is deployed. Do not activate trials or purchase licenses to complete this release.

Safety and prerequisites

Use an administrator-controlled disposable training environment. Even disabled users can trigger external workflows. Preflight reads every group-inventory page and refuses to proceed if it finds dynamic membership or group licensing. The tenant owner must separately review external provisioning/onboarding automation that Graph cannot comprehensively discover.

Use Windows with PowerShell 7.2 or newer and current Azure CLI. This release was validated with an existing active Global Administrator session; Global Administrator is powerful and is not a blanket recommendation for daily administration. A narrower role combination needs its own validation before substituting it.

Install only the required official modules from PowerShell Gallery:

Install-Module Microsoft.Graph.Authentication,Microsoft.Graph.Users,Microsoft.Graph.Groups `
  -Scope CurrentUser -Repository PSGallery

Sign in to the intended tenant using Azure CLI yourself. Review az account show locally. Never publish its raw output. The stage scripts reuse the existing CLI Graph token in memory with Connect-MgGraph -AccessToken; they do not request new consent, register an application, or write a token to disk. If existing consent is insufficient, stop and have the tenant administrator review permissions. Do not grant broad consent just to suppress an error. Microsoft documents this Graph PowerShell authentication option.

Do not run PowerShell transcription, verbose HTTP tracing, az --debug, or screen recording during user creation. Initial passwords are cryptographically generated in process memory and discarded. They are never displayed, passed to a native command, or exported. The users remain disabled; there is no learner sign-in step.

Stage 1 — Establish the tenant and private state

Extract the ZIP. Open PowerShell 7 in the extracted lab folder. Select the intended subscription/tenant before obtaining $tenant. Confirm it matches your intended directory, not merely whichever session happened to be active.

$tenant = az account show --query tenantId -o tsv
$private = Join-Path $env:LOCALAPPDATA ('Workshopz-Lab02-' + [guid]::NewGuid().ToString('N'))
./Initialize-Lab02StateDirectory.ps1 -Path $private -Execute
$state = Join-Path $private 'state.json'
./Start-Az104Lab02.ps1 -Stage Preflight -TenantId $tenant -StatePath $state

The state-directory initializer creates a new directory restricted to the current Windows user and SYSTEM. It refuses to replace an existing directory's permissions. Every stage takes an exclusive file lock; a second process must fail rather than race the first. The lock file can remain after completion; the open file handle, not its mere presence, is the lock.

Preflight does not create identities, request consent, or change policies. It checks context, existing scopes, modules, a verified managed domain, administrator role, group automation risks, and SKU inventory. Zero SKUs is an observation, not permission to start a trial.

Stage 2 — Create the healthy baseline

After the tenant owner confirms no conflicting external automation, preview and execute:

./Start-Az104Lab02.ps1 -Stage Deploy -TenantId $tenant -StatePath $state
./Start-Az104Lab02.ps1 -Stage Deploy -TenantId $tenant -StatePath $state `
  -AutomationReviewed -Execute
./Test-Az104Lab02.ps1 -StatePath $state -Phase Baseline

Setup uses az ad group create --force true with a fresh run suffix. That explicit flag avoids the CLI's default create-or-update behavior. It immediately records the returned group object ID. Graph PowerShell uses New-MgUser, Update-MgUser, and New-MgGroupMemberByRef. The scripts store returned IDs after each successful creation and never adopt a matching name.

Expected baseline: two active directory objects, both with sign-in disabled, fictional department/job/office properties, and exactly two group memberships. “Active object” means not deleted; it does not mean sign-in is enabled.

For private inspection, load the manifest locally:

$run = Get-Content -LiteralPath $state -Raw | ConvertFrom-Json
az ad group member list --group $run.Group.Id --query '[].displayName' -o table

Do not publish the manifest, tenant domain, UPNs, or object IDs. The evidence exporter deliberately excludes them.

Portal checkpoint: healthy membership and user properties

Open Microsoft Entra admin center. Check the account menu's active directory against the CLI context before navigating. Go to Entra ID → Groups → All groups; search the exact group name recorded in the manifest, open it, and inspect Members. Both fictional users should be present.

Open each user through Entra ID → Users. Inspect Properties: the account is disabled, user type is Member, and the fictional profile fields match. Do not toggle account status or assign roles. Capture only relevant lab content; exclude account headers and identifiers from published screenshots.

Stage 3 — Introduce and diagnose the membership discrepancy

./Set-Az104Lab02Fault.ps1 -StatePath $state
./Set-Az104Lab02Fault.ps1 -StatePath $state -Execute
./Test-Az104Lab02.ps1 -StatePath $state -Phase Fault

The fault script calls az ad group member remove using the two recorded object IDs. It removes Jordan's membership reference; it does not delete Jordan. Refresh the Members page: Avery remains; Jordan is absent. Inspect both profiles again. Their selected properties must remain unchanged.

The Fault validation should pass because the intended faulty state has been reproduced precisely. Baseline validation at this point should fail. These are different assertions, not contradictory results.

Challenge yourself before opening the solution: can you prove whether the missing entity is a user, a membership, or the group itself? What evidence rules out a disabled-account change as the cause? The accounts were already disabled at baseline, so disabled sign-in is not the injected failure.

Stage 4 — Restore only the missing reference

./Restore-Az104Lab02.ps1 -StatePath $state
./Restore-Az104Lab02.ps1 -StatePath $state -Execute
./Test-Az104Lab02.ps1 -StatePath $state -Phase Recovery
./Restore-Az104Lab02.ps1 -StatePath $state -Execute
./Test-Az104Lab02.ps1 -StatePath $state -Phase Recovery

Recovery reads the current membership before using Graph PowerShell to add Jordan by reference. If Jordan is already present, it makes no duplicate addition. Refresh the portal and confirm two members. The exact membership count and unchanged profile checks are stronger evidence than a command returning without an error.

If using raw Graph in your own future automation, distinguish deleting a reference from deleting an object. Microsoft warns that omitting /$ref from a member-removal request can delete the directory object when the caller has sufficient permissions. This lab uses the supported CLI membership command. See Remove member.

Stage 5 — Read-only licensing checkpoint

In the Entra admin center, inspect the lab user's Licenses page and the tenant license inventory. Assignment management may direct you to the Microsoft 365 admin center. Do not use purchase, trial, assignment, or save controls in this release.

The live tenant returned no subscribed license SKUs. A separately licensed training environment would first require a valid usage location, an available SKU, compatible service plans, and appropriate consent/administrator permissions. Review the assignment source: direct and group-derived assignments have different removal paths. A removal of a direct assignment does not necessarily remove entitlement inherited from another source.

Illustrative Graph v1.0 request shapes, not executed and not live-tested here:

POST /v1.0/users/{approved-training-user-id}/assignLicense
Assign: {"addLicenses":[{"skuId":"{available-sku-id}"}],"removeLicenses":[]}
Remove direct assignment: {"addLicenses":[],"removeLicenses":["{same-sku-id}"]}

These are study examples, not another stage script. Do not substitute real employees or experiment with service removal in production. See Microsoft's license assignment guidance.

Stage 6 — External users: guided only, not live-tested

Walk through the decision process without sending an invitation. In a separately approved guest-collaboration exercise, an administrator would review external collaboration restrictions, select Users → New user → Invite external user, supply an approved recipient and business justification, and send the invitation only with authorization.

The recipient would redeem it using the supported identity flow. An administrator would then inspect the guest object's external-user state and verify the intended resource assignment separately. A Guest user type alone does not prove invitation redemption; redemption alone does not grant arbitrary resource access. Our two disabled Member objects are not substitutes for that test.

For this release, do not enter an actual recipient, send an invitation, redeem a link, or assign guest access. Study B2B guest user properties, including the distinction between user type and external-user state.

Stage 7 — SSPR readiness, not a password-reset test

Use Entra ID → Password reset for visual inspection only. Do not save policy changes. The readiness checklist is:

1. Is the intended scenario password change, forgotten-password reset, account unlock, or hybrid writeback?

2. Does each intended beneficiary have an eligible license for that scenario?

3. Does the existing policy include the intended population?

4. Are required authentication methods allowed and registered?

5. Are administrative accounts subject to additional requirements?

6. For hybrid identities, is writeback supported and configured appropriately?

7. Are support contacts, notifications, audit visibility, and rollback arrangements ready?

The existence of the Password reset page is not evidence that reset is licensed or operational. Microsoft's SSPR licensing matrix differentiates password change, cloud reset, and hybrid writeback. This tenant had no subscribed SKUs in the checked inventory. This release does not change authentication methods, MFA, Conditional Access, or existing reset policies; it performs no password reset or registration flow.

Stage 8 — Prove the safety controls

./Test-Az104Lab02Safety.ps1 -StatePath $state

The non-mutating negative tests exercise wrong-tenant rejection, an in-memory ownership mismatch, and real exclusive-lock contention. Interrupted-create and interrupted-recovery journal states are simulated; they are not claims of killing a process during a live Graph request.

An interrupted membership operation can be rerun because it rereads current membership. An uncertain create is different: Graph might have created the object before the client lost the response. The script leaves a pending-create marker and stops. An administrator must inspect audit logs and reconcile the exact object ID privately before proceeding. Never rerun blindly, search by prefix and adopt, or bulk-delete similarly named objects. A local manifest cannot make a remote create and a local file write one atomic transaction.

Safety checks stop on unexpected licenses, roles, non-lab memberships, or application assignments. They do not remove unrelated grants to manufacture a passing result. Azure role checks cover the selected subscription's visible assignments, not every possible external system. Avoid concurrent manual or automated changes to these objects.

Stage 9 — Cleanup and evidence

./Remove-Az104Lab02.ps1 -StatePath $state
./Remove-Az104Lab02.ps1 -StatePath $state -Execute
./Remove-Az104Lab02.ps1 -StatePath $state -Execute
./Get-Az104Lab02Evidence.ps1 -StatePath $state `
  -OutputPath ./evidence/my-sanitized-results.json -Execute

Cleanup targets only recorded IDs after ownership checks. It verifies zero active lab users and no active lab group. Deleted-user records are reported separately, not mislabeled as active leftovers. Users are soft-deleted and ordinarily recoverable for 30 days; the scripts never permanently purge them. The disposable assigned-membership security group is permanently deleted and is not recoverable like a Microsoft 365 group. See Microsoft's user deletion and group deletion documentation.

Keep the private manifest until cleanup and any uncertain-operation reconciliation are complete. Do not include it in your own shared ZIP. The provided evidence is an allowlisted summary, not a complete directory audit.

Knowledge check

1. Why can an Azure subscription Owner still need separate Entra permissions?

2. Why does this lab keep both users disabled?

3. What proves this is a missing-membership fault rather than a deleted-user fault?

4. Why use object IDs rather than display-name prefixes for recovery and cleanup?

5. Why inspect membership before adding the reference during recovery?

6. Why does seeing an SSPR configuration page not prove readiness?

7. What is the difference between Guest user type and invitation redemption state?

8. What remains after cleanup, and which lab deletion cannot be undone normally?

Open knowledge-check/answers.md in the download after answering. The challenge solution is also separate so you can attempt diagnosis first.

The operational lesson: a directory object existing is not the same as its intended relationships being correct. Establish the expected state, compare exact objects, repair the smallest discrepancy, and validate both recovery and cleanup.

Next: Lab 03 — Azure Governance Guardrails and Cost Control