Access Based Enumeration: How to Enable ABE for Windows Server

Access-based Enumeration was designed to stop the rumor mill from churning. It ensures that nosy employees do not even see objects they have no permissions for. In this article, we are going to explain how to set up ABE correctly and how it works on different Windows drives.

Every company has different types of data that different employees need access to based on their business role. Because this data is usually kept on a central file server shared by many people, admins have to set NTFS permissions and share permissions in such a way that each user can only access files and folders they need for their job. Restricting IT privileges to only what is strictly necessary, a.k.a. least privilege access, helps prevent employee data theft and lowers the risk of cyberattacks. It is an essential part of cybersecurity.

However, if you properly restrict permissions in Windows namespaces, you run into a problem: By default, users can still see folders they are not allowed to open, which can expose sensitive directories, makes it confusing to navigate the file server and leads to a lot of support calls by frustrated employees. Access based enumeration allows you to stop these issues by limiting what users can see to what they can actually interact with.

Up until Windows Server 2008, admins had to pay extra attention to how and especially where they set up new folder structures. Users with access to a particular folder were automatically able to see all of its subfolders, even if they did not have the necessary permissions to open those folders. This scenario was quite common and led to all kinds of problems:

Trying to avoid these issues often led to complicated folder structures because admins had to rely on moving folders to deeper levels or new branches of the directory tree to hide them from unauthorized users. Which meant that for employees who did need that data, it was buried under layer after layer of different folders. Access based enumeration put an end to this challenge.

Access based enumeration was introduced with Windows Server 2003 R2. Since it is not active by default, ABE must be explicitly enabled if you want to use the feature. ABE is also available for other data storage systems such as NetApp, where the feature must be activated through the ONTAP Command Line.

Since Windows 2008 R2, access-based enumeration also works in Distributed File System Namespaces (DFS). As with regular shares, ABE must be actively enabled for DFS namespaces since the setting is not in effect by default. More information on how to enable ABE for a DFS namespace. Again, there are multiple ways to enable ABE in a DFS namespace:

With ABE enabled, your file server needs to show different information to each user depending on their permissions. This requires checking which folders a user has access to the moment they open a directory, and then filtering out objects they cannot read, open or edit. Checking each object’s access control list to determine if it can be displayed adds extra steps to file server navigation and can affect performance and response times.

At least, ABE did have an effect on performance in the past. Back in 2003, when ABE was first introduced, this process required considerable amounts of CPU power, which in turn led to a loss in performance and thus to an increase in costs. You can learn more about the technical background of this phenomenon in this Microsoft blogpost.

Nowadays, however, performance loss when you enable ABE is no longer an issue. Even for very large environments, Microsoft currently cites that the additional CPU power required is at around 2-3 percent. For shares containing a max. of 15,000 files, no differences in performance could be observed at all.

Access based enumeration allows you to hide directories a user cannot access. To allow users to navigate to subfolders they have explicit permissions for, you need to make sure they receive the List Folder Contents permission for all directories between root and their target folder. Otherwise, they either cannot see or cannot open directories on the way to their destination.

Example: If a user has the permission “Modify” for a folder located on level 2, this does not automatically give them the right to browse level 1 and reach this folder. They must be given the List Folder Contents permission for level 1. You can automate this process by setting up nested list groups.

Here is the recommended approach: The permission group that grants a user access to a folder on level 2 is itself a member of a list group which holds the List Folder Contents permission for the superordinate folder. This way, any users that are assigned read or write privileges for subfolders automatically receive the necessary list rights to navigate to the folder in question.

For permissions on deeper levels, the procedure is the same, except multiple nested list groups are required: the permission group for level 3 is a member of the list group for level 2, which is itself a member of the list group for level 1. Because the number of required groups grows with each additional level and Windows puts a hard limit on group membership for SIDs, you should avoid setting explicit permissions on deeper levels (max. 2 or 3 levels deep).

Access Control Lists use the concept of inheritance, which means that access rights are automatically passed on from parent folders or files to subordinate (child) folders/files. To ensure ABE works correctly, it is very important to restrict inheritance when assigning these permissions.

If you enable inheritance for the “list contents” permission, users will be able to browse all folders on the file server because the permission needed to browse level 1 would propagate to all subordinate files and folders. To learn how to deactivate the inheritance function in Windows 10, click here.

In the best-case scenario, Access Based Enumeration works as follows:

As you can see: Access Based Enumeration works – but only if admins configure all settings and properties in accordance with best practices. If a share or its subfolders are not configured correctly or if you accidentally apply the unaltered default settings, users will be able to see the entire directory list, even with ABE active.

When you are managing hundreds of users and countless directories, the time and effort needed to create and manage the permission/list groups that govern file server access quickly grows out of control. Not only does manual group management waste a lot of valuable time for your IT staff, it also increases the risk of errors that could lead to chaotic structures, overprivileged users and data leaks. I.e. the sort of chaos that leads many organizations to see a file server migration as their only escape.

With tenfold, you won’t have to worry about group creation or user management any longer: Our innovative IAM platform automatically creates all groups and structures required to implement ABE and follow best practices like the AGDLP principle. Thanks to our user lifecycle management, users receive the exact permissions they need for their current role and lose outdated privileges whenever their position changes.

Identity access management solutions like tenfold do more than just help you manage file server permissions: Your IAM software acts as your central hub for user and permission management across all connected systems, from local Windows systems to the cloud services of Microsoft 365 and various third-party applications.

Not only does this central platform allow you to automate user provisioning and deprovisioning, its reporting tools also provide you with a clear overview of effective permissions on a user and item level. To make your admins’ lives even easier, tenfold additionally provides a self-service interface for access requests and password resets and can even help you automate user access reviews – the regular permission audits required by many IT security standards. You can learn more about the advantages of tenfold by watching our video overview or signing up for a free trial today!