SharePoint Permission Inheritance

By:   |   Comments   |   Related: > SharePoint


I am just getting started with SharePoint and noticed many security options and features. I can see that you can attach named users to sites, lists and libraries. I can even see there is some type of grouping system. But I don't know what to make of it all.

Beginning with WSS3 (and MOSS 2007), Microsoft introduced a security system that was granular right down to the item level. This means that not only can sites, lists and libraries be configured with different security setups, but individual list and document items within a library or list can have unique permission setups.

Before exploring the details of SharePoint security, it is important to understand the concept of permission inheritance. Permission inheritance occurs every time a new SharePoint object is created. All SharePoint objects are created within the context of a hierarchical tree. By default, all SharePoint objects 'inherit' the permissions of it's parent object until you change the inheritance structure.

Let's walk through some steps of creating objects, showing the inheritance, and then editing the inheritance to show the granular possibilities for SharePoint security.

To begin I'll create a new site. (Site Actions --> Create Site)

1 Create Site

Here is where we get our first important option. The default is to "Use same permissions as parent site". This does what you think. However there is no flexibility at all in the new site. I recommend always starting a new site with unique permissions unless you have a specific reason to use the default.

2 Unique Permissions

In WSS3 and MOSS 2007, the next important choice is on the next screen. The questions are what default groups do you want for the site. By default, the group choices are a group each for:

  • Read only
  • Contribute permissions (read and write)
  • Owners (full control).

I usually except the defaults, however I change the title of the 2nd group from 'members' to 'contributors'. It's a subtle difference in terminology, but it keeps me from going nuts guessing exactly what constitutes the permission of a "member", which is a little vague.

3 Default Permission Groups

So the site gets created. Let's look at some of the default settings.

4 People and Groups link

After clicking on "People and Groups", we can see three groups available . Two (xxxxx Contributors, and xxxxx Owners) were created when the site was built. The " Visitors" group I chose to 'inherit' when the site was built. (By clicking 'More...' you can access other groups in the site collection.)

6 Group Listings

Let's take a look at the advanced security settings of the site. Click "Site Actions" and then "Site Settings".

5 Site Settings

Under "Users and Permissions" click "Advanced permissions".

7 Advanced Permissions Link

Here are the default site settings that we chose when creating the site.

8 Site Permissions

When new site objects (like document libraries or other lists) are created, they will "inherit" these settings by default. Let's create a new document library and take a look. Click "Site Actions" then "Create".

9 Create

After choosing "Document Library", enter a name and accept all the default values and click "Create".

0 Security Documents

Now let's check the default permissions on the document library. In the library settings, click "Permissions for the document library".

1 1 Library Permissions Link

Notice they are the same as the default site permissions.

2 Default Library Permissions

After creating a folder, let's take a look at the 'inherited' permissions.

3 Folder Permissions

Yep, same as the document library (which inherited from the site).

4 Folder Permissions

After creating a new folder, let's change things around. In the permission settings of the new folder there is an "Action" menu. Select "Edit Permissions" from the menu.

5 Edit Permissions

Here is were we get to stop the inheritance and create a different set of permissions from it's parent object. Take a look at the warning message below...

6 Break Inheritance

After clicking "OK" we see there are now check boxes next to each permission objects. At this point we can remove or edit any of the permission objects.

7 Checkboxes

To remove a permission, check one (or more) of the boxes and select "Remove User Permissions" from the "Actions" dropdown.

8 Remove Permission

Here is the result.

9 New security

Whenever we change permissions at any level, all objects created underneath that level inherits the new permission set. So for a particular folder in a library where you modified the permissions, all documents in the library will inherit the permissions of the folder. Though I did not demonstrate it, you can change document permissions in the same was as a folder permission. So if there is a particularly sensitive document in the folder, you can hide it from a set of users while showing it to a different set of users.


SharePoint permission inheritance provides a way of automating some administrative tasks while offering granular control, much like a file server.

Next Steps
  • Check out for great information about Microsoft SQL Server.

sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip

About the author
MSSQLTips author Rob Fisch Rob Fisch has worked with SQL Server since version 6.5 as a dba, developer, report writer and data warehouse designer.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips

Comments For This Article

get free sql tips
agree to terms