NTFS vs Share Permissions for A+ Core 2: Worked Examples

Two gates on every shared folder

Objective 2.2 of 220-1202 lists "NTFS vs. share permissions" with file and folder attributes and inheritance. The idea behind every question is that a shared folder has two separate gates.

• Share permissions sit on the share itself. Microsoft's documentation says they "apply only to shared network resources" and "do not restrict access of any local user or terminal server user." The levels are Read, Change, and Full Control.
• NTFS permissions sit on the folder and files. They "affect both local and remote access" and apply regardless of protocol. The basic levels are Full control, Modify, Read & execute, List folder contents, Read, and Write.

When the folder is opened over the network, both gates apply. Microsoft's rule is that the final permission comes from "applying the more restrictive permissions" of the two. When the folder is opened locally, including from a Remote Desktop session on that server, only NTFS applies.

How each gate is calculated

Before you compare the two gates, work out each one on its own.

1. Collect every entry that matches the user. That means the user account and every group the user belongs to. Microsoft describes the access token as containing "SIDs for the groups of which the user is a member."
2. Add up the Allows. Permissions from different groups are cumulative. Read from one group plus Modify from another means Modify.
3. Apply Deny by position, not by reputation. Windows evaluates entries in a fixed order. Microsoft's icacls reference lists it as explicit denials, explicit grants, inherited denials, then inherited grants. An explicit Deny beats any Allow. An inherited Deny loses to an explicit Allow set directly on the object.
4. Anything not granted is denied. If no entry grants the requested right, access is implicitly denied.

Then, for network access, take the more restrictive of the share result and the NTFS result.

Worked examples

All the people and folders below are invented for practice.

1. The share is the bottleneck. The share \\FS01\Sales gives Everyone Read. NTFS on the folder gives the Sales group Modify. Dana, in Sales, opens it from her laptop.

• Share result: Read. NTFS result: Modify.
• Network result: Read. The share is more restrictive.
• If Dana signs in to FS01 through Remote Desktop and opens D:\Sales locally, she gets Modify, because share permissions do not apply to local or terminal server users.

2. Groups add up. The share gives Everyone Full Control. NTFS gives Staff Read & execute and gives Managers Modify. Luis is in both groups.

• NTFS result: Read & execute plus Modify, which is Modify.
• Network result: Modify. Full Control on the share does not add anything NTFS did not grant.

This is the common design Microsoft describes: set the share wide open and control access with NTFS.

3. An explicit Deny wins. On the folder D:\Bids, NTFS gives Sales Modify and gives the Contractors group an explicit Deny on Write. Priya is in both groups.

• Explicit Deny is evaluated before explicit Allow. Priya cannot write, even though Sales can. She can still read.

4. An explicit Allow beats an inherited Deny. On D:\Projects, an administrator sets Deny Write for Interns, and every subfolder inherits it. On D:\Projects\Training, the administrator adds an explicit Allow Modify for Interns.

• In Training, the explicit Allow is checked before the inherited Deny. Interns can write in Training.
• In every other Projects subfolder, the inherited Deny applies. Interns cannot write there.

"Deny always wins" is the shortcut that fails here. It is true when both entries are explicit on the same object, not when the Deny is inherited and the Allow is explicit.

5. The fix that "didn't work." You add Omar to the Finance group so he can open \\FS01\Finance. He still gets Access Denied. The access token that carries his group memberships is produced when he signs in, so his existing session does not include Finance yet. He needs to sign out and back in.

6. Moved or copied. An HR spreadsheet with HR-only permissions sits in D:\HR. A user moves it to D:\Public on the same volume, and another user copies a second HR file to the same place.

• Microsoft's article on copying and moving says an object moved to a different folder on the same volume keeps its original permissions. The moved file stays HR-only.
• A copied file, or a file moved to a different volume, inherits the permissions of its new folder. The copied file takes on Public's permissions, which may expose it.

Inheritance and attributes

Inheritance means a child folder or file receives entries from its parent. You can stop it on a folder. In the advanced security settings, disabling inheritance asks whether to convert the inherited entries into explicit ones or remove them. The icacls /inheritancelevel option does the same thing from the command line: d disables inheritance and copies the entries, and r disables it and removes the inherited ones.

Attributes are not permissions. Read-only, hidden, system, and archive are properties of the file. A user with NTFS Modify can still be blocked by a file marked read-only until the attribute is cleared, and a hidden file is still readable by anyone who has permission and knows the path. The archive attribute also matters for backups, which the backup types guide explains.

A five-step method for exam questions

1. Is the access over the network or local? If local, skip the share entirely.
2. Work out the share result: add up the Allows, apply any Deny.
3. Work out the NTFS result: add up the Allows, then apply the evaluation order of explicit Deny, explicit Allow, inherited Deny, inherited Allow.
4. For network access, take the more restrictive of the two.
5. Check the trap details: a group change without a fresh sign-in, or a file that was moved rather than copied.

Practice it for real

On your own Windows Pro computer, create a test folder, share it, and give a second local account different share and NTFS permissions. Open it from another machine and from the computer itself. Seeing Read over the network and Modify locally on the same folder makes the rule stick. Local Users and Groups and the Security tab are covered in the Windows tools guide, and the rest of objective 2.2 is in the Core 2 security guide.

Work through the six examples again without looking at the results, then practice A+ Core 2 permission scenarios with Passy →.