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

SharePoint Permissions – Permission Levels

This is the third in a series we’ve been doing on SharePoint Permissions. Here are the links for the previous blogs:
SharePoint Permissions – Friend or Foe?
SharePoint Permissions – Security Groups


In our last blog we talked about Security Groups and why they are important. Security groups are only one piece of permissions management. Let’s focus this week’s attention to subject permission levels.
Permission levels are shockingly easy to understand once you remove the other elements of permissions management. A permission level determines what a person or group can do in a site, list or library. By default each site comes with some standard permission levels:

• Read - Can view only
• Contribute - Can view, add, update, and delete
• Design - Can view, add, update, delete, approve, and customize
• Full Control - Can view, add, update, delete, approve, customize, and manage permissions

Notice how each level grows from the last one. The advantage is if you need to provide a group with ability to read documents, edit documents, and delete documents, you only need to give them Contribute access and they are off and running. It really is that simple. There are other permission levels out there and custom permission levels can be created, but that is another blog.

Join us next week, when we’ll wrap up permission with Permissions Inheritance.

SharePoint Permissions – How does access really work

SharePoint Permissions – How does access really work?

In my last blog SharePointPermissions – Friend or Foe, I introduced some thoughts on permissions in general terms.

Let’s spend this week and focus our attention to how permissions work in SharePoint. I think it is important to start with defining what “permissions” are. When we talk about permissions in SharePoint we are talking about access privileges to a site, list, or library. It is as simple as imagining a locked door, only someone that has the right key can unlock the door, open it, and walk through. In fact we use permissions every day in other areas of our lives and never think twice about it. The key to your car, for example, means that only the holder of that key can operate the car. Your credit card that you used to buy groceries last week; it too is an example of a key. It tells the grocery store that the holder of that card has the ability to purchase up to a certain dollar amount. The badge you used to get into the building you work in… yep it’s a key too. All of these keys provide the holder permission to perform certain actions or provide certain types of access. 

SharePoint permissions are no different.

Just like the examples we used above permissions are not just waiting out there for anyone to come and grab. One must request and be approved. For the car, someone had to hand you the keys under the agreement that you would pay for the car. You work badge, yeah that sucker isn’t free either. You get your badge only because you have an agreement with your wonderful employer to work once you enter the building.

Okay I think we beat that horse long enough don’t you? You get it, right? Permissions mean having the key to get where you want to go.

When we talk about SharePoint we step up the permissions talk in introduce the term, “permissions management”. For those of you that had that suddenly had this feeling of impending doom wash over you… take a deep breath, we’ll get through this together.

Permissions Management at its most basic is nothing more than granting or restricting user access. Per Microsoft permission management is comprised of three components:

• Security Groups
• Permission Levels
• Permissions Inheritance

It is the combination of these components that gives SharePoint its security and flexibility. This is also where a lot of people get lost. Why? In my experience it is because they try to make all three mean and do the same things, thus confusing themselves and their permissions. Let’s start with Security Groups.

Security Groups

Most new users and administrators of SharePoint underutilize the SharePoint security group. It probably seems a little too, all or nothing. In fact the proper use of security groups gives the administrator the best possible method of managing masses of people and what they have access to.

A security group is a collection of users, ideally that share common tasks on a SharePoint site. A single user can belong to several groups and many users can be in a single security group. A security group on its own is just a group, a collection of users.

An important note, security groups live at the site level in SharePoint. All of the people (users) that interact with any element of a SharePoint site will need to be accounted for in the site. Lists, Libraries, pages, documents and anything that you can set permission levels for will be looking to the site for its collections of groups and will, by design, want the administrator to choose one of those groups when assigning permissions. Can you assign people permissions without adding them to a group? Yes, but that my dear readers is another blog.

Now, getting back to security groups. We now know that security groups are collections of users that share common tasks or a common purpose. For example, let’s say I was an administrative assistant in a company. Chances are there are other administrative assistants in the company as well and chances are that we, the administrative assistants, perform some of the same types of work and need to access some of the same stuff. If I had a SharePoint site that needed administrative assistants to access a report for my boss then I could create a security group called (yep you guessed it) Administrative Assistants and place myself and my fellow co-workers in that group. So when I provide the group the needed permissions, they all get it at once.

You’ll notice that when we talk about security groups the word permissions seems to follow. There is good reason for that. A security group only has purpose once that group is assigned a permission level.

You know what, I just looked at the time and realized I’ve been typing for a while here. I think I’m going to leave us where we are until next week when we take a walk through the tulips of permission levels.