I6.8 Identity and Access Management Lab
Integrate fictional accounts, authentication, authorization, permissions, privileged access, lifecycle, sessions, ownership, monitoring, findings, remediation, validation, and residual risk into one professional Identity and Access Review Report.
Lesson Progress
Identity and Access Management Lab
High School Intermediate • I6: Identity and Access Management • Lesson 8 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Strong IAM Review Explains the Whole Access Story
A role list alone does not show effective access. A sign-in alone does not prove the physical person. A disabled account alone does not prove every session ended. A completed change alone does not prove the business workflow still works. This lab connects all available evidence into one traceable defensive report.
Weak report
“Several accounts look risky. Remove access and close the tickets.”
Strong report
“Connect each finding to evidence, owner, approved state, current state, impact, priority, narrow correction, rollback, validation, monitoring, and residual risk.”
Objective 1
Integrate fictional identity, authentication, authorization, role, permission, lifecycle, privileged-access, and monitoring evidence into one defensible review.
Objective 2
Separate confirmed facts, reasonable conclusions, alternative explanations, tool interpretations, business context, and evidence gaps.
Objective 3
Prioritize fictional identity findings using access scope, resource sensitivity, privilege, duration, owner, session state, and business impact.
Objective 4
Design narrow owner-approved remediation with rollback, positive tests, negative tests, session validation, monitoring, and closure criteria.
Objective 5
Create a portfolio-ready fictional Identity and Access Review Report that is traceable, professional, privacy-preserving, and evidence based.
Why This Matters
Identity Controls Depend on One Another
Authentication can be strong while authorization is excessive. Least privilege can be correct while a remembered session remains active. A mover workflow can add the correct role while retaining an old local permission. Monitoring can identify a real pattern but omit the owner-approved lifecycle context. Integrated analysis prevents one control from hiding another control’s weakness.
Evidence Packets
Eight Packets for the Integrated Lab
Packet A: Identity inventory
Fictional account identifiers, account types, owners, managers, departments, service purposes, creation dates, expiration dates, status, and last review.
Review question
Which accounts are active, temporary, dormant, privileged, service based, shared, emergency, duplicated, or unowned?
Packet B: Authentication evidence
Fictional password results, MFA challenges, factor changes, device trust, sign-in policy, recovery, remembered sessions, and step-up events.
Review question
Which authentication events meet the required assurance, and which require more evidence?
Packet C: Authorization evidence
Fictional direct permissions, groups, nested groups, roles, resource shares, application-local roles, attributes, policies, and access decisions.
Review question
What is the effective access for each important identity-resource-action combination?
Packet D: Privileged-access evidence
Fictional privileged requests, approvals, administrative accounts, devices, MFA, role activations, sessions, actions, targets, expiration, and post-use review.
Review question
Is privilege narrow, time limited, independently approved, monitored, and completely removed after use?
Packet E: Lifecycle evidence
Fictional joiner, mover, leaver, temporary-access, suspension, reactivation, ownership-transfer, recertification, and deprovisioning events.
Review question
Does the current technical state match the approved lifecycle state across every system?
Packet F: Monitoring evidence
Fictional alerts, raw events, timestamps, correlation IDs, sessions, devices, role changes, application actions, source-health records, analyst notes, and owner confirmation.
Review question
Which alerts represent expected activity, correct policy enforcement, false positives, suspicious patterns, confirmed issues, or evidence gaps?
Packet G: Business evidence
Fictional job functions, application owners, resource owners, project dates, service dependencies, approvals, support records, expected workflows, and sensitivity labels.
Review question
Which technical access paths are still required for a current approved purpose?
Packet H: Validation evidence
Fictional positive tests, negative tests, session refresh, role expiration, application-local cleanup, service health, owner acceptance, monitoring, and closure records.
Review question
Did the correction preserve required work, remove unnecessary access, and remain effective after sessions and applications refreshed?
Review Domains
Six Domains That Must Be Reviewed Together
Identity and account ownership
Review questions
Does every fictional user, service, application, privileged, emergency, temporary, shared, and dormant account have a valid purpose and accountable owner?
Evidence
Inventory, sponsor, manager, service owner, application owner, lifecycle record, and recertification decision.
Common findings
Orphaned service accounts, shared identities, duplicate accounts, dormant access, missing sponsors, and stale ownership.
Authentication assurance
Review questions
Do fictional factors, devices, sessions, recovery, remembered access, and step-up requirements match account and resource sensitivity?
Evidence
Sign-in logs, MFA, factor registration, recovery, device records, session state, policy result, and owner confirmation.
Common findings
Weak recovery, unexpected MFA, stale registered devices, remembered sessions, and incomplete post-reset session cleanup.
Authorization and effective access
Review questions
Do fictional roles, groups, direct grants, nested groups, resource shares, application-local permissions, and policy conditions match approved need?
Evidence
Role catalog, group membership, permission records, access requests, application decisions, resource owners, and policy logs.
Common findings
Excessive direct grants, inherited access, local-role gaps, stale project permissions, conflicting policies, and missing attributes.
Privileged access
Review questions
Are fictional administrative identities separate, named, narrowly scoped, time limited, independently approved, monitored, and fully de-elevated?
Evidence
Request, approval, administrative account, device, MFA, role activation, session, action, target, expiration, and post-use review.
Common findings
Standing privilege, shared administration, self-approval, broad service privilege, unowned emergency accounts, and stale sessions.
Account lifecycle
Review questions
Do fictional joiner, mover, leaver, temporary, suspension, reactivation, and ownership changes update every account, role, session, device, application, and resource?
Evidence
Lifecycle event, approvals, directory changes, local application changes, session actions, resource transfer, and owner validation.
Common findings
Privilege accumulation, missed expiration, local-access remnants, unrevoked sessions, dormant accounts, and incomplete ownership transfer.
Monitoring and evidence quality
Review questions
Are fictional identity events complete, timely, correlated, understandable, retained, routed to owners, and tied to clear case decisions?
Evidence
Source health, event IDs, timestamps, correlation values, alerts, analyst notes, owner reports, validation, and closure.
Common findings
Missing application logs, stale baselines, incomplete IDs, unowned alerts, delayed ingestion, and unsupported conclusions.
Core Concept
Compare Approved State, Current State, and Proven Final State
Approved state
Which fictional identity, account, role, action, resource, device, duration, owner, and purpose should exist?
Current state
Which authentication, permissions, sessions, factors, applications, resources, and ownership relationships actually exist?
Difference
Which access is excessive, stale, missing, unowned, inherited, local, privileged, or evidence incomplete?
Correction
Which narrow owner-approved change fixes the difference without breaking required work?
Proven final state
Which positive, negative, session, factor, resource, monitoring, and owner evidence supports closure?
Integrated Findings
Eight Findings with Owners and Narrow Recommendations
Orphaned legacy service account
Evidence
Fictional service account svc-report-old retains read access to a retired reporting endpoint. No current application team claims ownership, and the last approved review is eleven months old.
Impact
A non-human identity remains usable without accountable ownership, current dependency evidence, or reliable credential and permission lifecycle.
Owner
Identity Governance and Reporting Application Team
Recommendation
Assign an investigation owner, identify dependencies, restrict source use, disable through approved change control, validate reporting, and remove after the observation period.
Mover privilege accumulation
Evidence
Fictional user training-mchen receives analytics-reviewers but retains student-services-editors and one application-local case-editor permission.
Impact
The account can access resources unrelated to the current role and retains an old editing capability.
Owner
Learning Analytics Owner and Student Services Owner
Recommendation
Remove former-role access, refresh sessions, transfer owned resources, validate analytics access, and verify former editing and export actions are denied.
Temporary privileged session outlives role
Evidence
A fictional service-operator role expires at 13:56, but an administrative application session retains privileged claims for two minutes.
Impact
The technical session remains more powerful than the current authorization state during the refresh gap.
Owner
Privileged Access Team and Application Owner
Recommendation
Revoke or refresh sessions automatically at role expiration, test related applications, and monitor de-elevation failures.
Recovery leaves an old factor registered
Evidence
A fictional account completes approved device replacement, but the lost phone remains listed as a valid factor and two remembered sessions remain active.
Impact
Old factor and session paths may continue after the owner believes recovery is complete.
Owner
Identity Support and Account Owner
Recommendation
Remove and verify the old factor, revoke unconfirmed sessions, validate the new factor, review recent sign-ins, and monitor.
Broad report administrator granted for view need
Evidence
A fictional request approves report-view for thirty days, but the implemented role allows view, edit, export, and configuration.
Impact
The account has capabilities beyond the approved business purpose even though no misuse is recorded.
Owner
Reporting Resource Owner
Recommendation
Replace report-admin with report-viewers, refresh sessions, validate report viewing, verify edit and configuration are denied, and confirm expiration.
Restricted child folder inherits broad access
Evidence
A fictional project group is approved for the main workspace but can open a restricted child folder through parent inheritance.
Impact
Resource-level access exceeds the approved boundary.
Owner
Project Resource Owner
Recommendation
Create the approved child-resource restriction, refresh sessions, test main access, verify child denial, and monitor alternate paths.
Dormant account monitoring alert lacks context
Evidence
A fictional dormant account reactivation produces a high-severity alert, but the initial case view omits the approved project request and owner confirmation.
Impact
Analysts may overreact to approved activity or miss that the sensitive export was correctly denied.
Owner
Security Monitoring Team
Recommendation
Add lifecycle and owner context to the alert, preserve the denied-action evidence, tune the baseline carefully, and document classification logic.
Emergency account review is overdue
Evidence
A fictional break-glass account has named owners and alerting but has not completed a scheduled safe test or credential-rotation review.
Impact
The organization cannot confirm that emergency access will work correctly or remain protected when needed.
Owner
Identity Operations Leadership
Recommendation
Conduct an approved safe test, verify alerting and storage, review permissions, rotate authentication material if required, and document results.
Remediation Roadmap
Connect Every Finding to Action, Rollback, and Validation
IAM-01 Orphaned service account
Immediate action
Assign a fictional investigation owner, restrict the account to its known source workload, and preserve current usage and dependency evidence.
Permanent action
Disable through approved change control, observe for service impact, remove the unused permission and identity, and update the service inventory.
Rollback
Re-enable only through documented owner approval if a validated dependency fails during the observation window.
Validation
Confirm approved reports continue, the account cannot authenticate or access the retired endpoint, and no alternate identity depends on the old permission.
IAM-02 Mover privilege accumulation
Immediate action
Preserve old and new access records, remove former department roles and local permissions, and refresh affected sessions.
Permanent action
Add old-state versus new-state comparison to mover workflows and require both former and new resource-owner review.
Rollback
Restore only the exact former permission through a time-limited approved exception if a documented transition task remains.
Validation
Confirm analytics viewing and comments work while former case editing, record export, and project shares are denied.
IAM-03 Privileged session outlives role
Immediate action
Revoke the fictional administrative session when the temporary role expires and preserve role, session, application, and action evidence.
Permanent action
Connect privileged-role expiration to application-session revocation and add a de-elevation monitoring alert.
Rollback
Issue a new narrow elevation through the approved request path rather than restoring the stale session.
Validation
Confirm the approved task completed, the role is absent, old sessions cannot perform privileged actions, and unrelated actions remain denied.
IAM-04 Old factor remains after recovery
Immediate action
Remove the fictional lost-device factor, revoke unconfirmed sessions, and review surrounding sign-ins and recovery records.
Permanent action
Require factor removal and session review as mandatory recovery closure steps.
Rollback
Re-register a factor only after approved owner verification and device validation.
Validation
Confirm the replacement factor works, the old factor cannot authenticate, unconfirmed sessions are invalid, and required applications remain available.
IAM-05 Broad report role
Immediate action
Replace fictional report-admin with report-viewers and refresh the application session.
Permanent action
Add approved-action comparison and negative permission tests to the access-provisioning workflow.
Rollback
Restore only the exact owner-approved action if business validation identifies a missing requirement.
Validation
Confirm report viewing succeeds while editing, export administration, configuration, and role management remain denied.
IAM-06 Unsafe resource inheritance
Immediate action
Apply the approved fictional restriction to the sensitive child folder and refresh affected sessions.
Permanent action
Add inheritance-boundary tests to project workspace creation and access recertification.
Rollback
Restore the prior permission only if the resource owner changes the approved sensitivity boundary through a documented request.
Validation
Confirm the main workspace remains available and the restricted child folder has no direct, inherited, share, local, or session access path.
IAM-07 Monitoring context gap
Immediate action
Attach the fictional lifecycle approval, role, owner confirmation, application denial, and session evidence to the monitoring case.
Permanent action
Enrich dormant-account alerts with current lifecycle, owner, role, and approved-duration context.
Rollback
Return to the prior alert format if enrichment causes ingestion failure while preserving the underlying raw events.
Validation
Confirm analysts can distinguish approved reactivation from correctly denied sensitive actions and that no alert coverage is lost.
IAM-08 Overdue emergency-account review
Immediate action
Assign a fictional test owner and schedule an approved non-disruptive emergency-access validation.
Permanent action
Enforce periodic ownership, storage, permission, alerting, safe-test, rotation, and post-use review requirements.
Rollback
Use the documented secondary recovery path if the emergency account fails the safe test.
Validation
Confirm the account authenticates only under approved conditions, alerts route correctly, permissions are narrow, and review evidence is complete.
Validation Matrix
Eight Ways to Prove the Final State
Required access
Can each fictional identity still complete the exact approved business or service action after remediation?
Fictional example
training-mchen can view and comment on the analytics dashboard.
Evidence
Application decision, session, role, resource, owner confirmation, and expected workflow result.
Removed access
Are fictional old, excessive, privileged, local, inherited, or unrelated actions denied?
Fictional example
training-mchen cannot edit Student Services cases or export student records.
Evidence
Negative application event, effective-access calculation, refreshed session, and owner-approved scope.
Session alignment
Do fictional active and remembered sessions reflect current account, role, factor, device, and lifecycle state?
Fictional example
The expired service-operator role cannot continue through an older administrative session.
Evidence
Session inventory, revocation, refresh, new decision, and denied privileged action.
Factor lifecycle
Do fictional registered factors and recovery methods match current ownership and approved devices?
Fictional example
The lost phone is removed and the approved replacement factor works.
Evidence
Factor inventory, removal record, registration record, owner validation, and sign-in test.
Application-local access
Do fictional local application roles, shares, owners, and permissions match central governance decisions?
Fictional example
The former case-editor permission is removed inside the application.
Evidence
Application role record, local access list, session refresh, denied action, and owner confirmation.
Resource ownership
Do fictional reports, folders, services, groups, applications, and approval queues have current accountable owners?
Fictional example
Student Services reports transfer to the approved successor owner.
Evidence
Before-and-after owner records, successor access, notifications, and original-owner removal.
Monitoring coverage
Do fictional identity, role, factor, session, privilege, application, and lifecycle events reach the expected monitoring and case systems?
Fictional example
Role expiration and privileged-session revocation appear in the monitoring timeline.
Evidence
Source health, ingestion timestamps, event IDs, alert route, case link, and reviewer confirmation.
Business acceptance
Do fictional resource, application, service, identity, and process owners accept the final technical state?
Fictional example
The reporting owner confirms view access works and administrative actions remain unnecessary.
Evidence
Owner statement, workflow test, exception record, due date, residual risk, and closure approval.
Portfolio Report Structure
Eleven Sections for the Final Deliverable
1. Executive summary
Fictional purpose, scope, most important findings, highest priorities, major improvements, unresolved evidence gaps, and residual risk.
2. Scope and safety boundary
Fictional identities, systems, applications, resources, time range, evidence sources, exclusions, privacy protections, and authorized defensive limitations.
3. Identity and account inventory
Fictional user, service, application, privileged, temporary, emergency, shared, dormant, disabled, and orphaned account summary with ownership.
4. Authentication review
Fictional passwords, MFA, factors, devices, recovery, remembered sessions, step-up, assurance findings, and evidence limitations.
5. Authorization review
Fictional roles, groups, direct permissions, inheritance, local access, policies, effective-access examples, and least-privilege findings.
6. Privileged-access review
Fictional administrative identities, standing privilege, temporary elevation, emergency access, separation of duties, sessions, actions, and de-elevation.
7. Lifecycle and access-review findings
Fictional joiner, mover, leaver, temporary, dormant, suspension, ownership, recertification, session, and resource-transfer results.
8. Monitoring and evidence quality
Fictional log sources, timelines, event IDs, correlations, alert classifications, source-health findings, case ownership, and evidence gaps.
9. Prioritized remediation roadmap
Finding ID, priority, owner, immediate action, permanent action, dependency, due date, rollback, validation, and status.
10. Validation and residual risk
Fictional positive tests, negative tests, session and factor validation, monitoring, owner acceptance, exceptions, remaining risk, and closure criteria.
11. Evidence appendix
Traceable fictional source ID, timestamp, system, account, session, event, owner, related finding, limitation, and preservation note.
Integrated Workflow
Complete the Identity Review in Six Steps
Confirm scope and evidence
List the fictional identities, systems, applications, resources, time range, owners, and source records included in the review.
Build the approved-state model
Document the fictional business purpose, account type, role, permissions, duration, device, session, owner, and lifecycle expectation.
Calculate the current state
Trace authentication, groups, roles, direct grants, local access, privilege, sessions, factors, resources, and monitoring evidence.
Write and prioritize findings
Separate confirmed facts, conclusions, alternatives, evidence gaps, impact, priority, and accountable owners.
Remediate and validate
Use narrow approved changes, preserve prior state, prepare rollback, refresh sessions, and test required and denied actions.
Monitor and close
Confirm owner acceptance, related-system review, monitoring, residual risk, due dates, and evidence-based closure criteria.
Key Vocabulary
Integrated Identity Review Terms
Identity review
A structured fictional evaluation of accounts, authentication, authorization, roles, permissions, lifecycle, sessions, ownership, and monitoring.
Scope
The fictional identities, systems, applications, resources, time range, environments, and evidence included in the review.
Confirmed fact
A statement directly supported by one or more preserved fictional evidence sources.
Reasonable conclusion
An evidence-based fictional interpretation that is supported but still includes stated assumptions or limitations.
Alternative explanation
Another plausible fictional interpretation that should be considered until stronger evidence excludes it.
Finding
A documented fictional condition in which access, ownership, lifecycle, session, policy, monitoring, or evidence differs from the approved state.
Risk priority
The fictional importance assigned to a finding using scope, sensitivity, privilege, duration, exposure, likelihood, and business impact.
Compensating control
A temporary fictional safeguard used when the preferred access-control improvement cannot be completed immediately.
Remediation owner
The accountable fictional person or team responsible for correcting, validating, monitoring, and closing a finding.
Residual risk
The fictional risk that remains after approved remediation and validation are complete.
Closure criteria
The exact fictional technical, business, monitoring, ownership, and evidence conditions required to close a finding.
Evidence appendix
A traceable fictional index connecting report conclusions to source records, timestamps, event IDs, owners, and limitations.
Fake Dashboard
Fake Integrated Identity and Access Review Dashboard
Training dashboard for the fictional Northstar Learning Services IAM review.
Identities reviewed
20
Standard, privileged, service, application, temporary, emergency, shared, dormant, and orphaned identities.
Findings
8
Four high-priority and four medium-priority identity, access, lifecycle, session, recovery, resource, emergency, and monitoring findings.
Validation actions
32
Required-access, denied-access, session, factor, application-local, ownership, monitoring, and business-acceptance checks.
Fake SOC Alert
Multiple IAM Findings Share One Root Governance Gap
Source: Fake Integrated Identity Review Console • Time: 04:10 PM
Fake Log Panel
Fake Integrated Review Evidence Timeline
DAY1 INVENTORY identities='20' applications='9' service_accounts='6' DAY2 FINDING id='IAM-01' type='orphaned_service_account' priority='high' DAY3 FINDING id='IAM-02' type='mover_privilege_accumulation' priority='high' DAY4 FINDING id='IAM-03' type='privileged_session_gap' priority='high' DAY5 FINDING id='IAM-04' type='old_factor_after_recovery' priority='high' DAY6 FINDING id='IAM-05' type='excessive_report_role' priority='medium' DAY7 FINDING id='IAM-06' type='unsafe_resource_inheritance' priority='medium' DAY8 FINDING id='IAM-07' type='monitoring_context_gap' priority='medium' DAY9 FINDING id='IAM-08' type='emergency_review_overdue' priority='medium' DAY12 REMEDIATION high_priority='in_progress' owners='assigned' DAY16 VALIDATION required_access='pass' denied_access='pass' DAY17 VALIDATION sessions='pass' factors='pass' local_access='pass' DAY20 MONITORING related_findings='none_new' DAY30 REVIEW residual_risk='documented' closures='approved'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Integrated IAM Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken the Final IAM Report
Integrated Safe Lab
Produce the Northstar Identity and Access Review Report
Fictional Evidence Set
Forty-Eight Correlated IAM Records
Review fictional identities, sign-ins, MFA, factors, devices, sessions, roles, groups, direct permissions, resource shares, local application access, privileged elevation, lifecycle, recovery, monitoring, owners, approvals, validation, and source-health records.
Required Deliverables
- Define scope, systems, identities, time range, evidence sources, exclusions, and safety boundary.
- Build an identity and account inventory with account types, owners, status, purpose, and review dates.
- Calculate effective access for the highest-risk subject-resource-action combinations.
- Write at least eight findings with evidence, impact, priority, owner, and recommendation.
- Create a remediation roadmap with immediate action, permanent action, rollback, due date, and dependencies.
- Run positive, negative, session, factor, local-access, ownership, monitoring, and business validation.
- Document evidence gaps, confidence, exceptions, residual risk, and closure criteria.
- Build an evidence appendix linking every conclusion to fictional source records.
Scenario Decision Lab
An Orphaned Service Account May Support an Unknown Dependency
A fictional service account has no active owner but still records occasional reads from a retired reporting endpoint. The team cannot immediately prove whether one legacy report depends on it.
Scenario Decision Lab
A Finding Is Technically Fixed but Business Validation Is Missing
A fictional excessive report role is reduced, sessions are refreshed, and administrative actions are denied. The resource owner has not yet confirmed that the required monthly reporting workflow still works.
Defender Habits
Integrated Identity and Access Management Checklist
Check Your Understanding
I6.8 Mini Quiz: Identity and Access Management Lab
Choose your answers first. Explanations appear only after submission.
1. What is the strongest purpose of an integrated identity and access review?
2. Which statement is a confirmed fact?
3. Why should a remediation plan include positive and negative tests?
4. Which finding should generally receive higher priority?
5. What is residual risk?
6. Why is an evidence appendix important?
7. Which closure plan is strongest?
Portfolio Prompt
Portfolio Prompt
Create a complete fictional Identity and Access Review Report using at least forty-eight identity, account, authentication, factor, device, session, role, group, permission, resource, application-local, privileged-access, lifecycle, recovery, monitoring, owner, approval, validation, and source-health records. Include scope, safety boundary, inventory, effective-access calculations, at least eight findings, prioritization, owners, remediation roadmap, rollback, positive and negative tests, session and factor validation, monitoring, evidence appendix, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation