Boswell's Q&A

The Enforcer

Hide folders from users who have no business accessing them using a nifty feature of Windows 2003 Service Pack 1.

• By Bill Boswell
• 04/05/2005

The formal name of the feature is Access-based Directory Enumeration, or ABE. In a nutshell, ABE gives you, as the administrator, the ability to automatically hide shared files and folders from users if they don’t have access rights.

I hear you say, "Hooray!" I hear you say, "It's about time!" I hear NetWare administrators saying, "Ho hum. Old news. Had it for years."

Yes, folder hiding has been a feature in NetWare since somewhere near the dawn of time (certainly since the late '80s, which is about the same thing). It's a welcome addition to a Windows administrator's arsenal.

Here's how ABE works. Every share has a set of flags that control how data behind that share is presented to a user. For example, these flags say whether a share appears in a Dfs tree and whether the user can cache the contents using offline folders.

Windows Server 2003 SP1 includes a new flag called ENFORCE_NAMESPACE_ACCESS, which I'll call the ABE flag. When the ABE flag is set, users see files and folders under a share only if they have access rights. Otherwise, the files are invisible. This is done completely independently of the "Hidden" attribute, so crafty users can’t override the setting.

When I say that a user must have "access rights," I mean that the user must have at least the bare minimum permissions assigned by a generic READ entry in an Access Control List. The READ entry grants these permissions:

• List Folder
• Read Attributes
• Read Extended Attributes
• Read Permissions

The ABE feature takes effect as soon as the ABE flag is turned on for the share point.

Unfortunately, the Explorer shell does not contain any controls for the ABE flag—that is, no GUI. As it turns out, there’s no command-line tool as well, at least not in the Service Pack. You'll be able to download a utility called Abetool from Microsoft, which will be available prior to the release of SP1.

If you want to do some experimenting with ABE and you don't want to wait for Microsoft, take advantage of a free tool called Shrflags available at http://www.joeware.net. This site is managed by Joe Richards, a Microsoft MVP who has written a variety of nifty tools, including the astonishingly useful Adfind and Admod.

Experimenting with ABE
To experiment with Access-based Enumeration, just download the RC2 version of SP1 (if the final release hasn't already been released by the time you read this) and then download one of two utilities: the Abetools utility from Microsoft or the ShrFlags tool from joeware.

Now, install a Windows 2003 SP1 server in a test environment and create a new domain. Then, either on the domain controller or a member server running W2K3 SP1, run the following script to establish some initial test conditions:

You now have two test users, two test groups with one user each as a member, two test folders under a top-level shared folder, and a set of permissions assigned to the groups and to Administrators.

With these initial test conditions in place, log in as User1 at a workstation in the test domain and map a drive to the SharedFolder share on the server. Open Explorer and select the mapped drive. You'll see both folders. If you try to access TopFolder2, you'll be denied access. This is the standard Windows way of displaying and accessing shared files and folders. No surprises here.

Now leave the Explorer window open and go to the server that hosts the shared folder. Use ShrFlags to view the current share settings. Here’s a sample listing:

Now set the ABE flag on the SharedFolder share point as follows:

Go back to the workstation and press F5 in Explorer. The TopFolder2 folder will disappear. Drill down into TopFolder1 to verify that you have access to the files.

Open a command prompt and change directory to the mapped drive and run dir /s. Only TopFolder1, Subfolder1, and their contents will appear in the directory listing.

Now, at the server, grant READ permissions to Group1 on TopFolder2. (You can grant more permissions, if you like, but READ is minimum.) At the workstation, press F5 in Explorer. The icon for TopFolder2 will magically appear. The folders will also appear in a dir listing at the command prompt. You do not need to log off and back on to see the folder and its contents.

Note: If you add a user to Group1, the user won't be able to see folders with Group1 on the access list until logging off and back on. This part of Windows has not changed. A user needs the SID for Group1 in a local access token before accessing a protected file or folder.

If you remove Group1 from the permission list on TopFolder2 (or Deny READ access), then press F5 in Explorer, the folder will disappear again.

Access to Downlevel Folders
But what if you want to give users access to a folder under another folder where they don't have access? For example, you want to give Group1 permission to read the contents of \SharedFolder\TopFolder2\SubFolder2 but you don't want the Group1 users to see any files in TopFolder1. In this case, you can grant READ permission on TopFolder2 but restrict inheritance to the folder itself, no subfolders or files (see Figure 1).

Figure 1. You can be selective in regards to which folders you provide permission to, even folders at levels farther into the nest, while still restricting access to upper level folders themselves. Nifty trick, eh?

With this setting, the Group1 users can drill down through TopFolder2 to get to SubFolder2 and be completely oblivious to mountains of files around them for which they have no access.

Troubleshooting Tips
If files and folders disappear with seemingly no explanation, I recommend using the WHOAMI utility to verify group membership. This utility is installed by default in Windows Server 2003 and XP. It comes in the Windows 2000 Support Tools. You can use WHOAMI to tell you the groups you belong to, both directly and via nesting. Distribute this tool to every desktop so help desk technicians can use it for troubleshooting.

To see the permissions themselves, I like the Effective Permissions tab in the ACL Editor in XP and Windows Server 2003. You can enter a user name and quickly see what rights the user has to a particular file or folder (see Figure 2).

Figure 2. See right permissions immediately via the Effective Permissions tab.

Try It … You’ll Like It … But Don’t Be Hasty
You'll want to warn your users before you implement ABE in production. It can be very disconcerting when folders just poof and disappear, even if a user never had access to them in the first place. You can imagine the phone calls. "Dave, I just logged onto the R drive and all your financial stuff is gone. Just gone. Cripes, you'd better call the help desk and have them do a tape restore."

With proper training, though, it’s been my experience that users really like this feature. They get nervous when other people see their files, even if the other users are denied access.

I've just scratched the surface of the potential uses for ABE. In my opinion, ABE is one of the major reasons for deploying SP1 in production as quickly as possible.

Until next week!