Forum Discussion
When should users break inherittance?
I've always advocated that SharePoint inherittance should be broken in the following order; site collection, site, library, document set, folder, document. In other words only break at document level as a last resort. Logically the smaller number of permissions groups then the easier this is to manage and also this will encourage better collaboration and make it easier for users to find relevant information (SharePoint is not called LockdownPoint). Does anyone know if there is some good online advice around this? A good tutorial or video that I can share with my user community? All I can find is step-by-step guides on how to break inherittance rather than advice on when to break inherittance.
8 Replies
I don't know of a document or guide that provides the information you want. I also didn't do any 'googling' for such a document before replying to your post. One way to organize such a guide is to determine what you (or your customers) are trying to accomplish.
For example, if you are implementing a business process where a user fills out a form to request something. This commonly requires that permissions are broken and reapplied so that everyone can't read everyone elses' requests.
Microsoft has made sharing easier, but this often breaks permission inheritance, but the user doesn't know that. So even if you wrote up somthing titled "When to break permission inheritance", most user would not even know that this is relevant to what they are doing.
I tend to lean toward 'traditional' guidance such as:
1. Share with groups not individuals (OD4B shares with individuals not groups).
2. Leverage AD groups where you can, but recognize that their limitations. For example, the built in Check Permissions tool will tell you if an AD group has permisssion on an object, but it can't tell you if an individual is in that group. In other works if I check permissions for joe@mytenant.org and joe is granted permissions via an AD group then check permission will not see any permissions for joe. (it is possible that once they log in the first time, check permission will work, because joe is added to the the site collection user information list).
3. Use SharePoint groups, you can can put AD groups in them and you have control over who can edit\view group membership.
There is more to write, but I am just contributing and I have to get back to my regularly scheduled work. Greg
I normally try to define a proper document library structure with the client when we build a new Sharepoint site for them, so that I can define access on the document library level. For example, a "Managers" document library to which only the Managers group has access to.
If you get the document library structure right from the beginning, you will hardly need to set folder or document level permissions. If there's no way around it, I will set permissions on a folder and stop inheritance on that folder but this should be treated as an exception to the rule. I would never set permissions on a file level, user can do this themselves nowadays, so from an admin point-of-view you can then put the responsibility back to the customer.
So this has been a loaded question and one that got worse when Microsoft provided the Share functionality in SP2013. It has always been the best practice to control access via AD groups so the ACL in the index isn't constantly being updated and slowing down response in the crawl and in displaying data via security trimming. However, that all went out the window when Microsoft provided users the ability to share documents, folders, lists, and sites in SharePoint 2013.
I still strongly support that document level inheritance breaking should not be done. It becomes an administration nightmare and if done extensivily a performance affecting issue. Because of the Share buttons, to stop this from happening you either have to do some extensive custom development or implement a tool that blocks this process (I believe AvePoint and Metalogix support this).
From an admin stand-point I try to influence my clients to ask the question "Why don't you need access?" instead of the normal "Why do you need access?" This means you can open things up at the top level and only lock them down if the content warrants it. At my current client we have a document that defines when a document should be restricted or not. This helps in controlling the access and setting up an easy to use security system.
So in my opinion never actively lock down documents as a SharePoint admin. The lowest you should go is a folder. If you can get away with it don't lock down an entire list\library and even leave the site open unless the entire site contains securable information within it. If you are worried about users going snooping through data they don't need to, then your users need more work assigned to them. It's a simplistic way of looking at it, but in my opinion you need to stop considering how best to lock down your data internally and instead keep the Share in SharePoint and lock it down as little as possible. It requires a mindset change in many locations, but in the end users will be able to collaborate, search and work together much easier then when your SharePoint environment resembles a document prison.
I agree with you. Share Button is administrator's nightmare. It's difficult to understand the Microsoft policy and recommandation to don't break inheritance when then promote the share functionality. In fact, the share funtionality is a break of inheritance rights...
My personal opinion is to stop breaking permision inheritance no further than on site level.
So that it can be managed easily. If users, outside the standard permission, need access on a lower level then they can decide to share the folders, doc sets or docs.- Isn't the new answer is that users should break inheritance whenever they want? After all, there's a really easy mechanism provided for users to "share" a doc, and by default, sharing will break permissions as needed, as will several of the options in the dialog for getting a link to a doc. If you don't want users breaking inheritance, then what are you doing to keep them away from the sharing and "get a link" functionality?
If inherittance is broken at site collection or site level then all of the information below is invisible to everyone else, which may be required but if it is information that users should be able to see and permissions are being given on a document by document basis then collaboration and innovation becomes restricted hence my question asking if anyone has come across some decent training/education material to assist users in choosing the right option
