I6.2 Accounts, Roles, and Least Privilege
Learn how defenders map fictional accounts, groups, roles, permissions, ownership, duration, and business need to find excessive, stale, inherited, unowned, conflicting, and missing access.
Lesson Progress
Accounts, Roles, and Least Privilege
High School Intermediate • I6: Identity and Access Management • Lesson 2 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
The Most Powerful Role Is Rarely the Correct Shortcut
A fictional user may need to view one report, but a broad administrator role also allows editing, exporting, role assignment, and configuration. Least privilege does not mean denying required work. It means granting the exact actions, resources, conditions, and duration needed while preserving accountability and safe removal.
Weak response
“Give the user administrator because it includes the permission they need.”
Strong response
“Identify the exact resource, action, owner, purpose, duration, access path, conflicting duties, and validation plan.”
Objective 1
Explain how fictional user accounts, service accounts, groups, roles, permissions, entitlements, ownership, and business purpose connect.
Objective 2
Apply least privilege, need to know, separation of duties, time limits, approval, and review to fictional access decisions.
Objective 3
Identify excessive, stale, inherited, duplicate, temporary, orphaned, unowned, and conflicting access.
Objective 4
Evaluate fictional role design using job function, resource sensitivity, action level, environment, duration, and accountable ownership.
Objective 5
Create a professional fictional Access Matrix and Least-Privilege Review with evidence, findings, owners, remediation, validation, and residual risk.
Why This Matters
Access Can Be Correct Technically and Still Be Wrong for the Business Need
A valid role or group membership shows that access exists. It does not prove the identity still needs the access, the role is designed correctly, the owner approved the exact scope, the duration is appropriate, or the application removed older local permissions. Strong review compares technical paths with current purpose and ownership.
Account Types
Eight Account Types with Different Control Needs
Standard user account
Represents one fictional person performing normal learning, teaching, support, reporting, or business tasks.
Expected controls
Unique ownership, MFA when required, role-based access, normal device policy, session limits, and periodic review.
Common risk
Old roles, direct permissions, duplicate accounts, shared use, or access that outlives a job change.
Privileged user account
Represents one fictional administrator performing elevated configuration, account, security, or system actions.
Expected controls
Separate identity, fresh authentication, temporary elevation, approval, logging, restricted device, and detailed review.
Common risk
Standing privilege, daily use for normal tasks, excessive scope, weak monitoring, or shared credentials.
Service account
Represents a fictional application, scheduled job, integration, automation, or service-to-service workflow.
Expected controls
Named owner, exact workload, restricted source, minimal permissions, identity lifecycle, logging, and expiration review.
Common risk
Unknown owner, nonexpiring secret, interactive use, excessive permissions, or use from unexpected systems.
Application identity
Represents a fictional application or workload using an approved platform identity, certificate, token, or managed identity.
Expected controls
Exact application owner, audience, environment, permission scope, source workload, rotation, and monitoring.
Common risk
Production and test reuse, broad API access, stale ownership, or unexpected workload source.
Temporary account
Provides fictional short-term access for a project, event, substitute, vendor, intern, or training activity.
Expected controls
Sponsor, purpose, start and end time, restricted role, approved device, monitoring, and automatic expiration.
Common risk
No expiration, vague sponsor, reused identity, broad access, or failure to disable after work ends.
Emergency account
Supports fictional recovery when normal identity services or administrative paths are unavailable.
Expected controls
Strict storage, limited use, named owner, strong monitoring, periodic testing, post-use review, and immediate rotation.
Common risk
Routine use, unmonitored access, unknown ownership, stale credentials, or excessive standing permissions.
Shared operational account
Supports a fictional legacy workflow that cannot yet use unique identities.
Expected controls
Documented exception, restricted device, limited permission, session logging, named users, expiration, and replacement plan.
Common risk
No individual accountability, password sharing, uncontrolled membership, and permanent exception status.
Disabled or dormant account
Represents a fictional identity no longer active but retained temporarily for records, recovery, or lifecycle handling.
Expected controls
Disabled state, session revocation, group removal, ownership record, retention reason, review date, and deletion plan.
Common risk
Active sessions, application-local access, forgotten API permissions, or accidental reactivation.
Least-Privilege Principles
Eight Questions for Every Access Grant
Minimum required action
Does the fictional identity need view, edit, approve, export, configure, administer, or a smaller action set?
Strong practice
Grant the narrowest action required for the approved task.
Weak practice
Grant administrator because it includes the needed view permission.
Minimum resource scope
Which exact fictional file, class, report, application, database, folder, environment, or service is required?
Strong practice
Limit access to the specific owned resource or defined collection.
Weak practice
Grant access to an entire department or environment for one report.
Minimum duration
How long does the fictional access need to remain active?
Strong practice
Use automatic expiration for temporary access and review standing access periodically.
Weak practice
Leave project access permanent because the user may need it later.
Correct account type
Should the work use a standard user, privileged identity, service account, application identity, or emergency account?
Strong practice
Separate normal work, privileged work, and non-human workloads.
Weak practice
Use one powerful account for every task.
Named ownership
Who owns the fictional account, role, group, resource, and approval?
Strong practice
Assign accountable owners and review dates to every access path.
Weak practice
Keep access because nobody knows who should decide.
Separation of duties
Should one fictional identity request, approve, implement, and verify the same sensitive action?
Strong practice
Separate critical steps and document emergency exceptions.
Weak practice
Allow one account to create, approve, and conceal its own changes.
Context and conditions
Does access require a managed device, approved location, fresh MFA, specific application, or protected network?
Strong practice
Use context only when it is reliable, relevant, and validated.
Weak practice
Trust any device or session once a role exists.
Review and removal
How will the fictional access be recertified, changed, suspended, expired, or removed?
Strong practice
Define lifecycle events, owners, evidence, technical validation, and closure.
Weak practice
Treat access grants as permanent configuration.
Access Paths
Eight Ways Permissions Can Reach an Account
Direct permission
training-user-17 receives report-edit directly.
Strength
The exact grant is visible and easy to identify.
Governance risk
Direct access can bypass standard roles and become difficult to recertify.
Group membership
training-user-17 joins report-reviewers, which grants report-view.
Strength
Consistent access can be governed through one group.
Governance risk
Nested or stale membership can hide the true path.
Role assignment
The teacher role grants class-view and comment permissions.
Strength
Access aligns with a defined job function.
Governance risk
Roles can become too broad or remain after responsibilities change.
Nested group
learning-support is a member of application-operators, creating inherited access.
Strength
Large environments can reuse structured membership.
Governance risk
Reviewers may miss indirect access several levels deep.
Resource sharing
A fictional report owner shares one document with one reviewer.
Strength
The owner can grant narrow resource-level access.
Governance risk
Shares can remain active after the business need ends.
Temporary role
A fictional administrator activates support-admin for forty-five minutes.
Strength
Reduces standing privilege.
Governance risk
Weak expiration, approval, or session revocation can extend access.
Application-local permission
A learning application grants editor access outside the central directory.
Strength
Supports detailed application-specific actions.
Governance risk
Central access reviews may not see the local grant.
Exception or allow list
A fictional service identity receives a limited exception for one integration.
Strength
Supports a necessary workflow when standard roles are insufficient.
Governance risk
Exceptions can become permanent, broad, unowned, or untested.
Role Design
Eight Questions for a Defensible Role
What job or service function does the role represent?
Evidence
Fictional position description, application purpose, owner, workflow, and resource responsibility.
Design failure
The role exists because users requested broad access over time.
Which exact actions are required?
Evidence
View, edit, approve, export, assign, configure, administer, or other specific permissions.
Design failure
The role includes every permission because it is easier to manage.
Which resources and environments are in scope?
Evidence
Named reports, classes, applications, folders, systems, test environments, or production resources.
Design failure
The role applies to all resources in every environment.
Which permissions should never be combined?
Evidence
Request, approval, payment, configuration, audit, role assignment, or verification responsibilities.
Design failure
One role controls the entire sensitive workflow.
Who owns and approves the role?
Evidence
Business owner, technical owner, security reviewer, recertification schedule, and escalation path.
Design failure
The role has no active owner.
Is access standing or temporary?
Evidence
Normal job need, activation conditions, start, expiration, session limits, and emergency procedures.
Design failure
Temporary project access becomes permanent.
How will role use be monitored?
Evidence
Assignments, activations, sensitive actions, denials, unusual use, owner review, and alert routing.
Design failure
The role is reviewed only after a problem occurs.
How will the role be tested and changed?
Evidence
Positive and negative access tests, business validation, change approval, rollback, and version history.
Design failure
Permissions change without preserving the prior role or checking user workflows.
Core Concept
Review the Complete Access Path
Account
Which fictional person, service, application, device, shared workflow, or emergency function is represented?
Path
Does access come from a direct grant, group, nested group, role, share, local permission, temporary role, or exception?
Scope
Which resources and actions are available, and are any permissions broader than the approved need?
Lifecycle
Who owns the access, when was it granted, when is it reviewed, and when should it expire or change?
Validation
Does required work still succeed while removed or unrelated actions are denied after the correction?
Evidence Matrix
What Access Evidence Can and Cannot Prove
Evidence source
Account inventory
Can support
Fictional account type, identifier, owner, status, creation, expiration, manager, service purpose, and lifecycle state.
Limitation
Inventory may not include application-local access or active sessions.
Evidence source
Group membership
Can support
Direct and nested fictional group relationships, change time, requester, approver, and membership state.
Limitation
Membership does not prove current business need or all permissions granted by the group.
Evidence source
Role catalog
Can support
Role purpose, owner, permissions, resource scope, conflicting roles, review date, and intended users.
Limitation
The deployed role can differ from documentation.
Evidence source
Application permission record
Can support
The fictional local role, resource, action, direct grant, share, owner, and application-specific access path.
Limitation
Central identity tools may not automatically collect every local permission.
Evidence source
Access request and approval
Can support
Requester, purpose, scope, duration, resource owner, approver, conditions, and expected outcome.
Limitation
The implemented access may be broader, narrower, delayed, or different from the request.
Evidence source
Authentication and session logs
Can support
The fictional account, device, application, MFA, session, sign-in result, source, and time of use.
Limitation
Usage does not automatically prove appropriate authorization or continuing business need.
Evidence source
Change and lifecycle records
Can support
Joiner, mover, leaver, transfer, temporary assignment, disablement, expiration, and removal actions.
Limitation
The ticket may close before every technical access path and active session are removed.
Evidence source
Owner recertification
Can support
The fictional owner’s decision to retain, reduce, remove, transfer, or investigate access.
Limitation
Owner approval can be weak if the reviewer lacks understandable permission details or current evidence.
Access Matrix
Read Ownership, Scope, Duration, and Decision Together
Identity
training-jlee
Standard user
Role and resources
attendance-viewers
Attendance dashboard
Actions and lifecycle
View
7 days · Attendance Owner
Review decision
Retain until expiration
Identity
training-rpatel
Standard user
Role and resources
report-admin direct
Reporting platform
Actions and lifecycle
View, edit, export, configure
Standing · Reporting Owner
Review decision
Reduce to report-view
Identity
svc-report-training
Service account
Role and resources
report-data-reader
Reporting data service
Actions and lifecycle
Read
Standing with quarterly review · Reporting Application Team
Review decision
Retain with monitoring
Identity
svc-report-old
Service account
Role and resources
legacy-report-reader
Old report service
Actions and lifecycle
Read
Unknown · None active
Review decision
Investigate and disable
Identity
finance-training
Standard user
Role and resources
reimbursement-full
Reimbursement workflow
Actions and lifecycle
Create and approve
Standing · Finance Process Owner
Review decision
Separate duties
Identity
legacy-display
Shared account
Role and resources
display-editor
Operations display
Actions and lifecycle
View and edit
Exception · Operations Team
Review decision
Restrict and replace
Access Review Findings
Eight Common Least-Privilege Findings
Excessive direct permission
Evidence
A fictional teacher has report-admin directly even though the approved role requires report-view only.
Risk
The account can configure and export beyond the approved learning need.
Correction
Remove the direct grant, confirm role-based view access remains, run positive and negative tests, and document owner approval.
Nested-group inheritance
Evidence
learning-support is nested inside application-operators, indirectly granting restart and configuration permissions.
Risk
Reviewers may approve the visible group without understanding the inherited operational access.
Correction
Document the full path, separate support viewing from operator actions, and recertify both groups.
Stale temporary role
Evidence
A fictional project role remains active three weeks after its scheduled expiration.
Risk
The account retains unnecessary edit and export access.
Correction
Expire the role, revoke related sessions, verify required work is complete, and review other temporary assignments.
Orphaned service account
Evidence
svc-report-old has application-read permission but no active owner or current workload record.
Risk
The account may remain usable without accountable maintenance or review.
Correction
Identify dependencies, disable through approved change control, validate reports, and remove after the retention period.
Separation-of-duties conflict
Evidence
One fictional finance-training account can create and approve the same reimbursement request.
Risk
One identity controls both creation and approval of a sensitive transaction.
Correction
Separate requester and approver permissions, test the workflow, and document emergency exception handling.
Application-local access gap
Evidence
A former editor was removed from the central role but still has editor permission inside the fictional learning application.
Risk
Central recertification incorrectly shows that access ended.
Correction
Remove the local permission, refresh the session, validate denial, and add the application to future reviews.
Shared operational account
Evidence
Three fictional staff members use one legacy display account with edit permission.
Risk
Individual actions cannot be attributed reliably.
Correction
Restrict the account, identify named users, reduce permission, improve session logging, and create a replacement plan.
Missing required access
Evidence
A new fictional reviewer has no report-view role despite an approved request.
Risk
The authorized workflow cannot be completed, encouraging unsafe workarounds.
Correction
Implement the exact approved role, validate viewing, confirm editing remains denied, and close the request with owner confirmation.
Separation of Duties
Six Workflows That Benefit from Split Responsibility
Access request
The fictional requester describes the need; the resource owner approves; an administrator implements; another reviewer validates.
Why it matters
No one identity controls request, approval, implementation, and verification.
Financial reimbursement
One fictional user creates the request and a different authorized user approves it.
Why it matters
The creator cannot approve the same transaction.
Role design
The application owner defines required actions, identity governance reviews scope, and security validates conflicts.
Why it matters
Technical convenience does not become the only role-design decision.
Privileged change
One fictional administrator performs the approved change while another reviewer verifies the result and logs.
Why it matters
The same account does not make and independently approve its own evidence.
Emergency access
The emergency user performs the recovery, a separate owner reviews the use, and the identity team rotates the credential.
Why it matters
Urgent access still receives post-use accountability.
Access recertification
The account manager confirms employment need, the resource owner confirms resource access, and the technical owner removes rejected access.
Why it matters
Each reviewer answers a question they are qualified to judge.
Defensive Workflow
Complete a Least-Privilege Review in Six Steps
Inventory identities and accounts
List the fictional user, privileged, service, application, temporary, emergency, shared, disabled, and dormant accounts in scope.
Map every access path
Trace direct permissions, groups, nested groups, roles, resource sharing, temporary elevation, local permissions, and exceptions.
Confirm business need
Identify owner, purpose, resource, action, sensitivity, environment, duration, approval, and expected workflow.
Evaluate least privilege
Find excessive scope, conflicting permissions, stale roles, orphaned access, missing expiration, and weak separation of duties.
Remediate safely
Use narrow owner-approved changes with preserved evidence, rollback, user communication, and positive and negative tests.
Validate and recertify
Confirm required work still functions, removed access is denied, sessions refresh, monitoring works, and residual risk is recorded.
Remediation Timeline
Reduce Excessive Access Without Breaking Required Work
08:00:00
Access request
Fictional reporting analyst requests report-view for the quarterly review.
Defines the approved business purpose, resource, action, owner, and duration.
08:04:00
Resource owner
Reporting owner approves view access for thirty days.
Confirms the intended authorization scope.
08:10:00
Directory
Administrator adds training-rpatel to report-admin instead of report-viewers.
The implemented role exceeds the approved request.
08:12:00
Application
The account can view, edit, export, and configure reporting settings.
Confirms the technical effect of the excessive role.
08:20:00
Access review
Reviewer compares the request, role catalog, group membership, and application permissions.
Independent evidence identifies the least-privilege mismatch.
08:25:00
Owner decision
Reporting owner approves reduction from report-admin to report-view.
Provides accountable remediation approval.
08:30:00
Change
Administrator removes report-admin and assigns report-viewers.
Implements the narrow correction.
08:31:00
Session control
Existing fictional application sessions are revoked and refreshed.
Prevents the older session from retaining excessive claims.
08:35:00
Positive validation
The account successfully views the approved quarterly report.
Confirms the required business function remains available.
08:36:00
Negative validation
The account is denied report configuration and export administration.
Confirms excessive actions were removed.
Day 30
Lifecycle
Temporary report-view membership expires automatically.
Aligns the technical state with the approved duration.
Day 31
Owner review
Owner confirms access ended and no application-local permission remains.
Completes technical and business validation.
Key Vocabulary
Accounts, Roles, and Least-Privilege Terms
User account
A fictional account representing a person who signs in and performs approved actions.
Service account
A fictional non-human account used by an application, scheduled task, integration, or workload.
Shared account
A fictional account used by more than one person, reducing individual accountability unless tightly governed.
Group
A collection of fictional accounts used to assign access consistently through membership.
Role
A named collection of fictional permissions aligned to a job or service function.
Permission
A specific allowed fictional action such as view, edit, approve, export, configure, or administer.
Entitlement
A broader term for access granted through a role, group, license, permission, resource share, or application assignment.
Least privilege
Giving a fictional identity only the access required for the approved purpose, scope, and duration.
Need to know
Limiting fictional information access to identities with a justified business or learning need.
Separation of duties
Dividing sensitive fictional actions so one identity does not control every critical step.
Orphaned access
Fictional access that remains without a valid owner, active identity, current purpose, or review path.
Access recertification
A periodic owner review confirming whether fictional access is still required, correct, and appropriately scoped.
Fake Dashboard
Fake Accounts, Roles, and Least-Privilege Dashboard
Training dashboard for the fictional Northstar Learning Services access-review environment.
Accounts reviewed
36
Twenty-six standard users, three privileged identities, four service accounts, one shared account, and two dormant accounts.
Access findings
11
Three excessive permissions, two stale temporary roles, two local-access gaps, one orphaned service account, one shared account, one duty conflict, and one missing grant.
Validated corrections
8
Every correction includes owner approval, session refresh, positive testing, negative testing, monitoring, and residual-risk documentation.
Fake SOC Alert
Approved Report Viewer Receives Report Administrator
Source: Fake Identity Governance Review Console • Time: 08:12 AM
Fake Log Panel
Fake Least-Privilege Remediation Timeline
08:00:00 ACCESS_REQUEST user='training-rpatel' resource='quarterly-report' action='view' duration='30d' 08:04:00 OWNER_APPROVAL role='report-view' approved='true' 08:10:00 DIRECTORY user='training-rpatel' assigned_role='report-admin' 08:12:00 APPLICATION permissions='view,edit,export,configure' 08:20:00 REVIEW mismatch='approved_view_vs_admin' finding='excessive_access' 08:25:00 OWNER_DECISION remove='report-admin' add='report-viewers' 08:30:00 CHANGE excessive_role_removed='true' required_role_added='true' 08:31:00 SESSION action='revoke_and_refresh' 08:35:00 TEST action='view_report' result='allow' 08:36:00 TEST action='configure_reports' result='deny' DAY30 LIFECYCLE temporary_membership='expired' DAY31 OWNER_REVIEW local_permissions='none' closure='approved'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Least-Privilege Decision Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Access Governance
Safe Practice Lab
Build a Fictional Least-Privilege Access Matrix
Fictional Environment
Meadowbrook Access Review
Review thirty supplied fictional records involving standard, privileged, service, temporary, emergency, shared, and dormant accounts; direct permissions; groups; nested groups; roles; resource sharing; local application access; requests; approvals; sessions; lifecycle records; and owner decisions.
Required Analysis
- Inventory every fictional account type and accountable owner.
- Trace direct, group, nested, role, share, temporary, local, and exception access paths.
- Record resource, action, environment, duration, approval, and business purpose.
- Identify excessive, stale, inherited, orphaned, shared, conflicting, missing, and unowned access.
- Propose narrow owner-approved corrections with preserved evidence and rollback.
- Run positive and negative access tests and refresh affected sessions.
- Document monitoring, recertification, residual risk, and closure criteria.
Scenario Decision Lab
A Project Role Remains Active After the Project Ends
A fictional project-editor role was approved for two weeks. Three weeks after the expiration date, the account still has edit and export access through the role and an active application session.
Scenario Decision Lab
A Service Account Has No Active Owner
A fictional service account retains read access to an old reporting service, but no current application team claims ownership and the workload is not listed in current inventory.
Defender Habits
Accounts, Roles, and Least-Privilege Checklist
Check Your Understanding
I6.2 Mini Quiz: Accounts, Roles, and Least Privilege
Choose your answers first. Explanations appear only after submission.
1. What is least privilege?
2. Why is a direct permission often harder to govern than role-based access?
3. What is an orphaned service account?
4. Which access design best supports separation of duties?
5. What is the strongest response to excessive report-admin access?
6. Why should an access review include application-local permissions?
7. What should happen after a temporary role expires?
Portfolio Prompt
Portfolio Prompt
Create a fictional Access Matrix and Least-Privilege Review containing at least thirty account, group, nested-group, role, permission, resource-share, application-local, request, approval, session, lifecycle, owner, and validation records. Include account types, owners, business purpose, resources, actions, duration, access paths, excessive access, stale access, orphaned service accounts, shared accounts, duty conflicts, missing access, proposed corrections, rollback, positive tests, negative tests, session refresh, monitoring, recertification, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation