fwiw, +1 on all counts from me as far as best practices go. -- Espi
On Mon, Nov 27, 2017 at 11:14 PM, Kurt Buff <[email protected]> wrote: > 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 <[email protected]> > 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: [email protected] [mailto:listsadmin@lists. > myitforum.com] On Behalf Of Kurt Buff > > Sent: Tuesday, November 14, 2017 2:51 PM > > To: ntsysadm <[email protected]> > > 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 <[email protected]> > 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. > >> > >> > > > > > > >
