Make access drift in your tenant, then try to explain it

Setup

This lab starts the Identity governance track. Lab Photos plays an organization with staff: Ava Archer works in print support and is about to move to photo moderation, Cora Diaz already works in moderation, and Ben Okafor answers the help desk. The three groups you create here stand in for the lesson's unit groups and are reused by later governance labs.

1. If you want a clean start, reset the lab tenant with the Lab Photos preset (Overview > Reset tenant). Audit and Logs are preserved by default. The preset creates Ava, Ben and Cora.

2. In User Management > Users, confirm that [email protected], [email protected] and [email protected] exist. Use Set password to give Ben a password and keep it in your password manager. You sign in as Ben in a browser later.

3. In User Management > Groups, create three groups:

   • Print support, the team Ava works in today (the lesson's pediatrics access)

   • Photo moderation, the team Ava is moving to (the lesson's oncology access)

   • Print incident reviews, a review group Ava joined while in print support (the lesson's incident reviews folder)

4. Add Ava to Print support and Print incident reviews. Add Cora to Photo moderation.

5. Create the user [email protected] (first name Test, last name Account) and add it to Photo moderation. Do not write down why. This is the account nobody remembers creating.

6. Note your tenant's address from Overview, such as https://tenant-<id>.beyondthelogin.dev. The steps write it as $ISSUER.

7. On the lab page, choose Lab Photos as the lab tenant and press Start.

Walkthrough

1. The transfer. Ava moves to photo moderation. Add Ava to Photo moderation and do nothing else. Open Ava's row on Users or each group's Members: Ava now belongs to all three groups.

Why it matters: this is "How access drifts". Missing access produces a phone call within the hour. Extra access produces silence, so nothing prompts anyone to remove the print support groups.

2. The auditor's question, first half. Open Photo moderation > Members. You see Cora, Ava and Test Account.

Why it matters: the system answers "who" instantly, as Jordan could in "A question nobody can answer".

3. The auditor's question, second half. Copy the group's ID from the Groups page. Open Audit, choose the Source User directory, paste the ID into Search and run it. Each membership change appears as tenant.groups.members (Group members changed) with outcome succeeded, your account as actor, a time and a count of members added. Open one event's detail.

Why it matters: the record proves who changed the group and when. It holds no reason, no approver and no end date, because nothing in the tenant asked for them.

4. Write Ava's access next to its reason. Fill this table from the Groups page and Audit, the way the lesson does for Sam:

Why it matters: only one row has a current reason, and no row says when it should end. Each grant was an event, and no event ever took anything away.

5. Find the decision behind the test account. On Users, open Test Account's details and copy its User ID. Search Audit for it. You find tenant.users.create and tenant.groups.members, both by you.

Why it matters: the account exists and the record says who made it, yet nobody can say whether it should exist. An account like this is something to investigate, which the orphaned accounts lab does.

6. Give the help desk the power to change groups. In User Management > Roles, create a management role Help desk with tenant.users.read, tenant.groups.read and tenant.groups.update. On Users, open Ben's Management roles action and assign Help desk. Audit now shows tenant.roles.create and tenant.users.management_roles.assign.

Why it matters: this is "Administration and governance". You have arranged the administration half. Nothing yet decides who should get what, so whoever answers the phone will decide.

7. Sign in as the help desk. In a private window, open $ISSUER/manage and sign in as Ben. Ben sees only the pages his role allows. Open Groups and add Ben himself to Photo moderation. It succeeds, and Audit shows tenant.groups.members with Ben's tenant user ID as actor.

Why it matters: this is "Who decides". Nothing stopped Ben granting access to Ben. When the person who can make a change also decides it, the record shows only that the change happened.

Break it

1. Still signed in as Ben, look for Lock on Cora and for the Roles page. Neither is offered, because Help desk lacks those permissions. Hidden controls are not the protection, so test the server.

2. As Ben, open Photo moderation > Members and leave the dialog open. In your own window, remove tenant.groups.update from Help desk and save.

3. As Ben, remove yourself from the group in the dialog that is still open and save. The tenant refuses with access_denied, and Audit records tenant.groups.members with outcome rejected and Ben as actor. Permissions are evaluated on every request against current assignments, not when the page loaded.

Restore: in your own window, add tenant.groups.update back to Help desk and save. Audit records tenant.roles.update.

Check your work

Press Check my progress. The checks look for, in order:

• tenant.groups.members succeeded (step 1)

• tenant.roles.create succeeded (step 6)

• tenant.users.management_roles.assign succeeded for Ben (step 6)

• tenant.groups.members succeeded after the assignment (step 7, Ben adds himself)

• tenant.groups.members rejected with access_denied (Break it)

• tenant.roles.update succeeded after the refusal (the Restore)

Also check your table from step 4: at least two rows should say "No".

Cleanup

1. As yourself, remove Ben from Photo moderation.

2. Delete [email protected]. Its history stays in Audit.

3. Keep the three groups, Ava's three memberships and the Help desk role. Later governance labs start from this drift.