Mark Minasi's Windows Networking Tech Page
Issue #54 March 2006
To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp. RSS feed at http://www.minasi.com/rss.xml. Document copyright 2006 Mark Minasi.
What's Inside
- News
- New 10-CD Set "Securing Your Windows Systems" Available
- I'm Going to Tech-Ed!
- The Skinny on Mastering Windows Server 2003, Second Edition
- Tech Section
- Hiding Folders From Prying Eyes: Access-Based Enumeration (ABE)
- Conferences
- Bring a Seminar to Your Site
News
This month, I'm happy to write about something that many readers have wished for over the years -- the ability to hide folders and files from people who don't have the permission to read those folders or files. Even better, you probably already have the code to make it work on your computer if you're running 2003 SP1 or 2003 R2. It's been saddled with the awful name of "access-based enumeration" but no matter what you call it, it's useful and you can read about it here. But first, a word from our sponsor...
New 10-CD Set "Securing Your Windows Systems" Available
For several years now I've been doing my two-day security seminar, "Securing Your Windows Systems." I love teaching that two-day class and am grateful for the very positive response that I get from audiences. But as with my Windows 2000 and XP classes, many people tell me that they just plain can't get to a seminar either because I'm not doing one nearby, or they can't afford the cost of the seminar. Furthermore, this year will keep me so busy creating my Server R2 and 2003 SP1 book and the Windows Vista book that I'm just not going to have the time to offer any public seminars. So, as with the 2000 and XP seminars, I'm offering the Security class as a set of 10 audio CDs for an introductory price of $225, or $125 for those who've already attended my one-day or two-day Security seminar. If you're interested, please take a look at www.minasi.com/seccd, and thanks.
I'm Going To Tech-Ed!
To speak, that is. Woo-hoo! If you're going to be at June's Boston Tech-Ed then please plan to attend my talk "Using What You’re Not Using in SP1/SP2: Discover Service Pack Gold!"
The Skinny On Mastering Windows Server 2003, Second Edition
Many of you have written to me asking if there will be a second edition of Mastering Windows Server 2003 to include the changes brought by Service Pack 1 and Server 2003 R2. Originally I wanted to revise the whole book but my new publisher (Wiley bought Sybex last year) and I decided instead to put out a smaller, "Special Update Edition" of Mastering Windows Server 2003. The idea is that it'll be smaller than the original book, and will only cover the changes wrought by SP1 and R2. So for those looking for an SP1 update or an R2 update it'll be a convenient add-on to the existing book. Look for it in late summer. (Actually, if you read this newsletter I'll be announcing it as it arrives.) So the bottom line is, if you're thinking of buying Mastering Windows Server 2003, then don't worry about built-in obsolescence. Instead, get it and work through its 1800 pages and, by the time you're done, we'll have 400 or so more ready for you.
Tech Section
Hiding Folders From Prying Eyes: Access-Based Enumeration (ABE)
Over the years, I’ve gotten literally tens of thousands of pieces of e-mail from readers, so of course there are a few very frequently-asked questions. Here’s the single most common question from ex-Novellians:
“In Novell, users couldn’t even see folders that they had no access to. If you couldn’t read the folder, then it was invisible. How do I do that in Microsoft networking?”
I always had to answer the same way: “sorry, we can’t do anything like that in Windows. If a user doesn’t have access to a folder, however, then she can’t really do anything to that folder except see that it exists. But it is a shame.” An accurate answer, but a lame one -- but fortunately I don’t have to give that lame answer any more. Windows Server 2003 SP1 and R2 have a new feature that lets you tell a server, “when you’re listing the files and folders in a share, check that whoever asked to see that list of files and folders has at least ‘read’ access to each object. If he or she doesn’t have read access to a file or folder, then don’t show that file or folder.” This new feature might have been called “Novell Invisible Folders: Terrific! Yes!” or NIFTY but is instead called Access-Based Enumeration or ABE.
How ABE Works
ABE is a feature of the Server service, the Windows service that provides file and printer sharing. It works by modifying a feature of the Server service called “enumeration,” which basically means “how the server service answers the question, “what files and folders in a given share?” Windows Explorer does the same thing when you open up a folder. You know that flashlight that shines around the folder for a second -- well, a second on a good day -- when you open a folder? That’s Explorer entertaining you while it enumerates the folder contents.
ABE boils down to just a simple change in how the Server service handles an enumeration request from your client computer. Suppose you’re sitting at a client computer called Client and you’ve connected to a share named Stuff on a file server named Bigserver. You want to see what’s in that share, and so your client computer Client, you either open a command prompt and type a DIR command to see the share “Stuff”’s contents, or you open up a folder in Explorer to see the Stuff’s contents, and that gets translated by your computer into a “hey, Bigserver across the network, would you please enumerate the Stuff share?” Where the Server service on Bigserver used to just look in a file share for the share’s contents and report everything that it saw in that folder to your computer, now the file server service looks at the NTFS each file and folder sitting in the share and compares that to whatever user account you used to connect to the share. Then the Server service says for each file or folder in the share, “does this person have permission to read this file or folder?” If you do have the permission, then the enumerator tells you the file exists. If not, the enumerator is silent about it.
(Why is the file server service called the “Server” service rather than the “file server” service? After all, we don’t call the DNS server service, or Internet Information Server the “Server” service, so what makes the file server special? It’s not arrogance on the file server service’s part, it’s just that way back when Microsoft started writing network software, their servers did just one thing -- file and print serving. So back in the old days, “server” meant “file and print server.” The name just stuck. That also explains the odd name for the client software for the file and print server; it’s called the “Workstation” service.)
Does ABE Matter?
While this will warm the hearts of some, it’s worth stepping back and asking, “is ABE really useful?” I mean, the first time that a Novell guy explained the hide-the-folders-you’re-not-authorized-to-see feature, I thought “dang, that’s cool -- I wish we had that!”
But then I thought about it. I’d thought that hiding inaccessible folders would be a nice feature for reasons of security, and so did just about everyone who asked me about how to accomplish it in Windows. The main argument went something like this:
Many network administrators offer home directories to their users, folders that are only accessible to the user and, perhaps, the administrator. It’s a pain to have to create a separate share for every single user, though, so most folks put all of the home directories in one folder and then share that folder. So, for example, a network might have a share called “Homedirs” that contains a folder for every user. But that means that when the user connects to the Homedirs share, then she sees not just her folder, but a folder for every other user. And that troubled a lot of admin types.
But is it really bad for one user to be able to see, but not access, the home directory folders of all other users? It’s a matter of opinion. If the administrator’s done his job, then he’s set the NTFS permissions on each folder so that, again, no one can get to that folder save for the person who uses it as a home directory. But administrators don’t like that Sally can see that there’s a folder for Larry, and Paul, and Jane and so on. Why don’t they like it? Well, there’s an argument that it’s something of a security breach, as any user can pretty much get the list of all user accounts by just looking at the names of the folders in the Homedirs share besides the user’s personal folder. That sounded good at first, but upon a bit of reflection I have to say that I don’t buy it. You see, every user in an Active Directory has read access to all of the AD. That means that any user who wanted to could just cook up a quick VBscript program to dump the names of all of the user accounts anyway. So arguing that hiding inaccessible folders in the Homedirs share is a security measure is specious -- just something that provides the illusion of security, not actual security.
So is ABE pointless? No, absolutely not! While it may not be all that big a deal security-wise, it may make get some security auditor with a silly checklist off your back. Furthermore, what you’ll like about ABE is that it simplifies things for users.
Forget the scenario about the evil user writing down the names of his fellow users. The more likely scenario is the perfectly honest user in a firm of 500 people who logs onto the home directory share for the first time… only to be greeted with the vision of five hundred folders. With ABE, he would only see one folder… his personal home directory folder.
So in the end analysis ABE is useful. But it’s useful less as a security tool, and more as a productivity tool -- at least in my opinion. But quibbling aside, let's see how this neat tool works.
Isn't ABE the Same As Hiding A Folder with "$"?
Since I wrote this, I've gotten a few e-mails from people reminding me that it's always been possible to put a "$" a the end of a file share's name and thereby to hide that share from people. For example, if I created a share with my games on it for my convenience -- perhaps to be able to easily install those games on other systems without making them obvious to others -- then I might create a share called not \\myserver\games but instead \\myserver \games$. Then, when people browsed MYSERVER's shares from either Network Places or the NET VIEW command, then they would not see the games$ share.
There are two reasons why this is different from ABE.
First, ABE does not hide entire shares. ABE hides folders within shares. So, for example, if I had a folder inside my hypothetical "games" share named "markscreditcards" then I just might not want people to be able to get to that folder. I might not have a problem with them finding the games, or the "games" share itself, but \\myserver\games\markscreditcards -- no way I want them to even see that exists. So I just yank out everyone's NTFS read access to the "markscreditcards" folder. Now, anyone opening up the \\myserver\games folder will see whatever folders are in the "games" share -- except the "markscreditcards" folder. (And yes, this is a silly example -- I'm just trying to underscore what ABE does.)
Second, that "$" thing at the end of a share isn't very good security. I was quite surprised years ago when I did a network trace to see what happens when I browse a server via what was then called Network Neighborhood. As it turns out, your workstation says to a server, "tell me the names of all of your shares," and the server sends them all along -- even the ones with the "$" on the end. It is the software on your workstation, not the server, that filters out the ones with the "$" on the end of their share names, meaning that a bad guy could just write some revised Network Neighborhood software. In contrast, ABE does the filtering on the server, so the workstation never sees the hidden files.
If that's still not clear, try following along with the example that I'll build here to see the difference before and after ABE.
ABE Details
That’s the big picture. But there’s more to know:
- ABE only works on Server 2003 SP1 and later systems; XP, 2000 and the rest need not apply.
- The ABE code is installed on a 2003 SP1 or later system, but it’s not enabled by default.
- You can choose to turn ABE on for all shares on a system, or just a few.
- To see an ABE-protected file, you need a specific set of permissions.
Here are the details.
ABE Must Be Enabled
Any system including 2003 SP1 or later -- which means any R2 or, for that matter, any Longhorn Server system -- has the ABE code sitting on it, but it’s not enabled. To make it work, you need a tool to turn it on. You can find that tool at Microsoft’s site, as I’ll discuss in a bit.
Again, it’s 2003 only; you cannot, and probably will never be able to make ABE work on a 2000- or XP-based system. But don’t misunderstand; 2000, XP, even Windows 98 users can see the effects of ABE, as all of the work of hiding the share’s files and folders is done by the file server holding the share, not the client operating system. So, for example, if that file server Bigserver holding the share named “Stuff” was running Server 2003 with SP1 installed, and the client named “Client” was running Windows 2000 Professional, then that user on Windows 2000 Professional would still not see folders on the Stuff share for which the user lacked read access. When I say that 2000 will never use ABE, I mean that a file server running Windows 2000 Server cannot hide files and folders in shares from users based on their NTFS permissions.
ABE Works on Both Files and Folders, And Only in Shares
I’ve mentioned this before, but I wanted to clarify that ABE will not only hide an entire folder, it can also hide particular files. As with folders, the question of whether or not ABE shows a given file is all a matter of the NTFS permissions on that file.
Furthermore, ABE only affects the way that users see the contents of file shares. Someone actually sitting at a computer and using Explorer to browse the files and folders on a system would still see files and folders that he or she can’t read, as has been the case for ages in the Windows world.
ABE Works On All Shares, or Some Shares
In my experience, in general no one wants to hide files and folders in shares based on those objects’ NTFS permissions. If someone creates an Accounting share, then they just set the folder permissions so that only folks in the Accounting department can connect to the share in the first place, and so do not need to hide particular objects in that share.
But, as I’ve suggested earlier in the “Does ABE Matter?” discussion, there is one exception to the “if you’re here, you should probably be able to see everything rule, and it’s a big one -- home directories. I suspect that most folks will find ABE most useful for just the home directory share.
The bottom line here is that ABE doesn’t make sense for a lot of shares, and it does slow things down a trifle. So some folks will want to tell their file servers not to bother ABEing some shares, and to ABE others. You’ll see how soon, when we see how to install and configure ABE.
What ABE Needs For Permissions, Specifically
ABE hides files and folders from people who don’t have the NTFS “Read” permission, says Microsoft’s documentation. But what exactly does that mean? As you probably know (or can remind yourself of by reviewing Chapter 11 of Mastering Windows Server 2003), looking at the Security tab of any object gives you a kind of high-level view of permissions. But clicking the Advanced button in the Security tab, and then the View/Edit button shows you the lowest-level permissions. A bit of experimentation shows that to show you a file or folder, ABE wants to see that you have the following four specific permissions:
- List Folder/Read Data
- Read Attributes
- Read Extended Attributes
- Read Permissions
Of course, someone could have more permissions than these and see a file or folder via ABE. But lacking any of those four will make the file or folder disappear.
An ABE Example, Part 1
Before we continue, let’s set up an example system to use to play with ABE. (If you’re not interested in a step-by-step example, then just skip this section and go to “Installing and Configuring ABE,” the next section.) First, we’ll need a system running either Server 2003 with SP1 or an R2 system. Give it any name you like; I called mine “R2STD” because it’s Windows Server 2003 R2, Standard Edition. My intention in this example is first create a home directory folder on R2STD, then create two folders inside that folder -- one for a user named Paul and one for a user named Sally. I’ll set the NTFS permissions so that only Paul and Sally can access their folders (well, we’ll let the Administrator work with the folders as well), share the home directory folder, and then install the ABE UI. We’ll enable ABE on the home directory share, and the have Paul look in the home directory share. If all goes well, then he’ll only see the “Paul” folder; Sally’s folder will be invisible.
Now, it’d probably take a dozen pages of click-by-click explanation to set all of this up, so let’s make this a bit more concise by just using the command line. (Besides, it’s a great example of how much you can get done with just a few commands.) Make sure you’re logged onto your server as an administrator. Then open up a command prompt and type in these commands:
md c:\homedirs md c:\homedirs\paul md c:\homedirs\sally net user paul Paulie1 /add net user sally Sallie1 /add net share Homedirs=c:\homedirs /grant:"authenticated users",full /remark:"Home directories share" echo y|cacls c:\homedirs\paul /g administrators:f paul:f echo y|cacls c:\homedirs\sally /g administrators:f sally:f
What’s all that do? If you’re not a command-line black belt, here’s the above, dissected.
The first three commands use the “md” or “make directory” command to create a folder named Homedirs, and then to create subfolders of Homedirs named Paul and Sally. The next two commands create local user accounts called “paul” and “sally” with passwords “Paulie1” and “Sallie1” respectively. Uppercase or lowercase doesn’t matter in either the md or net user commands, except of course for the password text itself -- if Paul tries to log on with password “paulie1” he won’t succeed, as we typed it in “Paulie1” with a capital “P.”
The next command, the “net share” command, is a long one and wrapped on the printed page but should be typed as one long line. “Net share” says that you’re going to create a new shared folder. “Homedirs=c:\homedirs” means to give the new share the name “Homedirs” and that the actual directory to share is the one at c:\homedirs. The “/grant…” option says to set the share permissions on Homedirs to Full Control for the “Authenticated Users” group, and the “/remark:” option lets you put a comment on the share.
Thus far, we’ve created the folders, the users and the share, as well as setting the share’s permissions. But we’ve still got to set the NTFS permissions, and for that we can use the CACLS (“Change ACLS”) command. I know, the lines don’t start with “cacls,” they start with “echo y|” but that’s only because of an annoying feature of cacls -- it always stops and asks, “are you sure?” The beauty of prefixing the statement with the echo command is that the echo command automatically answers the “are you sure?” question. The cacls commands break down like this:
cacls directory-to-work-on /G username:permission username:permission...
The /G stands for “grant” as it grants permissions. It removes any existing NTFS permissions on, for example, c:\homedirs\paul and installs the ones in the command. “administrators:f” means “grant the ‘administrators’ group Full Control,” and of course “paul:f” grants Paul full control of his directory. The following command does the same thing for Sally. Now that the stage is set, let’s return to our discussion of ABE.
Installing and Configuring ABE
Ready to see ABE in action? Let’s see how to get the ABE user interface, install it, and configure ABE.
Download ABE from Microsoft.com
As I said before, all of the machinery for ABE is in your 2003 SP1 or R2 system, but Microsoft chose not to throw the switch. To do that, you need a file called ABEUI.MSI. Surf over to Microsoft’s Downloads site at www.microsoft.com/downloads and type into the Search field “access-based enumeration.” (It’ll work with or without the quotes.) As I write this, you’ll only get one hit, one with the title “Windows Server 2003 Access-based Enumeration” dated 8 April 2005. I would give you a specific URL rather than have you search, but for some reason it appears that there’s some guy at Microsoft who’s job it is to re-arrange the Web site every two weeks -- so the search works. If it doesn’t, try another search, but this time type in the name of the file that we’re looking for -- “abeui.msi.”
Click on the link, and you’ll end up at a page that offers a brief explanation of ABE, and offers three download hyperlinks: one for systems using standard 32-bit Intel processors, one for people using Itanium-based servers -- and wasn’t it thoughtful of Microsoft to create a whole new version of abeui.msi for those seven people? -- and finally a version for systems using either AMD or Intel’s 64-bit processors. Choose the one that’s right for your system and download that abeui.msi to your system.
Install ABEUI.MSI
Double-click abeui.msi and that’ll start up a wizard that installs ABE’s user interface. The first panel shows you a paragraph that basically explains ABE; click Next and you’ll get the obligatory software license; accept it and click Next. That’ll take you the screen that asks where you want to install the ABE user interface files (the default is fine), and who should be able to use the ABE user interface -- either just you or everyone. Choose whichever option works for you and click Next. That leads you toe a screen like the one in figure 1.
Figure 1: Turn on ABE now or later?
Just take the default; in a moment I’ll show you how to turn ABE on or off. Click Next and it’ll ask you to confirm that you actually want to install the ABE UI. Click Next, it’ll install, and then click Close at the “Installation Complete” page.
If you’re following along on the example, go ahead and get the version of the ABE UI for your system and install it. Go with all of the defaults except to click the “I accept” radio button on the license page.
Configuring ABE
Now that you’ve got ABE’s UI installed, you can do several things:
- You can turn ABE on for all shares
- You can turn ABE off for all shares
- You can turn ABE on for particular shares
- You can turn ABE off for particular shares
You’ve also got both a command-line and a GUI tool. First let’s look at the GUI. If you’ve got the ABE UI installed on a system with a shared folder, then right-click that shared folder in Explorer and choose Properties. You should see a new tab, “Access-based Enumeration.” Click it and you’ll see a dialog box like figure 2.
Figure 2: Initial ABE tab
Now, GUIs are supposed to be easier to use than command-line tools, but this one’s a little odd. I would have expected a check box somewhere that would let you just check the box and cause ABE to be turned on for all shares or, for that matter, to cause ABE to be disabled for all shares, but it doesn’t really work like that. The first check box lets you enable ABE for the particular share that you’ve clicked, as a casual read of the label next to that check box will show. But look at the second one -- “Apply this folder’s setting to all existing shared folders on this computer.” Hmmm. Oh, now I get it -- to turn on ABE for all shares, go to any one share and enable ABE for that share, then check the box that applies that folder’s ABE setting to all shared folders. Kinda awkward, yes -- you’d think that there would be a Control Panel applet or the like that would let you turn it on or off universally. But no matter; the command line makes it easier.
After installing the ABE UI, you’ll have a new command line tool “abecmd.” It looks like
abecmd [/enable|/disable]{/all|sharename} [/server servername]
Or, when rephrased from the Geekish:
- First type “abecmd” followed by a space,
- then you must type either “/enable” if you’re enabling ABE, or “/disable” if you’re disabling it, and
- then you must either type “/all” if you want this enable or disable command to apply to all shares, or type the name of the share to have it apply just to that share.
Finally, you may optionally type “/server” followed by the name of a server to assert control of ABE across a network. For example, “abecmd /enable/ all” would tell ABE to enable itself for all shares on a system. “abecmd /disable /all” would universally disable it. To tell the system to only enable ABE for the Homedirs share, type “abecmd /enable homedirs.”
An ABE Example Part 2
Time to return to our example. Let’s turn on ABE for the Homedirs share and demonstrate that Paul will only be able to see his folder… but the Administrator will be able to see both Paul and Sally’s folders. As you just saw, you can turn on ABE for Homedirs by opening a new command prompt and typing
abecmd /enable homedirs
You’ll get a response like
Access Based Enumeration enabled on share “homedirs”
If you like, or if you’re naturally skeptical, then right-click the Homedirs share in Explorer, choose Properties and the Access-based Enumeration tab and you’ll see that the ‘Enable access-based enumeration on this shared folder” check box is now checked. At this point, if Paul looks in \\r2std\homedirs then he’ll only see a Paul directory, not a Sally directory. We could see that in action by logging off from the Administrator account and logging on as Paul, but that’s too much work. Instead, we’ll open up another command prompt and we’ll use the “runas” command to open up that command prompt as Paul. Any commands in the “Paul” command prompt will run as if Paul typed them. We’ll have two command prompt windows, then -- the one we’ve already opened as Administrator, and another as Paul. Better yet, let’s open up Paul’s command prompt window with a blue background so that we can keep track of which command prompt window is which. To accomplish this, type this in the current (Administrator) command prompt:
runas /noprofile /user:paul “cmd /k color 1f”
You’ll be prompted for Paul’s password, which, recall, is “Paulie1,” and then press Enter. You should get a second command prompt window with a blue rather than a black background.
Now, in Paul’s (blue) command prompt window, type
dir \\r2std\homedirs
And press Enter. You should see a “paul” directory but no “sally” directory. Now go to the old command prompt window, the one where you’re logged in as Administrator, and try that command again. You’ll see both directories. Neat, eh?
ABE’s a nice SP1 freebie. By keeping prying eyes from seeing shared files and folders that those eyes aren’t supposed to see, ABE helps reduce the temptation to play internal hacker. And by reducing the clutter of files and folders presented to the average user, ABE can help make your network more productive.