Access Based Enumeration in 2003 and MSCS

This post provides an overview of Access Based Enumeration on Windows Server 2003, some limitations, advantages and information on controlling ABE in an Windows MSCS environment.

With a standard Windows file server, for users to map the share and view the directories they have access to, all users require the list directory right at the root of the share. The client would then see all directories, and receive access denied errors if they try to navigate to any sub-folder without NTFS access.

To provide access control similar to Netware, Microsoft have introduced Access Based Enumeration in Windows Server 2003 SP1. This provides a method of displaying only files and folders that a user has access to, rather than displaying all objects in the tree.

The best description I can give is that ABE will hide what you don't have access to, as opposed to ensuring you can see what you do have access to. For example, if you have .\A .\A\B and .\A\B\C, and you have access to C but you don't have access to B, C will be hidden through the explorer GUI.

While this allows for a seamless migration from Netware-based file servers, there are several potential limitations:

ABE has to be installed as a separate component to the Operating System, which must be documented and managed for implementation and recovery scenarios.
ABE is not cluster-aware, and as enabling ABE is a per-share operation, cluster failovers resulting in the dynamic creation of shares on a physical cluster node will not create ABE-enabled shares. A generic cluster application could be created to enable ABE on all shares as they are created on each cluster node. This is non-standard and not ideal.
Increased CPU usage on the file server and slower response times to the client, processing the file data to provide information to the client on which files and directories are visible. Depending on the algorithm used, the size and depth of data structures and file system security, this may be an issue.
There are known issues with DFS and Access Based Enumeration
There are known issues with the cache on multi-user workstations, which will provide a view of any files and directories that have been viewed by any user of a computer. Client cache characteristics such as retention and location are not known.

Advantages:

If looking at migrating from Netware to Microsoft file sharing, the migration will be seamless for users. The file/directory structure and security will be similar, along with end-user access.
Using ABE is a documented solution for managing the sharing and access control for clustered home folders, rather than using the share sub-directories feature of MSCS.

Notes:

There are known issues with backup applications that do not use the ‘back up files and directories’ right backing up data through standard file shares.
It is unknown whether navigating with explorer to a top-level directory causes server-side processing of all files/folders in the share to determine the access path to all items in the tree, or whether the algorithm will process per-directory. This may be relevant in determining the test-cases to apply to assess performance. Based on testing, it is assumed that if access is denied at a top-level, sub-folders and files are not processed deeper in that branch.
Windows Server 2008 includes cluster-aware ABE, enabled by default on all shares. Going forward this minimises the risk that this is a non-standard solution.

Controlling ABE in a cluster environment

Access Based Enumeration is controlled through SMB share settings for each instance of the lanmanserver service – each physical node in the cluster. These settings are not cluster-aware, and will be lost during a cluster fail-over operation.

To ensure that ABE follows virtual cluster nodes during failovers, a generic cluster application can be created, running the abecmd.exe to verify that ABE is enabled after failover. The cluster application will be dependant on the file share resource, run for each file share.

Resource Type - Generic Cluster Application
Resource Name - <share> ABE
Description - <share> ABE
Dependencies - <share>
Command - cmd.exe /k abecmd.exe /enable <share>
Current Directory - %SystemRoot%
Interact with Desktop - De-selected

Notes:

This assumes abecmd.exe is available in the path of each physical cluster node (this is the case when you install the Microsoft package).
The /k switch is required to ensure that the cmd.exe application remains open, after the abecmd.exe process terminates. This ensures that the cluster resource monitor does not detect the resource as failed. This also leaves a command shell running for each instance of ABE being enabled, certainly not ideal and potentially misleading.

Other solutions considered

Other solutions I've considered for controlling ABE in a Windows file and print cluster environment included:

Creating a generic cluster application dependent on all shares within a particular group, using the 'abecmd.exe /all' method. This is potentially less maintenance, but does not offer granular control of particular shares
Creating a generic script resource type, with a VBScript using the supported cluster entry points to enable ABE on shares when they are created. This requires VBScript knowledge to create and maintain the solution, as opposed to a standard Microsoft provided executable.
Creating an external watcher than determine cluster failovers and share re-creation, running the appropriate abecmd.exe commands as required. This requires an external server process, either a compiled application or script, watching the cluster, not intuitive and adding a single point of failure
Controlling Access Based Enumeration through Group Policy. Third-party software exists to control the enforcement of Access Based Enumeration to file servers. However, unless the scheduled GPO refresh period was very regular, this would not be relevant in a failover cluster scenario.

CPU usage and end-user response times

The biggest concern is response times, as the Microsoft whitepaper on ABE determines that with 150,000 files, the operation of ‘reading shared directories’ increase from 12 seconds to up to 58 seconds. However, there is no detail on the type of test performed or the hardware used.

On a 2003 cluster with several million files and more than a terabyte of data, no performance impacts have been noticed when accessing folder structures through shares with ABE enabled.

References:

Access Mask:
http://msdn2.microsoft.com/en-us/library/ms790780.aspx

Access Based Enumeration whitepaper:
http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx

Access Based Enumeration:
http://technet2.microsoft.com/WindowsServer/en/library/f04862a9-3e37-4f8c-ba87-917f4fb5b42c1033.mspx

Enabling ABE with DFS:
http://support.microsoft.com/kb/907458

Implementing home folders on a cluster server:
http://support.microsoft.com/kb/256926

Windows Server 2008 failover clustering:
http://technet2.microsoft.com/windowsserver2008/en/library/13c0a922-6097-4f34-ac64-18820094128b1033.mspx?mfr=true

Scripting Entry Points:
http://msdn2.microsoft.com/en-us/library/aa372846.aspx

Create a generic application resource type:
http://technet2.microsoft.com/windowsserver/en/library/ad0bd83d-6144-45b5-8dda-3e599d1edfdb1033.mspx

Generic script cluster resource:
http://www.microsoft.com/windowsserver2003/technologies/clustering/resources.mspx http://msdn2.microsoft.com/en-us/library/aa369599.aspx
http://msdn2.microsoft.com/en-us/library/aa373089.aspx