Forum Discussion
When should users break inherittance?
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.
