How Share, NTFS Permissions and Inheritance Actually Work

This article explains Windows® share and NTFS level permissions including inheritance.

The concept of NTFS permission inheritance was introduced a long time ago with the release of Windows® 2000. For whatever reason, it is still one of the less understood topics. We discuss what share and NTFS permissions are and how they work in detail.

We offer a file server and NAS migration product called CopyRight2 and from time to time our customer support gets asked why specific permissions, do not migrate to the target as expected.

The answer to that question is typically that the source folder has inheritance enabled and is inheriting some permissions from one of its parent folders. Those parent folders are out of scope and not part of the copy job.

The folder should be migrated to the target system below some existing folder that has different permissions configured than the parent folder on the source system has.

Therefore, the resulting permissions will look differently, because of the way how inheritance works.

 

Table of Contents:

1. Share Permissions
2. NTFS Permissions
3. Basic NTFS Permissions
4. Windows Access Check
5. NTFS Permission Inheritance
6. The Advanced NTFS Permission View
7. Basic NTFS Permission Entries
8. Advanced NTFS Permission Entries
9. New Object Creation
10. Canonical Order of NTFS Permissions
11. Corrupted NTFS Permission Inheritance
12. How to Recover From Corrupted NTFS Permission Inheritance
13. How CopyRight2 Handles Permission Inheritance
14. Effective Access if Share And NTFS Permissions Are Used
15. Who Can Change Permissions?
16. What to Use? Share, NTFS or Both Types of Permissions?
17. Conclusion
     

Share Permissions

Share permissions restrict shared folder access from remote systems using the so-called server message block (SMB) protocol.

They are not applied if accessing data on a system locally, either physically being in front of the machine or by using remote desktop (RDP) protocol.

A share’s permissions consist of a list of user and group accounts being granted the following three types of permissions:

Each type of share permission can be granted as a permission either allowing or denying access for a specific account.
 

Accounts in that list are not stored by name, but are referenced by their unique SIDs instead. Each user and each group (and also built-in groups like “Everyone” for example) have unique identifiers.

This way, you can rename accounts at a later time without having to grant permissions for the renamed account again.

Internally a share permission uses a so-called Windows security descriptor. File shares utilize only the so-called discretionary access control list (DACL) component of the security descriptor.
 

NTFS Permissions

NTFS permissions have more complexity than share permissions but on the other hand offer more functionality.

Just like file shares, NTFS permissions are using Windows security descriptors as well.

Beyond the DACL controlling access to the data, the Windows UI displays three of the four components a security descriptor consists of:

• A second list for auditing data access called system access control list (SACL)
• An owner account.

Both the DACL and the SACL are lists of variable length and contain entries, referred to as access control entries (ACE).
 

There are different ACE types, but the most commonly used ones are the so-called access allow and access deny type of entries

In addition to its ACE type, the entries contain the SID of an account a permission is granted or denied for (or in case of SACLs access is audited for) and a bitmask determining the specific type of access.
 

Basic NTFS Permissions

To make life as easy as possible for Administrators, NTFS permissions have six basic types for folders and five for files.

(*) Execution applies to executable files. In case of scripts, it is up to the script processor executing the script to allow or deny the execution. For executable files this is handled by Windows process creation logic.

Windows Access Check

When Windows tests whether a specific request to some resource should be granted or denied it processes the security descriptor DACL from top to bottom.

• If it encounters an ACE that grants access, the access check is done and access is granted.
• If it encounters an ACE that denies access, the access check is done as well and access is denied.
• If the end of the list is reached without any match, it will also deny access.

This allows to grant permissions for a group, but at the same time to deny access for specific members of that group. This can become quite confusing, but anyways, it is technically possible.

If auditing is enabled the same logic will be used to determine if access to a file or folder should be logged or not. You can define audit ACEs for successful and denied operations.
 

NTFS Permission Inheritance

Opposed to share level permissions, NTFS permissions offer the possibility to let files and subfolders inherit NTFS permissions from their parent folders.

The inheritance chain can be interrupted at any level, from the top down to a file, by disabling inheritance.

If inheritance is enabled at all levels, the chain will go up to the permissions set at the drive’s root folder. In case of non-Windows systems, this means up to the point in the file system where the root level is located. Linux/Unix based systems do not incorporate the concept of drive letters as they exist in Windows.

Disabling inheritance is sometimes referred to as “breaking the inheritance chain”. If solely using the term "broken" that can be kind of misleading and sounds as if there is something broken that needs to be fixed. This has to be differentiated from corrupted NTFS permissions which we will deal with in a chapter further below.

If inheritance is disabled at a specific level, the object, either a file or folder will not inherit permissions from its parent folders.

If that object is a folder its own “children”, subfolders and files, will still inherit permissions of that folder as long as those child objects themselves have inheritance enabled. However, they will only inherit from up to the point where inheritance was disabled in the chain.

The Advanced NTFS Permission View

If looking at NTFS permissions with Windows Explorer, you will at first be presented with a simplified view of the DACL. This simplified view is sorted by account name in alphabetical order and is hiding inheritance.

Consequently, there is no way to know if a specific permission was explicitly set at that level or if it was inherited from one of the parent folders.

Additionally, the default view does not display information about auditing (SACL) and the owner.

The advanced NTFS permission view provides access to the other components of the security descriptor.

In the “Permissions” tab you can see the DACL. In the “Auditing” tab the SACL is shown.

The Owner can be seen in the upper left corner of the dialog. You will also see information about where ACEs were inherited from:

If you disable inheritance for a file or folder with Explorer, you will be given the option to convert inherited ACEs to explicit ACEs or to remove them.

If you decide to convert the inherited ACEs, you will subsequently see that the same accounts possess the same level of access they had before. The only noticeable difference will be the content of the “Inherited From” column showing “None” to indicate those are explicit ACEs now.

Basic NTFS Permission Entries

After clicking on the "Add" or "Edit" button within the "Advanced Security settings", you will see the following dialog.

You can control the type of ACE and set it either to "Allow" or "Deny".Deny".

If the object you selected is a folder, you additionally have very fine-grained control over what type of objects the ACE should get applied to by setting "Applies to" to a corresponding scope:

• This folder, subfolders and files (This is the default setting)
• This folder only
• This folder and subfolders
• This folder and files
• Subfolder and files only
• Subfolders only
• Files only

Advanced NTFS Permission Entries

All basic NTFS permissions are internally mapped to a more granular bitmask, consisting of 14 bits.

Advanced NTFS permissions are slightly simplified and shown in the Windows GUI in the form of 13 checkboxes, after clicking on the "Show advanced permissions" hyperlink:

There is an additional 14th checkbox titled “Full Control”, which simply means all the other 13 shown options are checked.

Advanced NTFS permissions go beyond the scope of today’s article, but we will write more about this topic in the near future.
 

New Object Creation

When a new file or a folder is created, inheritance is enabled by default, so the new object will inherit permissions from the folder it is placed in.

Here is what happens to each component of the security descriptor during object creation:

• The owner gets automatically assigned to the user account that created the object.
  
  As with all rules in the real world there are exceptions. If a file or folder is created by an account being a member of the local “Administrators” group, the owner will be set to that group instead.
  
  If user account control (UAC) is active and therefore Explorer is running in non-elevated mode, this exception does not apply. In that case the “Administrators” group is removed from the restricted logon token used to launch the Explorer.Exe process, the process any other started processes inherit their logon token from. So, any files or folders created will have the owner set to the account name, just as it would be the case for regular users. This makes it an exception to the exception.
   
• The DACL and SACL lists, containing permissions and auditing information are inherited and initialized according to the settings of the access control entries of the folder they are located in. If for example an ACE should be applied to subfolders only this ACE will not be part of a new files corresponding ACL.
   
• On systems that are configured as domain members, the group owner is initialized to the primary global group of the current user, which is usually the "Domain Users" group. On systems that are not member of a domain, the SID of this group will resolve to "None", a built-in and invisible local group that has no members.

Canonical Order of NTFS Permissions

In the “Advanced View”, you will notice permissions are arranged in some specific order referred to as "canonical order" instead of being listed alphabetically by account name.

You could split the permissions in multiple blocks, with the first block being explicitly set ACEs for the object, if there are explicit ACEs defined at that level.

The next block will be ACEs inherited from the objects parent folder, if that parent folder has explicit ACEs defined.

The blocks continue with that parent folder’s parent folder and so on, until a folder is reached that has inheritance disabled or is the drive's root folder. This last folder of the chain, will be the ultimate block.

Within each block there is a specific order as well, with denying ACEs coming first, followed by ACEs allowing access.

This order is critically important because of the way an access check works (top down), which we talked about in an earlier chapter.

If using Explorer to examine an access control list that is not in canonical order, you will receive a nice reminder and Windows offers to arrange it properly for you.
 

Corrupted NTFS Permission Inheritance

To explain why corrupted NTFS permissions can occur, it is necessary to understand how permissions and inherited permissions are stored (see the previous chapter “Canonical order of NTFS Permissions”).

If you are familiar with software development, you could ask yourself, why are inherited permissions of parent folders redundantly stored all over the place for each file and folder?

The answer to that question is performance. Specifically, the performance for users of the system.

Of course, the Windows team could have implemented some sort of pointers that refer to the permissions of parent folders instead of redundantly storing this information. But that would have meant slower access checks, occurring each time a file or folder is accessed.

With the design choice made an access check is extremely fast, because it only has to traverse the list of permissions that is already in place.

There is no need for any additional I/O to work up the inheritance chain to ultimately decide yes access is granted or no access is denied.

It is also more robust because each object comes along with a complete definition of who is allowed to access it. Just imagine, if pointers were used, and if the top of the inheritance chain got corrupted somehow. That would in effect mean that any files below would potentially get access problems as well.

Additionally it made the transition from previous Windows versions like Windows NT 3.5x and NT4 easier, because those versions did not yet support inheritance.

The caveat of this design choice is, as you most likely know, that it can take a fairly long time to propagate changes. For example, if making changes to the top level of the inheritance chain.

In that case Windows has to propagate this change down to the very last files and folders that inherit from the folder the change was made to.

However, those type of permission changes usually occur much less frequently than actual access to data takes place.

If the propagation of a change is interrupted for whatever reason, permissions will be in an inconsistent state. This could be viewed as another disadvantage for this design choice.

In that case some of the file and folder permissions have been updated, while others are still having the permissions they were having before the change was made.
 

How to Recover From Corrupted NTFS Permission Inheritance

To resolve that issue, it is usually sufficient to make a random change at the same location the interrupted changes was made at and allow it to completely propagate.

You could for example add your own user account or the account of a group that you don’t mind getting access (not the "Everyone" group for example).

Important: To propagate permissions, please make sure you do not check the “Replace all child object permission entries with inheritable permission entries from this object”! What this would do, is essentially replace the permissions of all files and folders below that level with the permissions of the folder you are currently looking at. This would wipe out all explicit permissions that were set at the lower levels! So, unless this is what you want to do, do not check it.

Next undo the change again and remove the user or group previously added and let it propagate one more time. Voila, the “broken” permissions are repaired.

CopyRight2 has a command line feature built-in that allows you to propagate permissions in a single turn, instead of having to do it twice.

If you should ever need it and you don’t have the time to do it twice, please contact our support (support@sys-manage.com) and we can assist you. This feature is also helpful if you don't know at which level the interrupted change was made at.
 

How CopyRight2 Handles Permission Inheritance

The default settings of a CopyRight2 copy job will copy the inheritance flag of specified source folder(s) to the target.

With that default setting, the destination folder's NTFS inheritance will get enabled if the source folder had inheritance enabled and disabled if the source folder had inheritance disabled.

Additionally, you can enable and disable inheritance regardless of the source folder’s setting. Please note that this only applies to the specified root folder(s) defined in the “Source and Destination” page.

For folders below the specified folder(s), it will always migrate the inheritance setting as long as you don’t enable the “Do not migrate permissions. Inherit permissions from destination folder instead” option.

If you select the option “Disable inheritance flag for root folder(s)” you can, similar to Explorer, convert ACEs inherited from the source’s parent folder(s) into explicit ACEs on the destination side. To accomplish that you can additionally enable the “Convert ACEs inherited from source parent folders to explicit ACEs on target folder” option.
 

• Disabling inheritance and converting all inherited ACEs into explicit ACEs is one way to migrate ACEs that were inherited from a source folders parent. In turn any files and folders below the destination folder will not inherit from parent folders of the destination folder either because the inheritance chain ends there.
• Alternatively, you could leave the job at its default settings and ensure that the parent folder(s) of your specified destination folder, have the same permission the parent folders of the specified source folder(s) had on the source system You could also do that at a later time, after the data was migrated to the target, but the propagation of permissions may take a while.
• Another way to solve the problem, would be to migrate the parent folders as well, as long as the migration's goal is not structural changes. You could for example migrate the entire source drive with a single source/destination pair to a specified target drive.
  
  This usually works best if you do not want to consolidate data and the target drive is empty before you begin the migration. At least if you want to use a delta copy with the synchronization mode set to “Add/Update/Delete”, effectively making the destination identical to the source.
• Another possibility would be to create the target folder manually, set the permissions accordingly and then uncheck the “Copy explicit permissions of root folder(s)” option. This will leave the manually created destination folder’s permissions untouched and any files and subfolders will inherit those permissions, if they had inheritance enabled on the source. This is useful if you want completely different permissions assigned on the target side.

Effective Access if Share and NTFS Permissions Are Used

When granting access, the system first evaluates the share level permissions.

If access is granted at the share level, the next step will be to evaluate if NTFS permissions result in a positive access check as well.

Therefore, the more restrictive permissions are applied.

If for example, the share level permissions grant change, but the NTFS permissions grant “Full Control” permissions the more restrictive “Change” permission becomes effective.

Any attempts to modify permissions, requiring full control access would be denied.

Who Can Change Permissions?

Besides of users having “Full Control” granted in the DACL, the owner of a file or folder can also change permissions.

To prevent users from granting potentially wrong permissions, you could restrict the file share permissions to change instead of granting “Full Control” permissions.

As described in the “NTFS permissions” chapter, the owner is automatically set by the system when a new file or folder is created.

What to Use? Share, NTFS or Both Types of Permissions?

Depending on your requirements you could completely rely on share level permissions to control access.  This is the least complex option. There will be no inheritance involved and only a limited set of three possible share permissions exist.

You could as well decide to use only NTFS permissions to control access and have share level permissions set to something like “Everyone:Full Control” or "Everyone:Change" and "Administrators:Full Control". NTFS permissions are more complex but at the same time offer more functionality. There are more basic NTFS permissions than share level permissions and even more advanced NTFS permissions you can grant to accounts. Additionally, NTFS permissions can utilize inheritance.

In some cases, you may want to utilize a combination of both, and the more restrictive permissions will become effective. Implementing a mix of both is the most complex option.

Conclusion

Congratulations on surviving our first blog posting and reading up to this point. This is kind of boring stuff to most people.

Microsoft has struck a good balance with keeping the administration as simple as possible, while at the same time offering a ton of features.

The more complex things like inheritance, for example, are placed behind "Advanced" buttons. So, if you don't have the requirements to use them, you can evade them completely, for example by using share level permissions only.

If you have been reading until here you should now have a much better understanding of how Windows permissions work.

We have covered the differences of share and NTFS permissions, and how they work in conjunction. We also talked about basic NTFS permissions, NTFS inheritance and how to use Windows Explorer’s advanced permission view to investigate NTFS permissions. Additionally, we discussed the canonical order of NTFS permissions and how to recover from a corrupted & inconsistent state of inherited NTFS permissions.

If you should have any feedback, positive or negative or some follow-up questions, please let us know in the comments below. Thank you.

2 comments on article "How Share, NTFS Permissions and Inheritance Actually Work"

Robert Stevens

This is one of the better explanations of inheritance and permissions that I have seen. I especially like that you make clear several points

1. Permissions are stored with the object in question regardless

whether they were inherited.

2. Share permissions are much simpler than NTFS

3. The inheritance chain can be terminated at an upstream container

5/24/2024 9:32 PM

trueframe

Thanks for clarifying how NTFS permissions and inheritance function. Very informative!

6/17/2024 4:06 PM

Leave a comment

Name:	Please enter a name.
Email:	Please enter an email address. Please enter a valid email address.

Comment:	Please enter comment.
I agree	This form collects your name, email, IP address and content so that we can keep track of the comments placed on the website. For more information check our Privacy Policy and Terms Of Use where you will find more details on where, how and why we store your data. You must read and accept this rules.

Add comment