Windows Server

Prevent users from seeing objects they cannot access with Access-Based Enumeration

Windows Server 2008 now includes a feature that allows administrators to hide files and folders from users who do not have read permissions to these objects. Derek Schauland explains how this feature comes in handy for network administrators.

On a company network, many different departments have their own shares to create folders and store documents. For example, a member of the marketing team may have read permissions to all or most of the folders in the marketing network share, but probably not to folders in the shares for Human Resources or Finance. Previously in versions of Windows Server, even though users didn't have permissions to access the documents in other network shares, they could still see the folders that held them.

Access-based Enumeration (ABE) is a new feature available as part of the file server role in Windows Server 2008 (and as a download for Windows Server 2003). It will allow an administrator to hide objects from view on an entire server or on a per-share basis.

When enabled for a file share, users who do not have read access to objects would not be able to see those objects. Hiding these objects would prevent nosy (or worse) users from trying to access confidential files and could clear up some of the confusion caused by a bunch of "access denied" messages when trying to open them.

There are a number of privacy or security reasons why the folder names in Accounts Receivable, for example, shouldn't be viewable by the rest of the company. When the ABE feature is enabled on the file server, a user browsing the file share would not be able to see the Accounts Receivable folder at all.

Making use of the ABE feature can help clean up file shares by hiding the folders that users don't need to see, and it reduces the number of calls to the help desk from users who are trying to gain access to things they do not need, whether out of confusion or mischief. It could also keep unauthorized people out of files that do not have appropriate permissions set due to someone's oversight.

Note: The ABE features work only on Server Message Block (SMB) shares. If a user has access to a file server via Remote Desktop, the entire contents of the share will be visible.

Other network operating systems, such as Novell Netware, have had access enumeration features for many releases, leaving one to wonder why Microsoft has waited so long to introduce it. The argument is that the feature isn't needed if properly configured permissions on objects are already in place, but that doesn't necessarily cover all the reasons one might want to hide the names of certain folders.

You can download ABE for Windows Server 2003 Access-based Enumeration. Windows Server 2003 SP1 is required to install the feature.

About

Derek Schauland has been tinkering with Windows systems since 1997. He has supported Windows NT 4, worked phone support for an ISP, and is currently the IT Manager for a manufacturing company in Wisconsin.

16 comments
Atul_R
Atul_R

It works fine when the folder is mapped, it does not show the folders with No Read permissions for a particular user. But when the same user makes RDC to that server it gets to view the folder name. Of course he is not able the access the folder as he gets access denied message but he does gets to see the folder names. I don't want the users to see the folder names. Folder to which they don't access Read access should be hidden from them even when they RDC to that server.

gijoemarine
gijoemarine

Well, it is about time. I had this feature on my Novell network over 10 years ago.

Hagstrom
Hagstrom

We us it for our file-server, it's great! Everybody gets a mapped drive to the same place, but they only see what they have access to. Way less confusing for the end users. The only very frustrating part is it only works with SP1, it doesn't work with SP2! Or is there a newer version available? Maybe can make a copy from the Win2008 disk which will work with Win2003 SP2?!

bulk
bulk

If you combine ABE with DFS, you should consult KB 907458, "How to implement Windows Server 2003 Access-based Enumeration in a DFS environment" otherwise ABE may not work as you expect. RS

wdewey@cityofsalem.net
wdewey@cityofsalem.net

I see this as a way to hide complexity from users that don't need to see it. I have found that if a user only can see the directories that they use then it makes them a lot happier. Bill

atuldeshmukh
atuldeshmukh

Its a great utility i have used this utility in server 2003 abeui.msi on the file server, it comes handy when you don't want others to let other users to see what data is there created by other users on the file server

waltrutka
waltrutka

if you remove the tab character before compiling with watcom the objects shut down properly in the exectronic journal

Gis Bun
Gis Bun

Unless I missed something ABE works only if you are specifically setting security on the share iyself and not just the folder. By default Windows Server 2003 assigns the "everyone" group with "read" access on the share. Although not a perfect practice [and against Microsoft's certification requirements], we remove "everyone" and then add "authenticated users" giving that group full access on the share. We then use file and folder permissions to apply the security we want for the folder [and below].

TG2
TG2

that's right.. so now the cracker just has to remove the read option from files and folders to hide them from an adminstrator login.. gee thanks.. I really need another "I_love_you.txt.com" virus or other hidden content that the cracker can place there, and the administrator can't see.. as if root kits weren't enough. Why doesn't microsoft learn from their mistakes? I can see this as a great thing for admins to block the average idiot ... but again, it only gives another tool to the BAD people out there.. just like with the "I love you" virus.. you would have thought after that massively well known infection, that microsoft would have STOPPED defaulting to hidden files, folders, and extensions.. not enough good comes from hiding files and folders, and too much bad can come from it.. let your users question that folder they see.. if they can't open it..they can't open it.. that's a pretty f**king simple concept for a user to learn.. why try to color every window rose colored only to make the idiots unaware?

ted.mccarty
ted.mccarty

Hi Derek, my problem with Vista and I assume Win 7 is that I cannot totally restrict user access to files that they do have read access to. Files like MMC.EXE and REGEDT32.EXE. Yes I know the Party Line that they really can't do an major damage because they have limited use of the files but we don't want them to even know that they exist. With XP I can easily remove their access rights to almost all files but with Vista I have to take ownership of the files. At that point I have probably taken at least some of the access away from the "Trusted Installer" phantom user. No one seems to know what damage that will do in the future. Why did they take those important rights away from administrators? No one at M$ will even talk to me about this issue. Ted McCarty

bulk
bulk

Much MS documentation gives you the impression that ABE works exclusively on shares. It doesn't. It works on folders that are usually accessed using shares. You switch it on by accessing the properties of a folder that is shared. I'm guessing if a user logged on locally that an ABE-protected folder would not be displayed if listed locally. Imagine a share named users$ that has individual subfolders for each user. If the user browsed to user$, without application of ABE he'd see a long list of everyone's home folders. With ABE he'd see just one, his own, the only one that he has at least "list" permission to. So ABE enhances your practice as in your 2nd para above, by "hiding" folders your users cannot access. ABE tweaks the way NTFS attributes are used to display folders in explorer and dialogs. It does not tweak the way shares work, although I grant you it may also hide shares if the perms on the actual share don't allow list/read, I've never tried that as using the "$" suffix is usually enough. See the MS doc at http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx RS

Nimmo
Nimmo

All this is doing is adding security by obscurity you still set your permissions as usual. I can see why people say it's useless but I can also see a benefit (if it isn't there people are less tempted to try and explore it. Obviously if there is someone malicious accessing the network either internally or externally the benefit of this is lessened. As for hidden malware as stated above if you?re the administrator you are able to see all files/folders. It just complements your security

Gis Bun
Gis Bun

I guess you don't get the concept. This hides folders for those who don't have PERMISSIONS to the share. As an administrator you should have access to everything.

Aakash Shah
Aakash Shah

Anyone who is trying to compromise your systems know that mmc regedit exist. Rather than simply trying to hide them and potentially breaking future update (since your are changing the security permissions), you should use Group Policies to prevent any access to them. Block registry access: http://www.mydigitallife.info/2008/12/23/how-to-disable-registry-editor-editing-tool-regedit/ Block MMC and snap ins: http://technet.microsoft.com/en-us/library/cc722167(WS.10).aspx This will also allow you to set this policy more easily on multiple computers almost immediately (within the group policy interval time) and will prevent you from either manually going to each computer and changing the permissions or manually scripting the permissions changes. Also, this will prevent breaking any updates in the future.

Esher72
Esher72

I come from a MS background and have always understood the "I see it but when I click on it, I get Access Denied" issue. Hell, we have put a folder out there named "Secret" and audited attempts to open it just for fun. However, the company I work at currently has been a Novell shop for ever. We have recently been sold and the new company has in the words of our CIO, "drank the Microsoft kool-aid." I hear constantly about how "Novell could do this" and "Novell could do that" from the old admins that are resisting the change. The biggest complaint from the legacy Novell admins and management alike has been that people can see folders that they could not before. They simply do not like the concept. Management is a skittish bunch and yes we do have to save them from themselves sometimes but this doesn't seem so bad to me. It sits on top of existing security, it doesn't replace it. It gives the typical end user (we are in the south)a simpler view. I was not even aware this existed for 2003. I may test it out on one of our low priority file servers tomorrow. Just to silence the Novell lovers. If simply hiding a file takes out your file server then one of two scenarios has occurred. The first is that it was such a well orchestrated attack that there was not much you could have done to stop it. The second scenario is that you are a crappy admin that has not done their job. This may sound a little Darwinian but in this case, you need to get creamed. Your company will come back stronger for it or the market will simply cull the herd. If the company comes back maybe you will come back as a better admin for having been burned... or there will be an opening for someone else. In this market, that wouldn't be too hard to fill. The guy that delivered my pizza the other day had an MCSE and a CCNP. I chatted with him a bit and I don't think he was a "paper MCSE" either. Just my 2 cents.

Editor's Picks