Windows Server Access-based Enumeration (ABE)

Enhance security by making files and folders hidden from users who do not have permission. Normally files and folders that reside in a folder or share the users have access to will be visible. When the user attempts to access the restricted resource, the user will get an access denied error.

By implementing Access-Bases Enumeration (ABE) the user will never know about files they do not have access to. ABE will hide folders the user does not have access to. This helps keep out prying eyes and also prevents them from seeing folder and file names that may be sensitive themselves.

The ABE works with both standard shares and Distributed File System (DFS).

Download and install the MS ABEUI Utility. Use the GUI or the CLI to configure.

The MS KB can be found here: How to implement Windows Server 2003 Access-based Enumeration in a DFS environment

In Windows Server 2008 and newer, ABE is now part of the standard windows server management interface.

This article describes how to implement Microsoft Windows Server 2003 Access-based Enumeration in a DFS environment. When Access-based Enumeration is enabled, Windows does not display files or folders that a user does not have the rights to access.

Consider the following scenario:

  • You deploy a Distributed File System (DFS) root named \\dfs-share\users. Several DFS links exist under the root.
  • These DFS links represent the home directories of several users.
  • You want to enable Access-based Enumeration on the \\dfs-share\users root so that users see only their home directories when the users enumerate the root.

To implement Access-based Enumeration in this scenario, follow these steps:

  1. Use administrative credentials to log on to Windows Server.
  2. Use the Cacls utility to set the appropriate access control lists (ACLs) on the DFS links. (The Cacls utility is included in Windows Server 2003.)For example, make the ACL on the link the same as the ACL on the target of the link. Therefore, if \\dfs-share\users\johndoe links to a target named \\server1\share1\johndoe, make the ACL on \\dfs-share\users\johndoe the same as the ACL on \\server1\share1\johndoe. If the target is on a Windows-based computer, type cacls at the command prompt to verify the ACL. For more information about the Cacls utility, type cacls /? at a command prompt.
  3. Apply the Access-based Enumeration property on each root share by using the ABEUI utility. To obtain this utility, visit the following Microsoft Web site: (

    Note Set the Access-based Enumeration property on each replicated root share.

  4. As soon as the domain root and the links are replicated, use the Cacls utility to manually set the ACLs on the replicated links. Repeat this step for all replicas. However, first make sure that the root and links have been fully replicated on the target.
  5. In a cluster environment, when a node fails over to another node, DFS removes all the DFS links and recreates them on every failover. When failover occurs, ACLs must be reapplied on the links. To automatically reapply links after a failover, follow these steps:
    1. From the cluster administrator console, create a script resource. Make sure that this new resource is part of the same group as the DFS and as the share resources.
    2. Add the script resource to the script resource that sets the ACLs for each DFS link.
    3. Make the new script resource dependent on the DFS resource. This step makes sure that the new script resource is run only after the DFS links are created on the new failed over node.
    4. Take the group offline, and then put the group back online to make sure that the new script resource works.
  6. Restart the Distributed File System (DFS) service. To do this, follow these steps:
    1. Click Start, click Run, type cmd, and then click OK.
    2. Type net stop DFS, and then press ENTER.
    3. Type net start DFS, and then press ENTER.

After you follow these steps, only those DFS links that a user has the rights to access are displayed when the root is enumerated.

Sometimes, the ACLs on links are reset and must be reapplied. ACLs are reset in the following scenarios:

  • A DFS root is restored by using the DFS utility (Dfsutil.exe). The ACLs on the DFS links are not preserved and are reset.
  • DFS roots are exported and then imported to another location. The ACLs on the DFS links are not preserved and are reset.
  • If you add a new DFS root target, the links do not receive the appropriate ACLs because the links are created for the first time.
  • If you rename a DFS link, the DFS service deletes and recreates the link. The ACL on the link is reset.
  • If you delete multi-component links, DFS removes any empty intermediate directories. Any ACL that was set on a directory is lost when a directory is removed. When you create a new multi-component link by using the same path, you must reapply all ACLs on the intermediate directories.

Note When Access-based Enumeration does not perform as expected with DFS links, first examine the ACLs on the DFS links by using the Cacls utility.

If the ACL on the DFS link is not set to match the ACL on the target, the following conditions may be true:

  • If the ACL on the link is more restrictive than the ACL on the target, the link will not be displayed. However, if the user knows the name of the link, the user can locate the appropriate path and see the contents of the target.
  • If the ACL on the link is less restrictive than the ACL on the target, the link is displayed. However, when the user locates the link, the user sees an “Access Denied” message.

Require assistance?

Support from our knowledgeable help desk staff ensures your team stays productive by swiftly and accurately resolving issues.