"Who Can Do What" — Permissions, Shares, Access Control
Dana from Finance is furious — Engineering can see the Finance share. Time to learn how Windows decides who gets access to what, and fix a real permissions problem.
NTFS Permissions: The Six Levels of Access
Every file and folder on an NTFS volume has a set of permissions that control exactly what users and groups can do with it. Think of these permissions as a graduated set of keys — each one unlocks a different level of access.
| Permission | What It Allows | Includes |
|---|---|---|
| Read | View file contents and attributes. See folder listings. Read permissions on the object. | — |
| Write | Create new files and subfolders. Modify file attributes. Append to existing files. | — |
| List Folder Contents | View file names and subfolder names inside a folder. Only applies to folders, not files. | Read (on folder) |
| Read & Execute | Everything Read allows, plus run executable files and scripts. Traverse folders. | Read + List Folder Contents |
| Modify | Everything Read & Execute allows, plus edit files, delete files and subfolders. | Read & Execute + Write + Delete |
| Full Control | Everything Modify allows, plus change permissions (the ACL itself) and take ownership. | Modify + Change Permissions + Take Ownership |
Notice that each permission level builds on the ones below it. Full Control is the most powerful — a user with Full Control can not only read, write, and delete, but can also change who else has access. This is why Full Control should almost never be given to regular users.
ACLs, ACEs, DACLs, and SACLs
Permissions don't just float around — they're stored in a precise data structure attached to every object in Windows. Understanding this structure is essential for anyone managing security.
Every file, folder, registry key, and securable object in Windows has a Security Descriptor. The Security Descriptor contains:
- Owner SID — Who owns the object (can always change its permissions)
- DACL (Discretionary Access Control List) — Controls who can access the object
- SACL (System Access Control List) — Controls what gets audited (logged)
The DACL is the one that matters most for day-to-day access. It contains a list of ACEs (Access Control Entries). Each ACE is one rule that says:
Deny ACEs are always evaluated first — Deny always wins
Windows processes ACEs in a specific order: Deny ACEs are evaluated first. If any Deny ACE matches, access is blocked immediately — even if an Allow ACE also exists. This is why explicit Deny always wins.
The SACL works differently. It doesn't control access — it controls auditing. You can configure the SACL to log events when specific users access (or fail to access) specific objects. This is how you set up audit trails in Windows — for example, logging every time someone opens a file in the Payroll folder.
Inheritance: How Permissions Flow Downward
Imagine you have a department folder with 500 subfolders and 10,000 files. Do you really want to set permissions on each one individually? Of course not. That's what inheritance solves.
When you set permissions on a parent folder, those permissions automatically flow down to all child folders and files. This is controlled by inheritance flags in each ACE:
| Flag | Abbreviation | Meaning |
|---|---|---|
| Object Inherit | (OI) |
This ACE is inherited by files in child folders |
| Container Inherit | (CI) |
This ACE is inherited by subfolders |
| Inherit Only | (IO) |
The ACE applies only to children, not to the folder itself |
Common combinations you'll see in icacls output:
(OI)(CI)— Applies to this folder, all subfolders, and all files (the most common)(OI)(CI)(IO)— Applies to subfolders and files only, not the folder itself(CI)(IO)— Applies to subfolders only (not files, not this folder)(OI)(IO)— Applies to files only (not subfolders, not this folder)
Breaking inheritance is sometimes necessary. When you break inheritance on a folder, you have two choices:
- Copy inherited permissions — Start with the same permissions but as explicit (non-inherited) ACEs that you can modify independently
- Remove inherited permissions — Start with a blank ACL (dangerous! could lock everyone out)
Share Permissions vs. NTFS — "The Two Locks"
Here's where most people get confused. Windows has two completely separate permission systems that can apply to the same resource:
Think of accessing a shared folder like entering a building:
- Lock 1 — Share Permissions (the Front Gate): Applied when someone connects over the network. Only three options: Full Control, Change, or Read. Coarse-grained. Like a building security guard who checks your badge at the entrance.
- Lock 2 — NTFS Permissions (the Office Door): Applied regardless of how you access the file (network or local). Six levels of granularity. Like individual office door locks inside the building.
The Rule: When accessing over the network, you must pass through both locks. Your effective access is the most restrictive combination of the two. If the share says Full Control but NTFS says Read, you only get Read. If the share says Read but NTFS says Full Control, you still only get Read.
When accessing locally (logged in at the machine), share permissions don't apply at all — only NTFS permissions matter.
Share permissions are set on the share itself (via net share or Computer Management). NTFS permissions are set on the file system (via icacls or Properties → Security). The two systems are completely independent — changing one does not affect the other.
| Feature | Share Permissions | NTFS Permissions |
|---|---|---|
| Applies when? | Network access only | Always (local + network) |
| Granularity | 3 levels (Full Control, Change, Read) | 6 levels + special permissions |
| Applied at | The share (folder level only) | Any file or folder |
| Inheritance? | No — share-level only | Yes — flows to subfolders and files |
| Tool | net share, Computer Management | icacls, Properties → Security tab |
Best practice: Set share permissions to "Everyone: Full Control" (wide open gate), then use NTFS permissions to control the fine-grained access (locked office doors). This way you only have one set of permissions to manage. Using both for access control creates confusion and makes troubleshooting nightmarish.
Administrative Shares: C$, ADMIN$, IPC$
Windows creates several hidden shares automatically. They're called "administrative shares" because they end with a $ sign, which hides them from casual browsing (they don't show up in Network Neighborhood).
| Share | What It Is | Why It Exists |
|---|---|---|
C$ |
The entire C: drive | Allows administrators to remotely access the entire file system. Every drive letter gets one (D$, E$, etc.). |
ADMIN$ |
Points to C:\Windows |
Used by remote administration tools (like PsExec) to push executables or access system files. |
IPC$ |
Inter-Process Communication | Used for named pipes and remote management. Required for many Windows remote management features. Also used during null session attacks. |
\\target\C$ to browse the entire drive remotely. Lateral movement tools like PsExec use ADMIN$ to deploy payloads. Disabling these shares breaks some management tools but significantly reduces attack surface. Most organizations leave them enabled but monitor access via SACL auditing.
Principle of Least Privilege
The Principle of Least Privilege is the single most important concept in access control: every user, program, and process should have only the minimum permissions necessary to do their job — nothing more.
Why does this matter? Because every extra permission is an extra attack vector:
- A marketing intern with Modify access to the Finance share? If their account is compromised, the attacker can alter financial records.
- A service account running with Domain Admin privileges? If the service is exploited, the attacker owns the entire domain.
- Everyone in the company having Full Control on a shared drive? One ransomware infection encrypts everything.
Real examples at Meridian Dynamics:
- Good: intern01 has Read access to the IT documentation share. Can learn, but can't accidentally delete anything.
- Good: Finance-Staff has Modify on
Finance$, but only Finance-Managers have Full Control. - Bad: Engineering-Staff somehow has Read access to the Finance share — they have no business reason to see financial data.
- Bad: t.manning (a departed employee) still has Modify access to the Payroll folder — a major compliance violation.
The Two-Lock Model: Share + NTFS
Click any layer to explore what happens at each checkpoint when a remote user requests access to a file.
NTFS Inheritance Tree
Permissions flow downward from parent to children — unless inheritance is broken. Notice the Payroll folder has broken inheritance (its own explicit permissions).
Finance-Managers: (OI)(CI) Full Control
Finance-Staff: Modify ✓
Finance-Managers: Full Control ✓
Inherits • Staff: Modify ✓
Inherits • Staff: Modify ✓
Finance-Staff: Modify ✓
Finance-Managers: Full Control ✓
Payroll-Team: (OI)(CI) Modify
Finance-Managers: Full Control
⚠ t.manning: (OI)(CI) Modify
⚠ t.manning: Modify
⚠ t.manning: Modify
Permission Calculator: Share vs. NTFS
Select the Share permissions and NTFS permissions a user has. The widget calculates the effective access (the most restrictive combination). When accessing over the network, both locks must be passed.
Investigation Lab: The Finance Share Incident
net share to see all shares on the file server MD-FS01.icacls "\\MD-FS01\Finance$" to view the NTFS permissions on the Finance share. Identify who has access that shouldn't.icacls "\\MD-FS01\Finance$\Payroll" to check the Payroll subfolder. Look for former employees.net user t.manning /domain to check when t.manning last logged in. Is this account still active?•
icacls "\\MD-FS01\Finance$" /remove "MERIDIAN\Engineering-Staff"
•
icacls "\\MD-FS01\Finance$\Payroll" /remove "MERIDIAN\t.manning"