My apologies up front for the long ramble. Take this with the usual pinch/tablespoon/pound/kilo of salt. This is what works for me - you might need something different. Actually, I'd wager money that you do, as you seem to be in an educational environment, which most assuredly has different requirements than a business.
However, up front, I'll just say this: Breaking inheritance for permissions in any environment is like telling lies - it's a bad idea, because you have to keep track of it all, and the more lies you tell (and the more places you break inheritance), the less likely you are to be able to keep track of the situation. So, mostly, the answer to your question depends on what you mean by "departmental folder", and where each lives in the directory structure. We have a Groups directory which is shared (i.e., G:\Groups (I don't create shares at the root of a drive for several reasons)), and which contains a subdirectory for each department (G:\Groups\HR), and other subdirectories at the same level as needed for cross-departmental efforts (G:\Groups\9001ISOAuditDocuments). However, the first thing I'd do is document the permissions as currently applied, then peruse them carefully. If there are any places where inheritance is broken, figure out why. If there's a defensible reason (there are no "good" reason for this, IMHO), then look for ways to fix it - with my favorite way being to move the directory that has inheritance blocked somewhere up the directory structure, to a point where inheritance no longer needs to be blocked. If there isn't a defensible reason for inheritance to be broken/blocked, refactor your permissions and re-enable inheritance. It will help to do a few other things: - take a careful look at the groups for which permissions are applied. If any individual accounts have explicit permissions, replace those with group permissions - create a dummy directory structure (possibly empty, or with only some zero-length files in it), and practice your script-fu on that, before tackling production directories - set up a dummy departmental directory as a model in your production structure, with a readme file in it to document how you want new departmental directories created The Groups directory is shared with Full Control to Everyone, and with NTFS permissions of read-only to all employees for that folder only (Admins get read-write, with full inheritance). Each departmental directory at its top level has read-only access to all employees, for that folder only. This gets everyone transit to its subdirectories. Each departmental directory has only three subdirectories: Public (read-only for all employees, read-write for department employees, with full inheritance ) Private (read-write for department/project employees only, no access to other employees, with full inheritance) Manager (read-write for the department/project manager only, no access to other employees, with full inheritance) Permissions are not applied any further down the tree than that. If a directory needs different permissions, it is moved to the root of the departmental directory, and relevant permissions are applied to it there. A couple of other things I do: - Each departmental directory gets three groups of its own in AD: non-departmental read-only, departmental read-write and department manager owner(s). - I create an AD OU into which I stuff all of the groups for the server (file, SQL or other), and it's a sub-OU of the OU in which that server resides, and is named <server>-permissions. Modify this as needed for DFSR environments. - I name each group explicitly for the directory to which it is applied, so it's obvious where and why it's used (USFSGroupsHR-RO - which means the US file server, the Groups Directory, the HR subdirectory, read-only permissions) This doesn't address SharePoint directly (although I think the general approach on how permissions are applied would translate fairly well), but I consider SP not a fit replacement for a file server. SP is a collaboration/workflow tool, IMHO, not a file repository - stashing massive amounts of files into a SQL Server makes me itch all over. Others disagree, I'm sure. Kurt On Mon, Nov 27, 2017 at 7:34 AM, Tammy George <tammy.geo...@acadiau.ca> wrote: > Our directory structure does need refactoring and as a solution to this, > we're strongly encouraging our users to move their files to SharePoint > Online. Once we have departmental buy-in, we plan to "flip" all user > permissions to read-only. We have a mess of permissions - everything from > group based, explicit, broken inheritance, etc. Each top level folder on our > network share is a departmental folder with folders within it a few levels > deep. We will be working with each department individually, one at a time. > > From your experience, what is the best/easiest/cleanest way to "flip" > permissions to read-only for all users one departmental folder at a time? > > Options I've considered thus far - > > Run a report of the current permissions and then using icacls, modify > all to read-only. (stumbled on this today - > https://gallery.technet.microsoft.com/scriptcenter/PowerShellAccessControl-d3be7b83) > I just downloaded Quest's Security Explorer and plan to test it out. > > Many thanks. > - Tammy > > > > > > -----Original Message----- > From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] > On Behalf Of Kurt Buff > Sent: Tuesday, November 14, 2017 2:51 PM > To: ntsysadm <ntsysadm@lists.myitforum.com> > Subject: Re: [NTSysADM] Accessing only a lower level folder in a share > > You need to adjust the permissions in the directory tree, and breaking > inheritance is the wrong way of doing it. > > Change the permissions at each level so that they are explicitly defined to > allow "This Folder and Files" for those who only need to see the files in > that directory, but not other subdirectories. > > Also, it seems as if your directory structure needs refactoring - it's way > too complex if you're running into these kinds of permission problems. > > Kurt > > On Tue, Nov 14, 2017 at 8:51 AM, Michael Leone <oozerd...@gmail.com> wrote: >> It's been so long since I've had to do this, I need a check. I'm doing >> something fundamentally wrong, I think. >> >> We use groups to set share/ACLs on folders. I got a request to share a >> 4th level sub-folder with other employees not in the ACL. So what I >> have is: >> >> Folder A1 (shared) >> -->>B2 >> -->>C3 >> -->> D4 (this is the one I want to allow access to) >> >> Now, the share permissions on A1 is for DevelopmentGroup, and the NTFS >> permissions are the same. Those permissions just flow down to B2, C3 >> and D4 (i.e., normal inheritance). >> >> Now, I'm pretty sure the only way to allow access to only D4, and not >> allow access to B2 and C3 or even see files there, is to enable ABE. >> But I've never done that, and am leery of enabling it in production, >> without a whole more testing and forethought (I shudder to think of >> all the help desk calls, if I get something wrong). >> >> Am I correct that only ABE will do what I am thinking of (allow access >> only to D4 and hide contents of A1, B2, C3)? >> >> Barring ABE, there's nothing I can do, short of granting a new group >> access to D4, and living with the consequences? >> >> Thoughts? At this point, I want to just add the new group to the NTFS >> permissions of D4 only, and live with the fact that these new group >> members can see everything higher up. >> >> > >
