I3.2 File Permissions and Shared Folders
Review fictional Windows files, folders, shares, owners, groups, inherited rules, explicit rules, effective access, classification, and business need using least-privilege principles.
Lesson Progress
File Permissions and Shared Folders
High School Intermediate • I3: Windows Security Basics • Lesson 2 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Folder Can Look Private While Still Being Broadly Accessible
A user may gain access through a direct entry, inherited rule, nested group, local group, share permission, application identity, or administrative role. Defenders must follow the complete access path rather than trusting one visible permission.
Weak response
“The folder lists only the project group, so access must be correct.”
Strong response
“Review ownership, inheritance, explicit entries, nested groups, share access, effective access, classification, and approved need.”
Objective 1
Explain how Windows file and folder permissions, ownership, inheritance, local groups, and shared-folder access work together.
Objective 2
Distinguish explicit permissions, inherited permissions, allow entries, deny entries, ownership, share permissions, and effective access.
Objective 3
Evaluate fictional access using data classification, approved role, owner, business need, group membership, and least privilege.
Objective 4
Identify broad, stale, duplicate, inherited, conflicting, and ownerless access without changing real systems.
Objective 5
Create a professional permission-review report with findings, confidence, owners, controlled corrections, validation, rollback, and review dates.
Why This Matters
Permissions Protect Confidentiality, Integrity, and Availability
Read access affects confidentiality. Write, modify, and delete access affect integrity and availability. Full control can also change who receives access. A clear permission model protects data while preserving legitimate work.
Permission Levels
Match Access Level to Approved Need
Read
Allows viewing file contents, folder listings, and basic metadata under the applicable conditions.
Main risk
Sensitive information may be exposed even when users cannot modify it.
Defender question
Does this role need to view this data, and is the classification appropriate for the audience?
Write
Allows creating or changing content within the scope of the granted permission.
Main risk
Users may alter data, introduce unsafe files, or create integrity and accountability problems.
Defender question
Does the role need to create or update content, or would read-only access be enough?
Modify
Typically includes reading, writing, changing, and deleting content.
Main risk
Deletion and broad content changes can cause data loss or operational disruption.
Defender question
Is deletion required for the approved workflow, and are backups and ownership clear?
Full control
Allows broad use of the resource and may include changing permissions or ownership.
Main risk
Excessive control can allow access expansion, permission changes, and destructive actions.
Defender question
Why is this level necessary, and can a narrower role-based permission replace it?
Deny
Explicitly blocks an action under the relevant permission calculation.
Main risk
Deny entries can create confusing and unexpected results when users belong to multiple groups.
Defender question
Is the deny rule necessary, documented, and tested against all required roles?
Special permissions
Granular combinations controlling specific actions such as listing, reading attributes, deleting, or changing permissions.
Main risk
Complex entries can be difficult to review and may hide unintended access paths.
Defender question
Can the design be simplified into clear role-based groups and standard permission sets?
Core Concept
Effective Access Is the Result of Multiple Layers
A user's final access may depend on direct entries, inherited entries, local groups, nested groups, explicit deny rules, share permissions, application controls, and the path used to reach the resource. No single line tells the complete story.
Identity
Which user, group, or service is requesting access?
Path
Which local, shared, linked, or application path is used?
Rules
Which explicit, inherited, allow, and deny entries apply?
Purpose
What approved role or workflow requires access?
Result
What can the identity actually do under the reviewed conditions?
Inheritance and Exceptions
Follow the Complete Permission Path
Parent-to-child inheritance
A child file or folder may receive access rules from its parent, creating consistent permission structures.
Review evidence
Parent path, inherited entries, inheritance state, and any child-level exceptions.
Inheritance disabled
A child object may stop receiving future parent changes and keep or remove previously inherited entries.
Review evidence
Inheritance status, conversion history, explicit entries, owner, and change record.
Explicit exception
A directly assigned rule may create more or less access than the parent design.
Review evidence
Specific user or group entry, permission level, approver, purpose, expiration, and review date.
Nested groups
A user may receive access indirectly through one group that belongs to another group.
Review evidence
Complete group path, role ownership, current membership, and effective-access calculation.
Conflicting entries
Users may receive permissions from multiple groups, explicit rules, inherited rules, or deny entries.
Review evidence
All applicable entries, membership paths, share access, local access, and final effective result.
Moved or copied objects
Permission behavior may change depending on destination, method, ownership, and inheritance.
Review evidence
Original path, destination, operation type, resulting permissions, owner, and validation results.
Folder Models
Different Shared Resources Need Different Reviews
Local-only folder
Used directly on the Windows device by local users, applications, or services.
Network-shared folder
Reached through a share name from another authorized device or user.
Team project share
Used by a defined project, class, department, or operational team.
Public or broad internal share
Available to a large internal population or all authenticated users.
Administrative share or protected location
Used for approved management, deployment, support, or system operations.
Application data folder
Used by a service, application, scheduled task, or system component.
Key Vocabulary
Windows Permission and Sharing Terms
Permission
A rule that allows or restricts actions such as reading, writing, modifying, deleting, or changing access.
Ownership
The recorded relationship between an account and a file or folder, often affecting who can change permissions.
Inheritance
The process by which a child file or folder receives permissions from a parent folder.
Explicit permission
A permission applied directly to a specific file or folder rather than inherited from a parent.
Effective access
The final access result after relevant user, group, inherited, explicit, allow, deny, and sharing rules are considered.
Share permission
An access rule applied when a folder is reached through a network share.
Local permission
An access rule applied directly to files or folders on the Windows device.
Security principal
A user, group, service identity, or other identity to which access rules can be assigned.
Least privilege
The practice of granting only the access required for an approved task and no more.
Access control entry
A specific rule that assigns permissions to a user or group.
Broad access
Access granted to a large group or population beyond the narrow approved need.
Stale access
Access that remains after the original role, project, owner, or business need has ended.
Evidence Analysis
What Permission Evidence Can and Cannot Prove
Evidence source
Permission list
Can support
Users, groups, inherited entries, explicit entries, allow or deny rules, and assigned permission levels.
Limitation
Does not prove current business need, complete group nesting, or network-share effects.
Evidence source
Ownership metadata
Can support
Which identity is recorded as owner and may have authority to manage access.
Limitation
Does not prove the owner is current, appropriate, or actively responsible.
Evidence source
Group membership
Can support
Direct and indirect role membership that may grant access.
Limitation
Does not prove the role remains approved or that every nested group is visible in one record.
Evidence source
Share configuration
Can support
Share name, allowed users or groups, access level, network scope, and availability.
Limitation
Does not prove the final local file permission or actual business need.
Evidence source
Effective-access result
Can support
The calculated access outcome for a specific identity under the reviewed conditions.
Limitation
May not include application-level controls, offline copies, alternate paths, or future group changes.
Evidence source
File and folder classification
Can support
Expected sensitivity, handling requirements, owner, retention, and approved audience.
Limitation
Labels may be missing, outdated, or inconsistent with actual content.
Evidence source
Usage and audit records
Can support
Observed access, modification, deletion, sharing, or ownership activity under available logging.
Limitation
Absence of recorded use does not prove no access occurred or no future need exists.
Evidence source
Owner and project records
Can support
Approved purpose, role groups, project dates, owner, expiration, and review requirements.
Limitation
Documentation may be stale or may not match the technical permission state.
Defensive Workflow
Complete a Permission Review in Six Steps
Define resource and purpose
Identify the fictional path, owner, classification, application or project role, and approved audience.
Collect permission evidence
Record ownership, inherited and explicit entries, group membership, share permissions, and effective access.
Map access paths
Connect direct users, nested groups, services, applications, network shares, alternate paths, and profile locations.
Compare with approved need
Check whether each user or group needs read, write, modify, full control, or no access.
Classify findings
Separate confirmed broad access, stale access, inheritance problems, owner gaps, evidence gaps, and unsupported claims.
Plan controlled correction
Assign an owner, preserve evidence, test the change, define rollback, validate applications and users, and document the new baseline.
Fake Dashboard
Fake Windows Permission Governance Dashboard
Training dashboard for the fictional Meadowbrook Learning Services shared-resource environment.
Shared folders reviewed
28
Twelve project shares, six department shares, four application folders, and six broad internal shares.
Broad write-access findings
5
Five folders allow modification by groups larger than the approved editing population.
Ownerless permission exceptions
7
Seven explicit user or group entries have no current owner, expiration, or change record.
Fake SOC Alert
Internal Deployment Folder Writable by Broad Staff Group
Source: Fake Windows Access Governance Monitor • Time: 02:18 PM
Fake Log Panel
Fake Windows Shared-Folder Review Timeline
13:41:00 RESOURCE path='\\training-files\deployment-notes' classification='internal' owner='deployment-ops' 13:44:19 SHARE group='All Staff' permission='Change' 13:46:02 LOCAL inherited_group='All Staff' permission='Modify' source='D:\Shared' 13:47:51 LOCAL explicit_group='Deployment Editors' permission='Modify' 13:50:14 GROUP nested_member='Contractor Team' parent='All Staff' 13:53:28 EFFECTIVE user='sample-contractor' access='Modify' 13:58:43 OWNER intended_editors='Deployment Editors' intended_readers='All Staff' 14:03:10 USAGE staff_modifications='0' editor_modifications='42' 14:09:26 CHANGE test_group='Deployment Editors' validation='passed' 14:18:05 CORRELATION finding='broad_inherited_modify_access' confidence='high'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Permission Decision Is Best Supported?
What is the strongest next action?
Common Mistakes
Mistakes That Weaken Permission Reviews
Safe Practice Lab
Complete a Fictional Windows Permission Review
Fictional Environment
Northstar Shared Resource Assessment
Review twelve fictional folders across project, department, public-internal, application, administrative, and local-user use cases.
Required Analysis
- Record path, owner, classification, purpose, and approved audience.
- List inherited and explicit permissions.
- Map direct users, nested groups, services, applications, and shares.
- Calculate fictional effective access for selected identities.
- Identify broad, stale, duplicate, conflicting, and ownerless entries.
- Assign risk, confidence, owner, expiration, and review date.
- Write a tested correction, rollback, validation, and baseline-update plan.
Scenario Decision Lab
A Project Ended but Its Write Group Still Exists
A fictional project share remains available after project completion. The Project Editors group still has modify access, but no current project owner is assigned and retention rules require the data to remain read-only for one year.
Scenario Decision Lab
A Service Stops Working After a Permission Change
A fictional application service can no longer write to its approved data folder after broad user permissions are reduced. The service identity's exact required access was not tested before the change.
Defender Habits
Windows File Permission and Shared Folder Checklist
Check Your Understanding
I3.2 Mini Quiz: File Permissions and Shared Folders
Choose your answers first. Explanations appear only after submission.
1. What is effective access?
2. Why can inherited permissions create risk?
3. What should be reviewed for a network-shared folder?
4. Why is direct user-by-user access usually harder to manage than role-based group access?
5. A user has not opened a project folder recently. What is the strongest conclusion?
6. Which evidence best supports removing write access from a broad staff group?
7. What should happen after changing folder permissions?
Portfolio Prompt
Portfolio Prompt
Create a fictional Windows File Permission and Shared Folder Review for twelve resources. Include path, owner, classification, purpose, approved audience, local permissions, share permissions, inheritance, explicit entries, groups, nested groups, service identities, effective access, usage, finding, confidence, risk, owner, correction, test, rollback, validation, and review date.
Key Takeaways
What You Should Remember
Navigation