Different NTFS Permission on subfolders

Question

I have on our server a folder for each client. Inside that folder there are subfolders for each project that belongs to that client.

My problem is that different resources in the company handle the different projects and should only have access to their projects inside each client.

Right now when a new user needs access to a project I have to go into the clients folder (which is the one that is shared) and grant them access, then into the specific client folder and grant them access, then go inside the folder and select the project and grant them access.

Is there a way to just select the project folder grant them access and have a way that all the folders that are up in the chain grant also access so the user can actually read the files?

Answer 1

If visibility of the subfolders isn't a problem, you might consider adding a permission like "Authenticatd Users / List Folder Contents / This folder only" to the parent folders. This permission won't inherit to child folders, and access-based enumeration won't allow users to "see" subfolders to which they have no access granted, but it would end your need to apply permissions to the parent folders.

Example:

 [ folder ] Clients
     |
     | -- [ folder ]  Client A
     |
     | -- [ folder ]  Client B
     |        |
    ...       | -- [ folder ] Project A
              |
              | -- [ folder ] Project B
             ...

Assuming an inheritable permission at the root of "Administrators / Full Control" and "SYSTEM / Full Control", add the permission "Authenticated Users / List Folder Contents / This folder only" (set in the "Advanced" dialog from the "Security" tab of the folder properties) to the root. If access-based enumeration is enabled this will cause client folders to which the user has been granted access to be visible when listing the root directory. You don't have to use "Authenticated Users", obviously. You could something much more creative.

Assuming you do the same thing at each discrete client folder, authenticated users would be able to enumerate the entire list of clients, but only the projects under each client to which they have access.

Let's say that you wanted to tightly constrain visiblity of folders, though. This is a great application for Active Directory group nesting. In the example below, I'm going to leave out using domain local groups. Technically, Microsoft's best practice is to use a nesting of global groups into domain local groups to which permission is applied. If you're planning on staying a single domain environment (and w/o trusts to external forests) you don't need to follow this practice necessarily. For ease of explanation, I'm going to use only glocal security groups.

Create a new global security group for each project for each role that will be present:

• Client B, Project B - Reviewers - Permitted to read the contents of Client B's Project B
• Client B, Project B - Contributors - Permitted to modify the contents of Client B's Project B

Apply permission at each project folder as described by the names of the groups. The "Reviewers" group would get "Read" permission, and the "Contributors" group would get "Modify" permission,

Create a new global security group for each client:

• Client B Project Participants

Place the two Client B, Project B ... groups into the membership list for the Client B Project Participants group. At the folder for the named client, grant the Client B Project Participants group "List Folder Contents / This folder only" permission.

Create a new global security group for all project participants:

• All Client Project Participants

Place the Client B Project Participants and any other client groups into the membership list for the All Client Project Participants group. At the root folder, grant the All Client Project Participants group "List Folder Contents / This folder only" permission.

When a user joins a project, add them to the appropriate group for the project they're joining. Because of the group nesting and permissions applied, the user will automatically have access to enumerate the root folder and the given client folder(s) for the projet(s) they're involved with.

Answer 2

The issue here is that you may just want to give that user access to the particular project, and that's it, Windows can't know what your intentions are when you add this user to the projects folder, so it does nothing.

You could script something using CACLS, so that you specify the Project folder that the user has access to and it will write the other permissions for you (if they are standard every time)

However Evans solution is a much more elegant way of doing this and once you've got it setup, you can pretty much ignore it.