I'm currently building a new AD network so that we can migrate to it from Netware. Once again I apologize for being so clueless. If it’s any consolation, I’ve looked high and low, tried lots of things but I’ve ultimately ended up back at this point which is where I started at.

On my file server I’ve got the following folder structure:

DATA01\Staff\Faculty\
-Faculty01
-Faculty02
-Faculty03

I’ve set up Sharing at “Data01” so Everyone has change and read.

I’ve have a group called “Staff” and given it “List folder contents” permissions to the “DATA01\Staff” folder.

I’ve given a group called “FacultyTest” full permissions to the “DATA01\Staff\Faculty\Faculty01” folder.

Questions

1. Is setting up a single share at the “Data01” folder (Everyone has change and read) a good way to do it?

2. Logged in as a member of “Staff” and “FacultyTest”, If I browse to the “DATA01\Staff\Faculty” folder I can see all the files and folders. How can I restrict the view to files and folders where users have no rights? eg in the above mentioned scenario, how could I have a user have access to a faculty folder and only see the individual faculty folders that they need as opposed to all the faculty folders?

The end result that I would like is all staff to have the same drive mapping to the “DATA01\Staff\Faculty” but only see the individual faculty folders that they are a member of.

17 Replies

data01 shouldn't have a lot of permissions, those should be reserved for further down the chain- remember, someone with change permissions can still screw up the folder structure for the shares further down the hierarchy. Unfortunately, as the faculty folder is the object, and the lower folders are members of it, you aren't going to be able to set the view for them. You can however restrict the access inside of the folders that they aren't allowed access to by just allowing only those members who need access any access to the successive folders.

remember

Data01-

--staff-

---faculty-

----department-

each folder is a sub object belonging to the object above it. while in the faculty folder, one would be able to see all the sub-folders, however if one wasn't a member of the department, opening the department's folder would be useless as they are denied read/etc.

Also- be very careful of what permissions you grant, and at what level- inheritance can completely screw up good intentions. If you give read and change at the highest level, it will propagate down to the lowest level. You would have to explicitly deny at the lower levels in order to keep people out of where you don't want them.

I've now set the Share at Data01 to so Everyone has read (removed change)

Your example of using department would have been better than Faculty01, 02, 03 etc. Sorry.

Currently I can see all files and folders. The only way I can block this is to create a share at each department level. I can still see the all the department folders but can't get any further than that.

I actually started out doing this way but thought there must be a better way than having a share for each folder (there's around 50 department folders). Then I read a few places that some people just set the share at the highest level and do the rest with permissions.

Microsoft documentation says:

"Another approach is to set share permissions to Full Control for the Everyone group and to rely entirely on NTFS permissions to restrict access."

I realize this will more than likely create a massive flame war, but that seems like that wrong way to do it. I would always start with the most restrictive permissions first, and open them up when needed. True, creating one share is easier to administer than 50 shares, but a single share with screwed up permissions is going to cause more headaches than 1 out of 50 shares with screwed up permissions.

I guess it also depends on how you want to manage and share those documents- is it more of a case that all the departments really use the same documents, so it's pointless to break them out, or is it a case of someone in management doesn't want to remember multiple shares?

Always remember that the share is just the doorway, it doesn't apply any permissions. In general at the top level doorway share I give authenticated users full access to the share. Then you can get as granular as you want with the NTFS security. You may also want to look into domain local security groups for access to files and folders as it makes it easier to manage a group instead of assigning individual permissions to individuals.

Let me add my 2 cents to this discussion. I was taught a long time ago (NT4.0 days) That you give maximum permissions with the share settings and take them away with the folder security settings.

You can not grant rights with FOLDER security that are not available under the SHARE settings.

I User A has read only SHARE permissions then they can NEVER be granted anything higher in the Folder Security settings.

Give with share permissions - take away with folder security.

Another issue is you can turn security rights inheritance on or off for any given folder. If a person has full rights to a folder then with inheritance they have full rights to any sub-folder. With inheritance turned off then you have to set security for each and every folder and sub-folder.

Let me add my 2 cents to this discussion. I was taught a long time ago (NT4.0 days) That you give maximum permissions with the share settings and take them away with the folder security settings.

You can not grant rights with FOLDER security that are not available under the SHARE settings.

I User A has read only SHARE permissions then they can NEVER be granted anything higher in the Folder Security settings.

Give with share permissions - take away with folder security.

Another issue is you can turn security rights inheritance on or off for any given folder. If a person has full rights to a folder then with inheritance they have full rights to any sub-folder. With inheritance turned off then you have to set security for each and every folder and sub-folder.

This is the same structure I use on our network. I don't like to see a lot of shares when people browse the network. It creates a lot of questions and sometimes worries from administration that too much is showing and maybe someone has access to something.

For example, I have one share that everyone can see called User Folders. Then I give permissions to the folders inside that others want access to. They only see those folders that they are allowed see. Several folders are given permissions that let everyone access them. I have an Software folder with general applications that everyone can and usually do have installed on their computers. Then inside that I have a Restricted Software folder that only admins can see inside, for more specialized software. I have a printer driver folder that has all the printer drivers we have on our network so I can install any printer if Windows doesn't find the driver through AD, available to everyone. I have a Temp folder that anyone can access which is mostly used by me to help someone transfer a file to someone else that they couldn't otherwise get to. Plus there are other folders. I don't have a document management system yet like SharePoint.

My first attempts were to make a lot of folder shares but I think I messed things up because things started to behave strangely. Going back to a single share then giving rights to users via groups seems a lot easier, but having folders visible to users that can't access the content will be an issue. Apart from anything else I don't like the idea of a uaser opening the faculty folder and seeing 50-60 department folders when they are a member of only a few departments.

I've tried using the namespace with the $ at the end. That pretty much killed everything (I think I misinterpreted what this was going to do!).

I've now tried enabling Access-Based Enumeration on the Namespace. This works but only if you set up a share at every folder level that you need hidden. At this stage, although I like the idea of having as few shares as possible, it looks like I'm going to have to do it this way.

Going back to a single share then giving rights to users via groups seems a lot easier, but having folders visible to users that can't access the content will be an issue. Apart from anything else I don't like the idea of a uaser opening the faculty folder and seeing 50-60 department folders when they are a member of only a few departments.

Why? If they don't/shouldn't be accessing that data anyway, why would it cause problems? It does seem like this would be the best structure to use. Unfortunately, there is no way to hide shares based on permission.

qwd wrote:

I've tried using the namespace with the $ at the end. That pretty much killed everything (I think I misinterpreted what this was going to do!).

Have you considered mapped drives? They can be done quite easily using either GPO preferences or scripts. That way you don't need to worry about anyone browsing through shares as appropriate links will look almost like local drives.

Use Domain DFS, even if only as a shared namespace (e.g. \\domain\dfs\sharename)

Never share the root of a drive, always share a folder. Sharing a folder allows for folder migration on the same server without client side changes. Using a DFS path to reference the shared folder allows for server migration without client side changes.

Map drives via Group Policy Preferences Item level targeting: Security Group.
e.g. s: \\domain\dfs\Faculty\shared, z: \\domain\dfs\Faculty\archive
Note that you can map drives to nested folders based on either group or username

You only need one share per volume. If you're planning on either migrating or are currently using multiple volumes (or if you plan to use or enforce quota) create additional shares (e.g. share01, share02, share03).

My first attempts were to make a lot of folder shares but I think I messed things up because things started to behave strangely. Going back to a single share then giving rights to users via groups seems a lot easier, but having folders visible to users that can't access the content will be an issue. Apart from anything else I don't like the idea of a uaser opening the faculty folder and seeing 50-60 department folders when they are a member of only a few departments.

I've tried using the namespace with the $ at the end. That pretty much killed everything (I think I misinterpreted what this was going to do!).

I've now tried enabling Access-Based Enumeration on the Namespace. This works but only if you set up a share at every folder level that you need hidden. At this stage, although I like the idea of having as few shares as possible, it looks like I'm going to have to do it this way.

I think it also depends on the version of server OS. On my 2008 servers, I noticed, if the users don't have ntfs rights to a folder (within a main share), they don't see those folders. I usually create a share called Company_Data and one called User_Data. Then in Company_Data, I create the main folders (Administration, Accounting, Technical, Public...) and in User_Data, I create the user names. I then create security groups for each of the main data folders that were under Company_Data and name it Folder_Access_Accounting.... Then I set the corresponding security groups to the main data folders with Everything EXCEPT Full Access. I just click on Full Access and then uncheck Full Access (the other rights stay checked). Finally I add the users to the appropriate security groups. Using this way, I've noticed that on SBS2008 and Win2008R2, that only users that are member of the groups associated to the main folders actually see the main folders. I didn't notice that behavior in 2003.

OK, I found it. Help, Share Permissions, Next 30, Accessed Based Enumeration

Usually used w/ DFS, which is basically Lazy-RAID across servers with auto-sync. Good to improve availability, don't think you need DFS to use ABE.

Share and Storage Management.

Double-click the share to get to properties.

Advanced

Check Enable Access-Based Enumeration

OK your way back.

Note the Caution, access-based enum doesn't prevent people from getting access to the share ... wait a minute, they don't have access to it, how can they get to it? Apparently DFS perms are different from NTFS perms. Look before you leap.