SharePoint Permissions – Permissions Inheritance

SharePoint Permissions – Permissions Inheritance

We have spent the last several blogs focused on topic of permissions. With any luck you’re starting to see that permissions management is not some mystical voodoo, but rather a grouping of distinct components that work symbiotically. Let’s wrap up this series by diving into, what is perceived as, the most complex element of permissions management, Permission Inheritance. We’ve already reviewed security groups, which tell us who will have access, and permission levels, that tell us what we can do with our access. Permissions inheritance tells us where those groups and levels are applicable.  

The word inheritance is almost misleading at this point, we really should call it permissions placement. When a site is first created and the standard groups are built they have “site level permissions”, meaning the place where those security groups have access is, is to the site. In the image below we see a drawing of permissions for a new site. On one side of the image we have the libraries and lists that make up the content of the site, represented by folders. On the other side we have security groups with their permission levels. What connects these two sides together is the site. When we make new security groups SharePoint will automatically try to place the permission level you give that group to the site.

So why is it called permissions inheritance?

By default, when a new list, library, or sub-site is created it will have whatever permissions the site it was created in has. That is permissions inheritance. Let’s refer back to our image for the example. In our site the libraries on the left have the same permissions as the site because they were created in that site. In turn the security group, Site Visitors, has read access to the site and also to the libraries within it.

Now, even though a list or library starts off with the same permissions it is possible to change those permissions. Changing the permissions for a list or library from the permissions that are in the site is called Breaking Inheritance.

There are positives and negatives to breaking inheritance. Each break in inheritance means there is something additional for the site owner to maintain. That said; a break in inheritance might be the best way to ensure proper security for your site content. If you have a good security plan in place and you’ve thought through where content should go based on who is using it and for what purpose, the breaking or retaining of inheritance will provide harmony and ease of use, neglecting to plan your site out before altering permissions could mean a lot of administrative overhead and confused or frustrated users.

How do I know if I should break inheritance for a list, library or sub-site?

The conversation of breaking inheritance is always security related. Is the information in the list, library or sub-site sensitive or should it only be seen/edited by certain people? These are situations when you consider breaking inheritance. Again, establishing a plan for where documents go, and who has access to them will go a long way to making these decisions.

How do I plan for what I don’t know yet?

I’m reminded of a recent conversation with friends. My friends and I are planning a vacation. During a recent dinner we started talking about vacation, we immediately began to ask each other the “who, what, where” type questions.

“Who should we invite?”

“What do we want to do for our vacation?”

“Where do we want to go?”

These questions are really important to making sure our vacation is enjoyable. If we don’t figure out the “what”, we might make it somewhere but then what? If we don’t decide on “who” we should invite, someone might be going on vacation by themselves. If we don’t answer the “where do we want to go” question, well, we’ll never get there, will we?

If we apply that same thinking to permissions management we find that. Permission levels provide the “what” of permissions management. Security groups provide the “who” and permissions inheritance will give the “where”. The combination of those three areas provides us a complete permissions picture.

• Who – Security Groups
• What – Permission levels
• Where – Permission Inheritance

Take any one of these three away from the others and the others would simply have no value. When you create your security plan start with the Who, What and Where, that will give a great place to start. Don’t forgot your ITS SharePoint COE team is always happy to help you in your planning efforts so feel free to contact the team with any questions, comments or concerns.

 Summing it up

As you can see, permissions management while not simple is also only as complicated as you make it. Remember to ask your user community about their needs, ask the who, what and where questions and use that information to create a workable security plan (otherwise known as a governance plan). Remember that permissions management is really three distinct components that depend on each other for success.

Security groups – defines who has access

Permission levels – defines what those groups can do

Permissions Inheritance – defines where in the site those groups have access