Thanks. It took me a long time to figure all this out. Kurt
On Mon, Nov 27, 2017 at 11:29 PM, Micheal Espinola Jr <[email protected]> wrote: > 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:[email protected]] 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. >> >> >> >> >> > >> > >> >> >
