By Cathy Dew
Breaking Inheritance: Just because you can, doesn't mean you should
When it comes to managing the security for a SharePoint intranet, site, document library, or document, it’s important to understand the basics of permission inheritance. Permissions are the building blocks of the SharePoint security model. Essentially, people have “permission” to access a certain site or library based on their role in an organization. People without the same permissions may not have access to all the same documents or other resources. This system helps control who can see, access, change, or download information within your enterprise. If something is extremely sensitive or confidential, you can use limited permissions to minimize the likelihood of a leak.
How Permissions Inheritance Works in SharePoint
Rather than requiring SharePoint developers to customize permissions at every level, Microsoft designed something called permission inheritance. The way SharePoint intranets are usually set up is in a parent-child-grandchild configuration. You have a root site or top-level SharePoint site, which acts as the “parent.” The root site then has multiple subsites covering different subjects, serving different purposes, or different departments. These sites, in turn, might have their own subsites, to break information up even further. These subsites (and subsites of subsites) are the “children” and “grandchildren” of the top-level parent site.
Just as children and grandchildren “inherit” things from their parents, subsites in SharePoint are set to inherit permissions from higher-level sites. This system is in place to simplify matters for SharePoint developers. Since most SharePoint intranets work in such a way that anything in a subsite applies to people who are accessing the top-level site, inheritance makes it so that individuals who have permissions to access, read, or alter a top-level site will carry the same permissions for all connected child and grandchild sites.
Permission inheritance is an essential SharePoint feature for how much it simplifies the process of building a SharePoint intranet. However, there are situations where you might wish to be a bit more discerning with the permissions for a child or grandchild site than you are with the parent site. Just because you are giving a person access to a root site doesn’t necessarily mean that they need permission to view or edit every single subsite, list, library, or document underneath the parent site’s umbrella.
In situations such as these, you can “break” inheritance within your SharePoint site. Breaking inheritance just means that you are editing the permissions at the child or grandchild level of your SharePoint site or site collection. By default, non-root sites will start with permissions inherited from higher-level sites. Only when you build a new root site will you be required to create a new permission structure. However, you can edit your subsites, lists, or libraries to remove permissions, add permissions, or otherwise customize the permissions structure. Once you save these changes, any subsite, list, or library below that site in the hierarchy will assume the tweaked permissions of that site.
The Costs of Breaking Inheritance
The big cost of breaking inheritance is that it can create just as much chaos for your team. If you break inheritance at every level of a site collection—or if you start tweaking permissions haphazardly, without any concrete plan in place—it can become virtually impossible to remember who has access to what. Breaking permissions for individual users, meanwhile, means that you end up having to constantly alter your permissions every time a new person joins your organization. At the very least, you need to manage inheritance and permissions based on user groups.
Avoiding Permissions: Creating New Site Collections Instead of Subsites
The philosophy among some teams is that breaking inheritance is so cumbersome that it isn’t worth it for any purpose. SharePoint developers with this belief will often advocate building different SharePoint site collections based on permissions. If a subsite within an initial site collection is going to need a different level of security than the root site, these developers might opt just to build a new site collection with a higher (or lower) level of security.
This strategy tends to be flawed—particularly for small to mid-sized organizations. The child and grandchild sites within a site collection don’t just inherit permissions. On the contrary, they also inherit metadata settings, site templates, and branding features. If you are building a new site and it has the same metadata, template, and branding needs as the upper-level root site, it is always better to make the site as a subsite and break inheritance than to create a brand-new site collection. If the site you are building doesn’t require the same metadata or branding as the top-level site, though, then it probably isn’t relevant to the site collection and should be broken off into its own collection.
Call 2Plus2 for Help with Your SharePoint Security Structure
As you can see, devising a workable strategy for SharePoint permissions and inheritance can be difficult. If you need help deciding between setting up a subsite or a new site collection, or if you want some advice on when, where, and how to break permissions, 2Plus2 can lend a hand. Go online to schedule a free consultation with our team or call 510-652-7700 today.