Win 2003 High Availability Solutions, Access-Based Enumeration

The previous installment in our high availability solutions series based on Windows 2003 Server platform, we have focused on the File Share clustered resource and its characteristics. Throughout our discussion, we have covered configuration settings accessible through clustering administrative utilities as well as functionality related to storage and shared file access, such as quotas, encryption, volume mount points and volume shadow copies. We continue our coverage here with a review of access-based enumeration (ABE) and will conclude it in the next article with a discussion of NFS Service included in Windows Services for Unix.

More-seasoned Windows administrators are likely to recall the sarcastic smirks and claims of superiority from their colleagues responsible for managing NetWare environment, when attempting hide individual folders within a directory structure of network shares. While at this point, knowing the outcome of the feud between Microsoft and Novell in the operating system arena, validity of these claims seems to be rather questionable, the fact remains that such functionality, readily available in NetWare, was missing from past Windows operating system releases. This was finally changed with introduction of Windows 2003 Server Service Pack 1 and its ABE.

ABE is, in essence, an enhancement to the existing security model. It enables the application of standard NTFS Read permissions (both on folder and file levels) to one additional type of activity — viewing folder and file entries contained in shared network folders. This is different from hiding an entire share from the list generated by legacy NetBT-based Browser Service, which is possible by simply appending the “$” character to the name of such share. As the result, when connecting to a network share, users are able to see only file system objects to which they have at least Read permissions. It is important to realize that this mechanism does not apply to local access during a console or Terminal Services session on the server where shared folders reside. It also does not affect accounts that are members of local Administrator groups on that server.

Several benefits can be realized based on this new capability. The most relevant one is an increased level of security, which is accomplished by hiding information that could otherwise be exploited from unauthorized viewers. While, even in the absence of ABE, NTFS permissions should sufficiently prevent access to protected files or folders, their names might be indicative of a sensitive or confidential content, attracting undesired attention and potential exploit attempts. In addition, eliminating inaccessible parts of the directory structure from users’ view reduces their confusion, which, in turn, lowers the number of help desk calls about “Access Denied” messages.

ABE functionality is an integral part of Windows 2003 Server SP1 (that can be exposed via programmatic methods that reference updated NetShareSetInfo API), but its management utilities (providing graphical and command-line interface) must be obtained via a separate, free download (available as ABEUI.msi file in x86, x64 and ia64 versions). The installation process is wizard-driven and straightforward, prompting you to confirm whether ABE should be applied to all existing shared folders or if it will be limited to those selected and configured manually (in addition to such standard items as acknowledgement of licensing agreement, target folder, and selection of “per user” or “per computer” installation type)

Regardless of your decision, once the setup completes, the Properties dialog box for any local shared folder appearing in Windows Explorer includes the ABE tab. Surprisingly, this tab does not appear in the Properties dialog box for entries under the Shared Folders node in Computer Management MMC snap-in. From here, you can specify via two check boxes whether to “Enable access-based enumeration of this shared folder” and “Apply this folder’s setting to all existing shared folders on this computer,” yielding any desired combination of local ABE settings. Another, less-apparent result of the installation is the availability of ABEcmd.exe command line utility, which, unlike the graphical interface, allows you also to configure ABE on a remote system. Its syntax has the following format (where and designate names of target server and share, respectively):

ABEcmd.exe [/enable | /disable] [/server ServerName] {/all | ShareName}

If you subsequently decide to manage ABE from your Windows XP or Vista workstation (or another Windows 2003 SP1 Server), simply copy to it ABEcmd.exe from the %windir%system32 subfolder on the system on which you installed ABEUI.msi. To implement the graphical interface, copy ABEui.dll from %windir%system32 to the same folder on another Windows 2003 Server SP1 (or later) system and register it by running the following from the Command Prompt:

RegSvr32 %windir%system32ABEUI.dll

Note that applying this procedure to older operating systems is pointless, since, even though ABE tab will be present in a shared folder’s Properties dialog box, setting or clearing its check boxes will have no impact on the local system’s behavior. After you apply ABE to one or more of shares, you could verify its functionality by connecting to them with non-administrative credentials. Provided that these shares contain either folders or files, to which the connected user does not have Read permission, they should not appear in the directory listing — this includes all lower-level subfolders and their content. Performance overhead introduced by this mechanism is negligible in most cases. You might want to keep that in mind, however, when dealing with heavily utilized systems serving a large number of concurrent connections.

It is a bit disappointing that this useful feature has not been incorporated directly into Windows 2003 Server based clustering. If you set it on a File Share resource using any of the previously described methods, you will notice ABE settings do not persist after a failover. Fortunately, there is a fairly straightforward workaround you can employ to remediate this issue. The workaround involves creating a Generic Application clustered resource that invokes ABEcmd.exe (make sure you copy it to %windir%system32 folder on each node) with appropriate parameters, which, in turn, re-establishes desired configuration whenever ownership of the group containing the relevant File Share resource changes. The Generic Application resource must be dependent on that File Share. Hence, both must belong to the same resource group), and its Parameters tab should contain the following entries (where ShareName is the name of clustered File Share resource to which you want to apply ABE):

• Command line textbox: CMD /k ABEcmd.exe /enable ShareName
• Current directory text box: %windir%system32
• “Allow application to interact with desktop”: unchecked (to avoid a Command Prompt window appearing on the desktop)
• “Use Network Name for computer name”: not relevant in this context (for more information on its significance, refer to the Microsoft Knowledge Base article 198893).

The purpose of the command invoked by the resource is to execute ABEcmd.exe (within the Command Prompt window), which enables ABE on the target file share. This window remains open (which is enforced by the /k switch), in order to keep the clustering resource online even after the ABEcmd.exe completes. When using this approach, you need to add a separate, Generic Application resource with the settings listed above for each clustered file share. This might not be practical, especially if you rely on share autocreation (that is enabled by “Share subdirectories” option button in Advanced File Share Properties dialog box, displayed after clicking on Advanced button on Parameters tab of the File Share Properties dialog box). In this case, it might make more sense to alter the command line by replacing an individual share name with the /all switch, which reapplies ABE to all shares hosted by the current group owner.

ABE in a DFS Environment

If you intend to deploy ABE in a DFS environment, you will find some helpful information in Microsoft Knowledge base article 907458. However, since its instructions might appear confusing or incomplete (such as details on setting permissions or a generic script resource), we will provide a slightly modified example illustrating implementation of such configuration. Our sample setup will leverage a clustered DFS structure described in the MS KB article 301588, although, for the sake of simplicity, we will use only one of the groups listed there (such arrangement, while not representative of a “real-world” scenario, should be sufficient to demonstrate the underlying concept), resulting in the following:

• DFS Root Group — the group hosting a stand-alone DFS root, consisting of the following resources (IP Address resources have bene omitted since they are inconsequential in this case):
  • Physical Disk – R:
  • Network Name – NORTHAMERICA
  • File Share – USERSHARE
• Group 0 — referenced in the article 301588 as EAST FileShare Group, containing a file share resource to which we will apply ABE:
  • Physical Disk – S:
  • Network Name – EASTFILESERVER
  • File Share – named EASTUSERS$,

The first group contains the DFS root implemented as a clustered File Share resource, with dependency on its Network Name and the Physical Disk (R:), where the shared folder hosting the DFS root resides. The share name is set to USERSHARE and its path to R:USERSHARE. You must also select the Dfs root option in the Advanced File Share Properties dialog box, which is displayed after clicking on the Advanced command button of the Parameters page of the New Resource wizard. Once all resources in the group have been created and brought online, you can verify their functionality by connecting to NORTHAMERICAUSERSHARE, using either Windows Explorer or Distributed File System console (listed in Administrative Tools menu).

The second group includes the share EASTUSERS$ pointing to the folder S:EASTUSERS and designated as a standard file share (although hidden from NetBT browsing). This share will become a target of a link under the DFS root configured in the previous step. To accomplish this, select the New Link… option from the root’s context sensitive menu within the DFS console. In the resulting New Link dialog box, type in EASTUSERS in the “Link name” text box and EASTFILESERVEREASTUSERS$ as the “Path to target (shared folder)” entry. Note that as a side effect of this action, a new subfolder with the same name as the link (EASTUSERS in our case) will appear in the folder corresponding to the DFS root (R:USERSHAREEASTUSERS subfolder).

The DFS structure is now in the desired form. Our assumption is that users will be connecting to their respective shares via NORTHAMERICAUSERSHARE path, for which we want to set ABEs. Thus, only the authorized ones will be able to see their data. For the sake of our example, also assume that we created EastUsers_Group domain local group, intended for granting access to EASTUSERS share. We already know the procedure required to configure ABE in a clustered environment. In this case, we simply create a Generic Application resource in the DFS Root Group dependent on the USERSHARE DFS root File Share and set its command line parameter to (assuming other settings are identical to the ones described above):

The last remaining step involves setting NTFS permissions, which happens to be rather surprisingly complicated. First of all, note that access to a DFS target is controlled via its DFS links, which, in turn, are represented by the autogenerated folders residing under the folder hosting the DFS root (R:USERSHARE). Unfortunately, the Security tab of these folders is not available in their Properties dialog boxes in Windows Explorer, so you must resort to the CACLS command line utility to modify their access control list. Although it is possible to assign permissions by pointing the Explorer window to NORTHAMERICAUSERSHAREEASTSHARE, CACLS gives us another benefit that we will shortly take advantage of. For example, to grant Full Control over EASTUSERS subfolder to local Administrators and the built-in SYSTEM account (keeping in mind that the Cluster service account must have at least Read rights, so account for it as well if it is not a member of local Administrators group) and permit EastUsers_Group (from our domain called ServerWatch.com) to read it, you would execute the following from a node that is the current owner of the DFS Root Group (/G switch results in overwriting, rather than editing, existing settings):

CACLS R:USERSHAREEASTUSERS /G BUILTINAdministrators:F /G SYSTEM:F /G ServerWatchEastUsers_Group:R

You should ensure that the same permissions are assigned to the target folder (i.e., S:EASTUSERS), which can be done via Windows Explorer interface. While you might expect this would suffice, our procedure is not complete yet. This is because DFS recreates all its clustered links on failover, resetting permissions based on inheritance, and effectively overwriting the custom ones we assigned. To remediate this behavior, add another Generic Application resource in the DFS Root Group, dependent on the File Share hosting the DFS root, that invokes the very same CACLS command and fixes permissions to match our needs. However, since the CACLS command requires a response to “Are you sure (Y/N)?” prompt, we must somehow feed the confirmation into it. One way to address this issue is to save a text file containing a single character “Y” on the clustered disk (e.g. R:Y.txt) and change the command. Future article will look into more elegant methods of handling such scenarios.

Once the resource is created and brought online, you should be able to verify that regular users who are not members of ServerWatchEastUsers_Group are not able to view the EASTUSERS folder, even if they are permitted to connect to NORTHAMERICAUSERSHARE share.

The next article in this series will conclude our discussion of file system and disk-related clustering features by taking a closer look into Windows Services for Unix and its NFS component.