How IT works NTFS Permissions

Richard Civil

Several years ago I got quite a surprise while fixing the permissions on a client’s file server. One of the users had Write permission on several files and folders in one branch of the directory tree. This user was only supposed to be able to read the contents of the folders. Having dutifully read the Microsoft® Official Curriculum (MOC) and searched online sources, I proceeded to give the Deny Write permission on the top-level folder. All of the documentation I had read stated that permissions inherit from the parent folder to the child and that Deny overrides Allow. It seemed that what I had done should have solved the problem, but to my disappointment the user could still write to the folders.

I opened the Property Sheet, and on the Security tab it showed both that Allow and Deny Write permission had indeed been granted. Permission inheritance just did not work the way most documentation states it should, which prompted me to do a bit of research and testing.

Direct or Inherited?

To test this, I created a folder named Test and assigned a user (Martin Weber) Allow Read and Deny Write permissions to the folder. I then created a file named Data Report.txt in the Test folder and assigned Allow Read and Allow Write to the file (see Figure 1). Sure enough, Martin Weber was able to both open and edit Data Report.txt.

Figure 1  

The property sheet of the file, shown in Figure 2, indicated that both direct Allow (white checked box) and inherited Deny (grey checked boxes) had been assigned to the Write permission. The effective permission was Allow both Read and Write.

Figure 2 Inherited Permissions

Permission Hierarchy

The next step in the testing process was to see what would happen if both Allow and Deny permissions were inherited. On the root of the C drive I had a folder named Test. In the Test folder I created a folder named Inside Test. I placed the file Data Report.txt within the Inside Test folder (see Figure 3).

Figure 3  

For the top-level Test folder, I assigned the following Allow permissions: Read & Execute, List Folder Contents, and Read. I also assigned Deny Write to that folder (see Figure 4). For the Inside Test folder, I assigned the Allow Modify permission only. The Inside Test folder shows Allow Modify as a direct permission and Deny Write as an inherited permission (see Figure 5).

Figure 4 Permissions for Test

Figure 5 Permissions for Inside Test

Now here is where it gets interesting. In Windows® 2000, the security tab of the file Data Report.txt shows Modify, Read & Execute, List Folder Contents, and Read with Allow permissions, and Write with Deny permission, but not Allow. Good old Martin Weber can indeed still write to the file. In Windows XP, the property sheet for Data Report.txt shows both Allow and Deny Write as inherited permissions, but Martin can still write to the file.

Following the Permissions

When a user is authenticated to a computer running Windows NT®, Windows 2000, Windows XP, or Windows Server® 2003, an Access Token (AT) is created. The AT contains all of the Security Identifiers (SIDs) that pertain to the logged on user. The SID of each group the user belongs to (including nesting), as well as the user’s SID, is included in the AT. The Acess Token is used to grant or deny access to resources on that computer.

NTFS uses Discretionary Access Control Lists (DACLs) to detail permissions to files and folders. A DACL is a list of zero or more access control entries (ACEs) which are ordered in a specific way. The example I’ve created includes a grandparent folder, a parent folder, and a child file. The DACL will start with the permissions for the child file. Any Deny permissions for the child will be listed first, followed by any Allow permissions for the child. Next, the DACL will show the entries for the parent folder, again with the Denies listed before the Allows. The grandparent folder follows, using the same format (see Figure 6).

Figure 6 Permission Hierarchy

NTFS Resources

For more information on how NTFS permissions work, as well as tools you can use to manage NTFS, see the following Web sites:

How Security Descriptors and Access Control Lists Work

Security Descriptors and Access Control Lists Tools and Settings

We now have an AT with all of the SIDs that can apply to the user and a DACL that has all of the permissions for the child object. When the user tries to open the child object, a request is sent to NTFS to read the object. The DACL is evaluated to determine if the user has the correct permission to read the object. Remember, no direct permissions were granted on the child object. The parent object grants the user Modify, and the grandparent denies Write. The first thing evaluated is the child Deny permissions, and since the user is not denied, the evaluation continues to the child Allow permissions. The child object does not have Allow permissions so the evaluation continues to the parent object. The user has been granted Modify at the parent folder so they are able to open the file.

The user next attempts to edit the file and save the changes. On the Security tab of the property sheet of the file, either Deny Write is checked (in Windows 2000) or both Allow and Deny Write are checked (in Window XP). When the user tries to save the file, NTFS again evaluates the permissions to see if the user can perform the requested action. The evaluation starts on the Deny permissions, then the Allows, of the child object. No direct permissions were given at that level, so nothing allows or denies the requested action. Evaluation of the parent begins with the Deny permissions and finds none. The parent Allow permissions are evaluated next and Allow Write is specified. The evaluation stops there even though the grandparent object has Deny Write.

The DACL lists permissions by the object first, followed by the object’s parent, then the grandparent, and so on up the directory tree. Each layer has the Deny permissions listed before the Allow permissions. The evaluation starts at the child and checks the permissions at that level before continuing up the tree. This process goes level by level until one of three things happen:

• If the evaluation finds a Deny for the requested action, the evaluation stops and the action is denied.
• If the evaluation finds an Allow for the requested action, the evaluation stops and the action is allowed.
• If the evaluation made it to the top of the tree and the action does not have an Allow or Deny permission specified, the action is still denied.

Making This Work

Managing NTFS permissions can be more complex than it first appears. I would recommend organizing the file system with permissions in mind. The simplest method is to have a single set of permissions that inherit throughout the branch of the tree. This may be difficult to achieve, but if securing file system resources is important in your business, it is well worth the effort. This does not mean that all users must have the same level of access. For example, you can assign Full Control to the Administrators group, Modify to the Account Operators group, and Read to the Authenticated Users group. This will inherit to all subfolders and files ensuring that each group will have consistent permissions to all resources in that branch of the tree. Now you can select "Replace permission entries on all child objects..." from the Advanced Security properties to replace changed permissions.

Richard Civil runs Civil Consulting and Training, and is Senior Technical Trainer at New Horizons in Beaverton, OR. He also holds MCT, MCSE, MCP+I, SCPI, and IC3 certifications. Learn more about Richard at www.rcivil.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.