Decrypt 6 confusing File server NTFS permissions issues

A Windows platform based file server is a straightforward solution, and NTFS is the most critical permission mechanism for Windows file servers. As we know, NTFS provides a set of valid file (folder) security access mechanisms that let us strictly control how users read, write, and otherwise file files in the operating system. However, NTFS permissions are complex and, in general, the administrator has the ability to set file or folder permissions on the file server as required, but it does not get the results we expect, even for an experienced administrator. What is the reason? I think the main reason is that they do not know or ignore some of the security features of NTFS. This article will decrypt six confusing NTFS permission issues, and hopefully it helps to improve the security of your file server.

1. Why are there exceptions to ACL permission inheritance?

(1). There is a conflict between ACLs

The inheritance mechanism used by NTFS plays an important role in the access control of the file. To determine permissions, Windows must view all ACLs that affect the file. Any file or folder has its own ACL, which is used to grant or deny access to specific users or groups of users. In addition, each object inherits complex permissions from the parent folder and various parent folders. All of these permissions have conflicting potential possibilities: One ACL allows the user to access the file, while the other explicitly denies access. In addition, a user may also be a member of multiple user groups and have different permissions. (Figure 1)

(2). Rules to avoid ACL conflicts

To resolve the conflict between ACLs, Windows sets the following set of rules: (1). At any level, permissions from different user groups are grouped. (2). At any level, the Deny permission takes precedence over the allowed permission. (3). Permissions that are directly set on an object take precedence over permissions inherited by that object. (4). Permissions inherited from a close relatives folder take precedence over permissions inherited from a distantly related folder. (5). Any object can be protected by inheriting permissions from the parent folder. When you work with these rules, Windows first checks the access control entries that the object itself has. If it is not found, Windows continues to view its parent folder until it finds an access control project that explicitly allows or denies access to the object.

(3). Block Permission inheritance

We can prevent an object from inheriting the parent folder by opening the object's Security Properties Advanced dialog box, finding the Permissions page, and clearing the inherit from parent the permission entries that can be applied to child objects, including those explicitly defined here check box. If we do this, then the permissions of the parent folder will no longer affect the current file or folder and the next level of files or folders, at least in most cases. (Figure 2)