Get your copy of Windows Server Hacks!
I worked for a while as a network admin for a mid-sized business back in NT 4 days, and one of the things I remember is how curious users are. For example, we had several file servers on our network and each of them had a number of different shares. From time to time when I passed by a user’s desk I’d see them trying to click on a file in some share and getting Access Is Denied. Why did this happen? Because they were trying to open documents they didn’t have NTFS permissions on to read or modify. Yet they often double-clicked on them. Why? Because they were curious.
I mean, who wouldn’t be curious if you found a share on the network named HR (for Human Resources department) and in this share you found a folder named Layoffs and within this folder you found a document named NextMonthsLayoffs.doc. Yikes! Will I be one of those who will be laid off? Click-click…rats.
This scenario highlights one of the weaknesses of file sharing on Windows platforms, namely that by default all users who can access a network share can, at a minimum, see what files and folders there are in that share, even if they don’t have any permission to access them. For example, say you share the folder C:\Budgets as BUDGETS with everyone having Read share permission and the Users group having Allow: Read & Execute ACE on the folder. Say also that within this share is a file named ThisYear.xls and a folder named Previous. Now try this: add user Bob Smith to the ACL for these two file system objects, and assign Deny: Full Control ACE to both of them. Now log onto a Windows XP desktop as user Bob Smith and open My Network Places and browse till you find the BUDGETS share. Double-click on the share and what do you see? A file named ThisYear.xls and a folder named Previous. Try double-clicking on either of them to read the spreadsheet or browse the folder, and you get Access Is Denied. Well, if you, as Bob Smith, are denied access to these items, why are you even allowed to see them in the BUDGETS share?
That’s the whole rationale behind Access-Based Enumeration (ABE), a new technology included in Windows Server 2003 R2. (ABE was actually first included in Service Pack 1 for Windows Server 2003, but this service pack forms the basis of the R2 version of the platform.) What ABE does is just what Windows admins have always been wishing Windows file servers would do—hide files and folders from users who don’t have access to them. In other words, with ABE enabled and configured for the BUDGETS share, Bob can try browsing the BUDGETS folder using My Network Places, but when he looks inside BUDGETS he doesn’t see anything there—his NTFS permissions on the file and folder present don’t allow him to access these items, so they’re not even visible to him. Note that this behavior is the same regardless of whether you explicitly assign a Deny ACE to Bob while granting Allow to the Users group, or whether you remove the ACE for Users and grant an Allow ACE only to groups of users that need it (groups that don’t include Bob as a member) and have no ACE at all for Bob.
The result? If ABE had been available to me to use back in old NT 4 days, only senior management and HR personnel would have known about the existence of the Layoffs folder within the HR share, and no one but these personnel would have known about the existence of a document named NextMonthsLayoffs.doc. In other words, with ABE there wouldn’t have been rumors of impending layoffs flying about—unless they were started by HR personnel or by a manager of course!
Installing and Enabling ABE
When I say that ABE was included with Windows Server 2003 R2 (or SP1), I also need to explain that in order to use ABE you still need to download and install something on your file server. This something is a component that provides a user interface (both graphical and command-line) that allows you to enable and configure ABE on your server. You can download this component here from the Microsoft Download Center, but make sure you download the correct version depending upon your processor platform (x86, AMD64 or IA64). Once you’ve downloaded the appropriate Windows Installer package, install it on all R2/SP1 file servers you want to enable ABE functionality on.
Installing the ABE user interface component is a straightforward process (Figure 1):
Figure 1: Installing the ABE user interface
The only significant decision you need to make during the install process is whether you want to automatically enable ABE retroactively on all existing shared folders on your server, or whether you prefer to configure this manually later on a per-folder basis (Figure 2):
Figure 2: Deciding whether to retroactively configure ABE on existing shares or not
Note that choosing the first option in Figure 2 doesn’t mean that future shares you create will automatically have ABE enabled on them—you still have to manually configure ABE on future shares you choose to create on your server.
Once the ABE user interface is installed on your server, opening the properties sheet for a shared folder will display a new tab for enabling ABE on that share (Figure 3). Note that this tab won’t appear on the properties sheets of folders that haven’t yet been shared.
Figure 3: The ABE tab on the properties sheet for a shared folder
Select the first checkbox in Figure 3 to enable ABE on the shared folder. (Select the second chechbox to do the same to all existing shares on your server). It’s basically as simple as that. To check that ABE is working, compare Figure 4 below, which shows what Bob would see when he browsed the BUDGETS share from his XP machine before ABE is enabled on this share, with Figure 5 showing the same view on Bob’s computer after ABE is enabled on the share.
Figure 4: Before ABE is enabled on BUDGETS, Bob can see everything in it—even if he has Deny ACE on all items present
Figure 5: After ABE is enabled on BUDGETS, Bob cannot see files and folders he has no ACE for (or has Deny ACE for)
Limitations of ABE
There are a few limitations of ABE:
- You need Windows Server 2003 R2 or SP1 in order to be able to use it.
- Users who are administrators will be able to see every file and folder in a share even with ABE enabled and even when they have Deny ACE on these items.
- ABE does not apply to users who can log on interactively to the server, regardless of whether they are administrators or not. This means ABE isn’t really suitable for Terminal Services environments.
- You can’t configure ABE so that a newly created share is automatically ABE-enabled.
- Finally, ABE adds a few percentage points processing overhead to the file server, and this must be taken into account in heavy-load situations.
The good news however is that ABE is built into the new Windows Vista and Longhorn Server platforms and is enabled by default and needs absolutely no configuration on those platforms. So a folder shared on a Vista machine will only show its contents to users who have permissions to access items within it.
Last word on the subject
ABE is a good thing, especially if your company stores sensitive business information on file servers on your network. Remember that a malicious (or merely curious) user can sometimes find out a lot about your business merely by viewing the names of documents stored in shared folders on your file servers. What would an employee do if they nosed around and found a document named OurCEOwillretiretomorrow.doc? Probably sell his shares fast and tell his friends as well, and soon your company will have the SEC or some other regulatory agency breathing down your neck for insider trading!
