The short story: when a user has traverse-only rights to the root of a shared folder but full rights to a subfolder, the user cannot browse to the subfolder (correct) but can open the folder using the explicit path & change files in that subfolder (also
both correct), whether via mapped drive or UNC path. However, the user cannot add/delete/copy files to or from that folder when mapped (incorrect), only via UNC path. On the other hand, the user can create/delete files in that same folder, accessed via mapped
drive, using command prompt (inconsistent with above behavior).
I already know I can add List folder contents at the root of the share to overcome this, but that is a right I am trying to avoid, and I am trying to understand the nuance of file security here.
The long story:
In order to keep curious users from simply browsing to certain key shared application folders on my Windows 2012 R2 server (same thing happens on 2008 R2, though), I do several things:
1. Give Authenticated Users only these rights at the root of the drive hosting the share: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions.
2. Create the share as a hidden share. That is, share D:\Apps as Apps$. It is accessible as\\MyServer\Apps$.
3. Give Everyone Change & Read shared (not NTFS) permissions. There is no need for Full Control, since I do not want users to be able to change the share permissions.
4. Add group-based enhanced rights to specific application subfolders to which each group needs access. The additive rights are these: Modify, Read & execute, List folder contents, Read, and Write; in short, the basic rights required to create, modify,
and delete folder contents.
5. Map a drive to the Apps$ share for those user groups that require access to it. For example, my login script maps J: to\\MyServer\Apps$ by non-persistent "net use..." statement.
6. Create a shortcut to the particular application and distribute that to user groups that require it.
The reason for all of this is simple security: these application folders do not house files that users should ever interact with directly; the files are back-end data for which all interaction should be through a front-end application, for example, QuickBooks
company files and MS Access front/back ends.
All of this ensures that:
1. No curious user or malware can even find the shared folder. The hidden share ($) takes care of that.
2. No over-curious user with just enough knowledge to be aware of the default root administrative hidden shares (C$, D$, etc) but with too much time on his hands can browse the drive from the root up by navigating to\\MyServer\D$. Traverse-only at the root ensures this.
3. No curious user can browse for the application folders downline from the share. This is important because the drive mapping exposes the share name to the user, and a user could just double-click the drive letter, then browse and copy/delete a back-end data
file, accidentally or otherwise.
This all works perfectly:
1. Front end applications can appropriately add/remove data from the files based on the logged-on user's enhanced rights to the particular application folder.
2. The application shortcuts I distribute point directly to the files in the downline folders, for example to J:\App1\MyApp.accdb (MS Access application), where J: is mapped by domain login script to\\MyServer\Apps$. The user can open the application and
3. Access to the downline folders is arcane enough that anyone except a very knowlegeable user would ever know that browsing must begin, not at the root of the mapped drive or share, but with the specific folder. That is, an end user cannot browse to\\MyServer\Apps$ or the J: drive mapped there because the user has traverse-only rights there, but the user can get to\\MyServer\Apps$\App1 or J:\App1, where the user has read/write access, so long as the user enters the full path, bypassing the root of the share. I am pretty sure nobody has ever figured that out.
4. In all of this, I have no problem browsing to and manageing all of this when logged on using a domain admin account.
But there is one thing I do not understand: there is a difference in users' file-management rights, not affecting the ability to modify files, depending on whether they access the folder via UNC path or mapped drive. I have one user now that is a developer,
and I created this shortcut for him: J:\HisAppsFolder so he can push applications into that folder. While he can open files there (e.g. open the Access file there and use it, including changes that modify the file), he cannot copy anything to or from the folder
or make changes. On every attempt, he gets a "J: is not accessible" message accompanied by "Access is denied." However, if he instead goes to the same folder using path\\MyServer\Apps$\HisAppsFolder, he has (correctly) full access.
In fact, he can open a text file already in that folder, make changes, and save the changes. This, and the fact that this all works when using UNC-based access to the same folder make it obvious that he has full rights to the folder. However, he cannot copy
anything to or from the folder, even using XCopy. On the other hand, in a command prompt, he can go to J:, then cd to the folder and delete files there via command or create a file by doing something like this: dir > dir.txt.
I have found that only after I add "List folder contents" access to the folder to which I map the drive (or above) can the user fully interact with the downline folder to which he has full rights. But I really do not want to expose the folder list
to users at this level, and the user can already, without this right, list and modify files in the downline folder; he just cannot add, copy, or delete from the downline folder when connected via mapped drive. How is it that List folder contents must exist
at the root of the share in order for a user to have the full benefit of full rights already set on downline folders? And how is it that the command prompt can completely bypass this restriction?
After spending so much time working out all these details, it would be a shame to go away without understanding why this particular limitation exists, why it does not exist within command prompt, and how this all may affect me in the future. I have tested
this on multiple domains and with server 2008R2 & 2012R2.