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.

SharePoint Permissions – Friend or Foe?

If there is one thing and seems to scare many users in SharePoint land I would have to say it is permissions. For some reason this topic is cloaked behind a thick fog of confusion and mystery. We are going to dedicate the next few blogs to demystifying SharePoint permissions and shining the light on its pros and cons.

Let’s get started by talking about how SharePoint is structured. To help illustrate this concept let’s use the metaphor of a university campus. Universities are big places with many buildings and lots of things to do. Each building on university campus serves a specific purpose, there are buildings dedicated to science, math, law, music, etc…  buildings can be large or small, old or new. In each of these buildings contain classrooms, offices, libraries, and labs, all focused around gathering and dispersing knowledge.

In the land of SharePoint we have sites, usually dedicated to a single purpose, such as departmental information or program information. In a site we have lists, libraries and pages. All of these are designed to gather and share information. Using the university as our parallel we can think of a site is a building and lists, libraries and such are the rooms in the building. Everyone still with me?

So when we think about SharePoint permissions we can continue the metaphor to include the students and professors. If you were a student attending our happy university, you don’t simply arrive on campus one day and randomly pick a building. No, you go through a registration process. You request the type of classes you want or have to take, what you plan to major in and so forth. Your requests are processed and you are later presented with a series of classes you are registered for and provided information about the time and location of the classes you are “approved” to attend. You are not permitted to attend classes you are not registered for regardless of your desire to take them.

Permissions work very much the same way. You request (or someone requests on your behalf) access to something in a site and an administrator of that site approves or rejects your request. If approved you are given permissions, and you can only enter areas in a site that you have permissions for.

I’m sure at least one of you just though, “yeah, but I can see lots of sites but can’t get to parts of it, what gives?” You can think about that like… a lab. In many cases you can walk into a building at a university but when you try and open a door to a lab or library you might find the door locked and only if you are given the key can you get in. Permissions in SharePoint parallel this by being able to restrict access parts of a site depending on the SharePoint Group you belong to.

Let’s take this idea a little deeper. Let’s further stretch the metaphor and say you are law student. As a law student you can check out books in the law library, or attend law focused study groups. Only students that have declared “law” as their major can use the law library or attend the study group. In the graphic below we can see that thought in images. The student belongs to the group that is called Law Students and Law Students has access to the Law Library.

This mirrors the function of a SharePoint Group. By placing people that perform similar tasks into a group, permissions can be given to the group. While you can add a person directly to a site, list or library, adding them to a group will automatically provide them benefits of being in that group.

Well, that was a whole lot of info to take in, so let’s make this our stopping point for this week’s blog. Check back next week and we’ll dive a little deeper into SharePoint permissions.