What permissions take precedence when NTFS and share permissions conflict?

Share permissions are the permissions you set for a folder when you share that folder. The share permissions determine the type of access others have to the shared folder across the network. There are three types of share permissions: Full Control, Change, and Read.

NTFS permissions determine the action users can take for a folder or file both across the network and locally. Unlike share permissions, NTFS permissions offer several other permissions besides Full Control, Change, and Read that can be set for groups or individually. The most restrictive permission applies when share and NTFS permissions conflict.

As you get deeper into creating shares and applying NTFS permissions to various assets, you’ll eventually run into a problem: What happens when you combine share and NTFS permissions?

For example, suppose you’ve shared a folder on a Windows Server 2012 system and you’ve created the share as a read-only share for the Everyone group, but the NTFS permissions for the folder are Full Control for the Everyone group. When conflicts like this arise between share and NTFS permissions, the most restrictive permission set wins out. So, in this example, the share’s read-only permission would win the day and users would be unable to make changes to files and folders inside the share.

Likewise, if the share permissions granted the Everyone group Full Control, but the NTFS permissions were Read, the NTFS permissions would win because they’re the most restrictive.

Keep in mind that NTFS vs. NTFS permissions are additive. So, if user A has been granted NTFS Read rights and a group to which user A belongs has been granted NTFS Modify rights, then user A gets both Read and Modify rights. However, once share permissions enter the equation, things are a bit different.

Another point to note: Share permissions are only enforced if the contents of the shared folder are accessed over the network. If a user manages to log in directly to a server and access the folder through the file system on the local server, only the NTFS permissions will apply.

Explicit vs. Inherited Permissions

Each permission that exists can be assigned one of two ways: explicitly or by inheritance. For this reason, permissions are referred to as explicit permissions and inherited permissions.

• Explicit permissions are permissions that are set by default when the object is created, or by user action.

• Inherited permissions are permissions that are given to an object because it is a child of a parent object.

Similar to the way rights are managed for groups of users, permissions are best managed for containers of objects. Objects within the container inherit all the access permissions in that container.

For example, you might explicitly give permissions to a folder named MyFolder. All subfolders created within MyFolder automatically inherit the permissions assigned to MyFolder.

In the example above, it is possible to stop subfolders from inheriting access permissions. To do this, you must explicitly clear a setting that causes the inheritance.

Allow vs. Deny Permissions

When establishing permissions, you need to specify whether the entry should have access (Allow) or not have access (not Allow) to the resource.

After permissions have been set, the LSASS (Local Security Authority) controls access to the resource. LSASS compares the SID (Security ID) that you placed on the ACL (Access Control List) with the SID placed on the security access token that is given to the user at logon. If the SID associated with the user is on the ACL, the LSASS must determine whether the access is set to Allow or Deny. The Allow and Deny permissions inherit down through the structure.

Use the Deny permission sparingly, because of the fact that restrictive permissions override lenient permissions. It is more common to clear all the Allow check box for a group, thereby removing the group from the ACL.

This has the same result, giving no access to the resource. “Not-Allow” access in this way is easier to troubleshoot, manage and configure. It is easy to forget that you have used the Deny option.

You deny permissions (using explicit Deny) only to a specific user when it is necessary to override permissions that are otherwise allowed for the group to which this user belongs.

Permission Precedence

Because of the fact that users have can have many different rights settings and objects can have many different permission settings, it is possible that conflicting permission settings might apply to a particular object and access method.

When this occurs, the system must engage in a process of resolving the various permissions to determine which ones should govern the access.

Here are some rules for resolving permissions conflicts:

1. “Deny” permissions generally take precedence over “allow” permissions.

2. Permissions applied directly to an object (explicit permissions) take precedence over permissions inherited from a parent (for example from a group).

3. Permissions inherited from near relatives take precedence over permissions inherited from distant predecessors. So permissions inherited from the object’s parent folder take precedence over permissions inherited from the object’s “grandparent” folder, and so on.

4. Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in terms of being “deny” or “allow”) are cumulative. So if a user is a member of two groups, one of which has an “allow” permission of “Read” and the other has an “allow” of “Write”, the user will have both read and write permission–depending on the other rules above, of course.

Although Deny permissions generally take precedence over allow permissions, this is not always the case. An explicit “allow” permission can take precedence over an inherited “deny” permission.

The hierarchy of precedence for the permissions can be summarized as follows, with the higher precedence permissions listed at the top of the list:

What is the rule when combining NTFS and share permissions?

Which permission takes precedence?

What happen when the permissions of NTFS file system and shared folder are combined?

Which permission takes precedence in a shared folder?