Mastering NTFS and Share Permissions in Windows Server

In the world of Windows Server administration, data is the most valuable asset you protect. Whether it is sensitive financial records, proprietary source code, or personal employee information, the way you control access to this data defines your security posture. If you get permissions wrong, you either hinder productivity by blocking legitimate work or, worse, you leave the door wide open for data breaches and internal insider threats. Understanding the dual-layered approach of NTFS and Share permissions is not just a basic skill; it is the foundation of a secure infrastructure.

This lesson explores the mechanics of how Windows handles file system security. We will break down the differences between the New Technology File System (NTFS) permissions and Network Share permissions, explain how they interact when a user accesses a file over the network, and provide a roadmap for implementing the "Principle of Least Privilege." By the end of this guide, you will be able to design a scalable, secure permission structure that stands up to the rigors of a production environment.

The Two Layers of Defense: NTFS vs. Share Permissions

When a user attempts to access a file located on a remote server, they must pass through two distinct "gates." The first gate is the Share Permission, which controls access to the entry point on the network. The second gate is the NTFS Permission, which controls access to the actual files and folders on the physical disk. Understanding that these are two separate systems is the first step toward mastering Windows security.

NTFS Permissions: The Local Guardian

NTFS permissions are the most granular and powerful of the two. They are part of the file system itself, meaning they stay with the file or folder regardless of whether it is accessed locally, through a network share, or even if the hard drive is moved to another Windows machine. NTFS permissions apply to every user who logs onto the system, either locally or remotely.

NTFS offers a wide range of permissions, including:

• Read: Allows viewing the contents of a folder or the data within a file.
• Write: Allows adding files to a folder or changing the contents of a file.
• Read & Execute: Allows viewing data and running executable files or scripts.
• List Folder Contents: Specifically for folders, this allows seeing what files are inside without necessarily being able to open them.
• Modify: A powerful permission that combines Read, Write, and Delete. It allows a user to do almost anything to the data except change the permissions themselves.
• Full Control: The "keys to the kingdom." This allows everything Modify does, plus the ability to change permissions and take ownership of the file.

Share Permissions: The Network Gatekeeper

Share permissions only function when a folder is accessed over a network using the Server Message Block (SMB) protocol. If a user sits down at the physical server and logs in locally, share permissions have zero effect. Share permissions are much simpler and less granular than NTFS. They include only three options: Read, Change, and Full Control.

In modern environments, we generally keep share permissions broad (like giving "Authenticated Users" Change access) and use NTFS permissions to do the "heavy lifting" of security. This simplifies administration because you only have to manage one complex set of rules rather than two.

Callout: NTFS vs. Share Permissions

Feature	NTFS Permissions	Share Permissions
Applicability	Local and Network access	Network access only
Granularity	Very high (Files and Folders)	Low (Folder level only)
Persistence	Moves with the file system	Exists only on the Share entry
File System	Requires NTFS/ReFS	Works on any shared folder
Primary Use	Granular data security	Initial network entry point

How Permissions Combine: The "Most Restrictive" Rule

The most common point of confusion for junior administrators is how these two sets of permissions work together. When a user accesses a resource over the network, Windows calculates the "Effective Permission" by comparing the Share permission and the NTFS permission. The rule is simple: The most restrictive permission wins.

Imagine a scenario where a user, Bob, wants to edit a document in a shared folder called \Marketing.

1. Share Permissions: Bob is part of a group that has "Read" share permissions.
2. NTFS Permissions: Bob is part of a group that has "Modify" NTFS permissions.

Even though NTFS says Bob can modify the file, the Share permission acts as a bottleneck. Because "Read" is more restrictive than "Modify," Bob will only be able to read the file. Conversely, if the Share permission was "Full Control" but the NTFS permission was "Read," Bob would still only have "Read" access. To allow Bob to edit the file, both the Share and NTFS permissions must allow at least "Change" or "Modify" access.

Inheritance and Explicit Permissions

NTFS permissions use a concept called "Inheritance." By default, when you create a file or a subfolder inside a parent folder, it inherits all the permissions of that parent. This is incredibly useful for maintaining consistency across a large file server. If you grant the HR department access to the \HR_Data folder, every document dropped into that folder automatically becomes accessible to the HR team.

However, there are times when you need to break this chain. This is known as "Disabling Inheritance." When you disable inheritance on a folder, you have two choices:

1. Convert: Copy the inherited permissions and turn them into "Explicit" permissions that you can then modify.
2. Remove: Wipe the slate clean and start from scratch.

Warning: Be extremely careful when removing inherited permissions. If you remove all permissions without adding yourself or an administrative group first, you might "lock" the folder, requiring an administrator to "Take Ownership" to regain access.

Explicit vs. Inherited

• Explicit Permissions: Permissions that are set directly on an object.
• Inherited Permissions: Permissions that are passed down from a parent object.
• The Conflict Rule: Explicit permissions always override inherited permissions. If a parent folder grants "Read" to a user (inherited), but you specifically set "Deny" on a subfolder (explicit), the user is denied access.

The Best Practice Strategy: AGDLP

In a professional environment, you should almost never assign permissions directly to individual user accounts. Doing so creates an administrative nightmare. If an employee leaves or changes roles, you would have to hunt through thousands of folders to find and remove their specific name. Instead, the industry standard is the AGDLP approach.

AGDLP stands for:

• Accounts (Users)
• Global Groups (Representing job roles)
• DLomain Local Groups (Representing the resource/permission)
• Permissions (The actual NTFS/Share settings)

How AGDLP Works in Practice

1. Accounts: You have a user named Sarah.
2. Global Groups: You add Sarah to a Global Group called GG_Marketing. This group represents her role in the company.
3. Domain Local Groups: You create a Domain Local Group called DL_Marketing_Modify.
4. Permissions: You assign "Modify" NTFS permissions on the Marketing folder to the DL_Marketing_Modify group.
5. The Link: You add the GG_Marketing Global Group as a member of the DL_Marketing_Modify Domain Local Group.

This structure seems complex at first, but it is incredibly scalable. If Sarah moves to the Finance department, you simply remove her from GG_Marketing and add her to GG_Finance. You don't have to touch the file server's folder permissions at all.

Step-by-Step: Setting Up a Secure File Share

Let's walk through the process of setting up a secure folder for a department. We will use the GUI method first, as it is the most common way to visualize the process.

Step 1: Create the Folder Structure

Navigate to your data drive (e.g., D:\) and create a folder named ProjectData. Inside that, create a subfolder named Confidential.

Step 2: Configure Share Permissions

1. Right-click the ProjectData folder and select Properties.
2. Go to the Sharing tab and click Advanced Sharing.
3. Check Share this folder.
4. Click Permissions.
5. Remove the "Everyone" group (a common security risk).
6. Add "Authenticated Users" and give them Change and Read permissions.
7. Click OK twice.

Note: Why give "Authenticated Users" Change access? Because we want the NTFS layer to handle the specific restrictions. Setting the share to "Change" ensures that the share gate is wide enough to allow people to work, while NTFS will decide exactly who can do what.

Step 3: Configure NTFS Permissions

1. In the same Properties window, go to the Security tab.
2. Click Advanced.
3. Click Disable inheritance. Choose "Convert inherited permissions into explicit permissions on this object."
4. Remove any groups that shouldn't be there (like "Users").
5. Click Add to bring in your Domain Local Groups (following the AGDLP model).
6. Assign the appropriate rights (e.g., DL_Project_Read gets Read, DL_Project_Admin gets Full Control).
7. Click OK.

Automating Permissions with PowerShell

While the GUI is great for learning, real-world administrators use PowerShell to manage permissions at scale. PowerShell allows for consistency and speed, especially when setting up hundreds of folders.

Creating a Share with PowerShell

To create a new SMB share with specific permissions, you can use the New-SmbShare cmdlet.

# Create a new directory
New-Item -Path "D:\DepartmentData" -ItemType Directory

# Share the folder and give 'Authenticated Users' Change access
New-SmbShare -Name "DeptData" -Path "D:\DepartmentData" -FullAccess "Administrators" -ChangeAccess "Authenticated Users"

Managing NTFS Permissions with PowerShell

Managing NTFS is a bit more complex because it involves the Access Control List (ACL). You first "get" the current ACL, modify it, and then "set" it back.

# Define the path
$path = "D:\DepartmentData"

# Get the existing ACL
$acl = Get-Acl -Path $path

# Define a new access rule (Identity, Rights, Inheritance, Propagation, Type)
$identity = "CONTOSO\DL_DeptData_Modify"
$rights = "Modify"
$inheritance = "ContainerInherit, ObjectInherit"
$propagation = "None"
$type = "Allow"

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($identity, $rights, $inheritance, $propagation, $type)

# Add the rule to the ACL object
$acl.AddAccessRule($rule)

# Apply the modified ACL back to the folder
Set-Acl -Path $path -AclObject $acl

Explanation of the code:

• ContainerInherit, ObjectInherit: This ensures that the permissions apply to the folder, its subfolders, and all files within them.
• FileSystemAccessRule: This is the standard .NET object used to define what a user or group can do.
• Set-Acl: This is the final command that commits the changes to the disk.

Access-Based Enumeration (ABE)

Have you ever logged into a file server and seen fifty different folders, only to find you only have permission to open two of them? This is frustrating for users and provides a roadmap for attackers to see your organizational structure. Access-Based Enumeration (ABE) solves this.

When ABE is enabled on a share, Windows hides files and folders that the user does not have permissions to access. If Bob doesn't have at least "Read" NTFS permissions on the \SecretProject folder, he won't even see it in the list.

Enabling ABE

1. Open Server Manager.
2. Go to File and Storage Services > Shares.
3. Right-click your share and select Properties.
4. Go to the Settings page.
5. Check the box Enable access-based enumeration.

This is a "quality of life" improvement that also enhances security by reducing the "surface area" of information available to a standard user.

Common Pitfalls and How to Avoid Them

Even experienced administrators make mistakes with permissions. Here are the most common traps and how to avoid them.

1. The "Deny" Trap

In Windows, a "Deny" permission always takes precedence over an "Allow" permission. If a user is a member of two groups—one that allows access and one that denies it—they will be denied.

• The Mistake: Using "Deny" to manage exceptions (e.g., denying one person in a group).
• The Fix: Instead of using Deny, simply don't grant the Allow permission. Structure your groups so that users are only in the groups they need. Only use Deny in extreme, temporary circumstances.

2. Granting "Full Control" Instead of "Modify"

• The Mistake: Thinking "Full Control" is just a faster way to give "Modify" rights.
• The Problem: "Full Control" allows a user to change permissions on the folder. If a disgruntled employee has Full Control, they can lock out the IT department or grant access to people who shouldn't have it.
• The Fix: Always use "Modify" for users who need to create and edit files. Reserve "Full Control" for administrators and the system itself.

3. The "Everyone" Group

• The Mistake: Leaving the "Everyone" group on a share or NTFS list.
• The Problem: In modern Windows versions, "Everyone" does not include anonymous users by default, but it still includes guest accounts and other non-standard identities.
• The Fix: Use "Authenticated Users" or "Domain Users" instead. This ensures that only people who have successfully logged into your domain can access the resource.

4. Moving vs. Copying Files

This is a classic "gotcha" that causes endless helpdesk tickets.

• Copying a file: The file is treated as "new." It inherits the permissions of the destination folder.
• Moving a file (Same Volume): The file keeps its original explicit permissions.
• Moving a file (Different Volume): The file inherits the permissions of the destination folder (it behaves like a copy/delete).
• The Fix: Educate your team that moving folders between drives or within the same drive can result in unexpected permission behavior. Always verify the "Security" tab after a major data migration.

Callout: The "Creator Owner" Identity

You will often see a special user called "CREATOR OWNER" in the NTFS list. This is a placeholder. When a user creates a new file, they "become" the Creator Owner for that specific file. This allows them to manage or delete files they created, even if they don't have full permissions over the entire folder. It is a powerful tool for "drop-box" style folders where users should be able to manage their own uploads but not see others'.

Advanced Auditing and Troubleshooting

When permissions go wrong, or when you need to prove compliance for an audit, you need tools to see what is happening.

The Effective Access Tab

If a user complains they can't access a file, but your groups look correct, use the Effective Access tab.

1. Right-click the file/folder > Properties > Security > Advanced.
2. Go to the Effective Access tab.
3. Click Select a user and type the user's name.
4. Click View effective access.

Windows will calculate every group membership and every permission rule to tell you exactly what the user can do and why. It will even show you if a specific group policy or share restriction is blocking them.

Using icacls for Quick Checks

icacls is a command-line utility that has been around for decades. It is incredibly fast for checking or resetting permissions.

• To view permissions: icacls "C:\Data"
• To grant modify access: icacls "C:\Data" /grant SalesGroup:(M)
• To reset permissions to inherit from parent: icacls "C:\Data" /reset /t /c /l

The /t flag tells it to work recursively (through all subfolders), which is a lifesaver when fixing a messed-up file structure.

Industry Recommendations for Secure Data

To wrap up our deep dive, let's look at how top-tier organizations manage their data security.

1. Least Privilege: Always start with no access and add only what is necessary. It is easier to grant more access later than to revoke it after a user has integrated it into their workflow.
2. Regular Access Reviews: Use scripts or third-party tools to generate reports on who has "Full Control" or "Modify" access to sensitive folders. Review these lists with department heads every quarter.
3. Separate Admin Accounts: Administrators should have two accounts: a standard user account for email and browsing, and a "DA" (Domain Admin) or "SA" (Server Admin) account for managing permissions. Never log in as an admin to do daily work.
4. Use DFS (Distributed File System): Instead of giving users a path like \\Server01\Accounting, use a DFS namespace like \\Contoso.com\Shares\Accounting. This allows you to move data between servers without ever changing the permissions or the user's mapped drives.
5. Audit Success and Failure: Enable "Object Access Auditing" in your Group Policy. This logs an event whenever someone accesses (or fails to access) a sensitive file. This is crucial for forensic investigations after a security incident.

Summary and Quick Reference

Managing NTFS and Share permissions is a balancing act between security and usability. By using a layered approach and adhering to the AGDLP model, you create an environment that is both secure and easy to manage.

Permission Interaction Table

Tip: If you are ever in doubt, remember that the "Most Restrictive" rule only applies to the combination of Share and NTFS. Within NTFS itself, permissions are cumulative (unless a "Deny" is present). If User A is in Group 1 (Read) and Group 2 (Write), their NTFS permission is Read + Write.

Key Takeaways

• Dual Layer Security: Always remember that Share permissions and NTFS permissions are two separate gates. A user must pass through both to access data over the network.
• The Restrictive Rule: When Share and NTFS permissions conflict, the most restrictive one is the one that Windows enforces.
• AGDLP is Essential: Never assign permissions to individual users. Use the Accounts -> Global Group -> Domain Local Group -> Permission hierarchy to ensure your environment is scalable.
• Modify vs. Full Control: Avoid granting Full Control to standard users. "Modify" allows them to do their work without giving them the ability to break the security structure you've built.
• Inheritance Management: Use inheritance to maintain consistency, but don't be afraid to disable it for sensitive subfolders (like a "Management Only" folder inside a department share).
• Access-Based Enumeration (ABE): Enable ABE to hide folders from users who don't have permission to see them, improving both user experience and security.
• PowerShell for Consistency: Use PowerShell cmdlets like New-SmbShare and Set-Acl to automate your permission setup, reducing the chance of human error.
• Auditing and Troubleshooting: Use the "Effective Access" tab and the icacls command to diagnose permission issues and ensure your security policies are working as intended.