NTFS Permissions: Best Practices for Your File Server!

NTFS permissions allow you to grant directory access to individual users and groups. In contrast to share permissions, which only give you three permission levels (Read, Change and Full Control), NTFS permissions offer much more granular control. To set NTFS permissions, right-click on a folder or file and select “Properties”, then go to the “Security” tab to select permissions or click on “Advanced” for further settings and special permissions.

Available permission levels include:

In order to manage permissions for Windows networks effectively, it’s important to understand the relationship between NTFS and Share Permissions. Here’s the short version: You can combine Share Permissions and NTFS Permissions to manage file shares. The more restrictive permission takes priority, so if the Share Permission is set to Change and NTFS is set to Read, the user will only be able to read the file.

Of course, Share Permissions only apply when access is made through through the network. Since NTFS permissions offer more fine-grained options for access control, it is recommended to leave Share permissions on a high level (Full Control for admins and Change for normal users) and define the actual permission level using the NTFS system. This gives you more granular control and helps avoid conflicts between the two permission types.

The number 1 mistake admins make is assigning NTFS permissions directly to users instead of managing access through groups. This quick fix might save time in the moment, but inevitably comes back to bite you when you need to change or review permissions.

Yes, it takes time and effort to create and manage the global user groups and local permission groups required to implement Microsoft’s AGDLP principle. But it’s still a lot easier than trying to keep track of thousands of individual permissions. When file access needs to be adjusted later on, would you rather make one change to the relevant permission group or change the settings for dozens of individual users? Exactly.

There’s also the problem of transparency: While you can easily check which groups a user is part of by examining their account, direct access they have been granted will not show up in this list. You would have to check the properties of the directory in question to see the permission entry. If the user is deleted later on, their entries in the Access Control List will stay behind and turn into so-called orphaned SIDs, which add clutter to your Active Directory.

Similar to granting direct access to users is the common practice of assigning permissions directly to groups of users instead of adding this organizational group to dedicated permission groups that govern access to a specific resource. User groups should only be used to group together staff members that have the same business role and therefore need access to the same files and folders.

Even admins who follow these recommendations and set NTFS permissions via dedicated permission groups tend to fall for another common mistake: reusing groups to assign additional permissions that go beyond the intended use of the group. It may be tempting to alter an existing group to add or change permission levels for the sake of convenience.

However, by using the same AD group to assign new access rights, group members will end up with more permissions than the group name indicates. This makes permission reporting confusing and misleading. When new users are added to the group later on, they will receive more access than the group name suggests, which can lead to privilege creep and increase the risk of insider threats.

You may have noticed a common theme in these mistakes: Whenever you deviate from the agreed-upon approach, whether it’s group usage or naming conventions, things quickly get chaotic. To keep things clear and avoid confusion, all admins must stick to the same standard at all times. That’s part of the reason why manually implementing NTFS best practices requires a great deal of effort and discipline across your entire organization.

Sometimes users are given access to a specific subfolder but cannot navigate to it through the Windows Explorer. This is because permissions for a subdirectory do not automatically come with the permission to navigate through superordinate folders. Technically, users could get around this issue by entering the exact path into the Explorer address bar. But since your average user relies on clicking their way to their destination, you’ll want to make sure they can actually reach the desired folder through the GUI.

This requires granting them list permissions (“Show folder contents”) for superordinate directories. The best way to set list rights is via dedicated list groups: By making permission groups members of the list groups for directories above their folder, users automatically receive the necessary permissions when they are given access to a resource.

However, it is very important to restrict inheritance with this approach to ensure that users can only view folder contents for the one directory they need to navigate through, not all folders on the same level. Otherwise, users end up being able to browse all directories on the file server. To avoid these kinds of mistakes in the future, read our free white paper and learn about best practices for managing permissions in Microsoft environments.

So we’ve established what not to do when it comes to NTFS permissions, but how do you actually manage NTFS permissions correctly? There are various aspects to consider, but to help you get started, we’ve compiled the most important recommendations for managing NTFS permissions safely and efficiently.

At a glance – 9 best practices for managing NTFS permissions:

To establish a standardized process for granting access, naming groups, adding new directories etc., it helps to put everything in writing. Clear documentation ensures that you always have a reference point when you are unsure of the proper way to do handle an edge case. When you want a large team of admins to follow a consistent approach, there is really no way around establishing formal, written policies.

Always use permission groups to set NTFS permissions. Do not assign NTFS permissions directly to users or objects: Direct permissions are impossible to keep track of and when the user in question is removed from the Active Directory, they will leave behind orphaned entries in the access control list.

If you let users, even executives or managers, create new folders in the root directory, your tidy folder structure will soon become cluttered with random items. Instead, keep the root-level hierarchy locked down and only allow IT to add new directories.

It should go without saying, but there’s really no scenario where a normal, non-IT user needs the Full Control permission. Compared to Modify, which already lets them create, edit and delete files, all Full Control adds is the ability to change settings and permission levels, which you do not want normal staff to do.

Users who have Read and Execute access to a specific folder must also have the List Folder Contents permission for any higher-up folders in order to navigate to their target. The List Folder Contents permission should be assigned via group membership. By using nested groups, you can ensure that each user automatically receives the NTFS permissions for browsing when they are given the relevant permissions to the subordinate folder.

Do not set explicit NTFS permissions on deep levels in the directory tree. Stick to two or three levels for explicit permissions to keep things simple and let permission inheritance take care of the rest. Otherwise, the number of permission groups and list groups you need quickly grows out of control. Since Windows actually puts a hard limit on the number of groups a user can be part of, having too many of these groups can lead to not all permissions being read correctly.

In Windows, it is possible to break inheritance for permissions on each folder level. This means that the usual mechanisms (i.e. superordinate NTFS permissions are inherited by subordinate folders) can be bypassed, making it possible to set entirely new NTFS permissions. This process should be avoided because it makes it more difficult to read NTFS permissions and, as a result, permission structures become confusing and chaotic.

Windows 2003 R2 introduced Access Based Enumeration (ABE), which allows you to hide folders from users who do not have access to them. Activating this setting will massively improve clarity for users, as they no longer have to comb through hundreds of directories just to find the specific folder they actually need.

In accordance with the Principle of Least Privilege, each user should only be given the minimum level of access required to do their job. Eliminating unnecessary permissions prevents them from being exploited in the case of a cyberattack and is a key requirement of modern security frameworks like Zero Trust, as well as many compliance standards such as ISO 27001, NIST CSF and HIPAA.