Inheritable NTFS permissions and preventing user folder access Windows Server 2003/2008

Question

A little bit of background:

We currently use Windows Server 2003 and AD to control users and their data(we are looking at updating to Server 2008 R2 at some point in the medium future, but not immediately due to politics. Hopefully the solution will transfer to 2008 without issues). Users' roaming profile folders(both Windows XP and Windows 7 folders) are stored on a network share that we'll call "Windows_Home". I have read this article: http://technet.microsoft.com/en-us/library/cc737633%28v=ws.10%29.aspx, which is the "Security Recommendations" article from Microsoft, and applied the 'parent folder' permissions to the "Windows_Home" folder only (some of the sub-folders below it gave me permission denied when I tried this, so I guess I'll take ownership of each folder as Administrator individually, and then reapply the permissions again on the parent so they are passed down completely? Then reapply the original owner to the folder and life should be good?).

Each individual's folder(s) are currently inheriting from the parent, to my knowledge, but some have additional permissions I'm not aware of. Should it be only this way(only inheriting from parent "Windows_Home" end of story), or should each individual's folder not inherit the permissions and have their own set of permissions (albeit it'll be the same for each folder, ie Admin + owner + System having full control)?

If it were only to inherit, would this also affect the ability to view another's folders as a different user? For example, the users "jhendrix" and "tpetty" have their "user.V2" folder, which currently can be viewed and files/folders created and opened by the other. So tpetty can navigate through the network to jhendrix.V2 and read his documents and make files, and vice versa. Could this be changed on the parent folder level to say "Only a subfolder's owner and Administrator can access this folder, and no one else?" Or is this only be done on each folder individually, which would be very annoying?

---

Simply put, the goal is to have Microsoft's recommended roaming profile permissions according to the Technet article on the parent and user folders, with only the owner of the folder(who is, of course, a domain user), SYSTEM, and Administrator having full access to it and the contents(so we don't get any temporary profile or partially synched profile issues), while all other users get "Unable to access folder" message when they try to navigate into it. What should I be doing to get closer to this goal? Am I already there? Guidance is needed, thanks much!

Solution

Every time you block inheritance you're cutting yourself off from future flexibility. I avoid blocking inheritance at all costs. You're right to be concerned about it.

I have always thought that Microsoft's recommendations were wrong with respect to this feature. They don't seem at all representative of real world deployment scenarios. I see, at minimum, a potential denial-of-service attack by giving users "Create Subfolder" permission at the top of such an important folder hierarchy. I believe user profile folders (and other per-user folders) need to be pre-created as part of account provisioning.

My standard-operating-procedure for user profile (and other per-user folders) is as follows:

You need users to be able to list the contents of the top-level folder, so I use the following permission:

• SYSTEM - Full Control - Applied to this folder, sub-folders, and files
• BUILTIN\Administrators - Full Control - Applied to this folder, sub-folders, and files
• BUILTIN\Authenticated Users (or a more restrictive group if available) - Read and Execute - Applied to this folder only

Take note: The last permission should be set not to inherit to subfolders (i.e. applied to "This folder only"). This permission allows clients to enumerate the contents of the top level folder but, because it does not inherit to subfolders or files, does not grant any access to the subfolders.

At each subfolder inheritance remains enabled. I just add the user with "Full Control" rights on that subfolder.

You could do this via script, too:

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "x:\Windows_Home\%userDir%" /r /d y
ICACLS "x:\Windows_Home\%userDir%" /reset /T
ICACLS "x:\Windows_Home\%userDir%" /grant:r "DOMAIN\%userDir%":(OI)(CI)F
ICACLS "x:\Windows_Home\%userDir%" /setowner "DOMAIN\%userDir%" /T

You will need the Group Policy setting "Do not check for user Ownership of Roaming Profile Folders" enabled to prevent client computers from complaining about the profile folder not being "owned" by the user. I set this domain-wide as part of my standard-operating-procedure, too.

Comments

[Mr. Starburst]

What's the idea behind having "Read and Execute" permission for the "Authenticated Users" group on the top level folder, as opposed to something like Read and Modify instead? Wouldn't the users only be actually executing things in their profile folder and sub folders, and not in the top level folder, thus rendering execute unnecessary?

[Spence]

The "Read and Execute" for "Authenticated Users" on the top level folder, applied to the top level folder only (not inheriting to subfolders) is to allow clients to enumerate the contents of the top level folder. It should not be set to inherit to subfolders if you want to preserve confidentiality for the users assigned to the subfolders.

[Mr. Starburst]

So essentially it's saying "Users can see that these folders are here in the top level" and then actually lists those folders, but since it's applied only to the top folder, they can only see those folders on the top and then nothing in the sub folders (unless it's their stuff).

[Spence]

Glad I could help out.