SharePoint 2016 Permissions Guide Introduction

This SharePoint 2016 Permissions Guide has been created for the benefit of SharePoint site owners and SharePoint site collection administrators so that they can better manage SharePoint 2016 permissions for their team members.

Quite often within organizations, permissions management is decentralized. By that we mean permissions within a SharePoint team site are better understood by an individual working within the team, than they would be by the central IT department. A Sales Manager, for example, would better understand within a SharePoint Team Site, which Sales Executives should have what permissions to the documents and list items within the Team Site than perhaps an IT person would. For that reason, many organizations are decentralizing their permissions management by allowing site collection administrators to manage the permissions within their team sites. Site collection administrators therefore have the responsibility of understanding how permissions work, who has permissions to the content, and ensuring that permissions are maintained – for example, that group membership is kept up to date as people join and leave the organization. This guide therefore acts as a tool to help educate site collection administrators.

In this SharePoint permissions guide, we will explore the following:

• Introduction to How SharePoint Permissions work
• Assigning Permissions (including via Share)
• Reporting on Permissions
• Permissions and Permission Levels
• SharePoint Groups (including Active Directory Group discussion)
• SharePoint Permission Inheritance
• Assigning Permissions in a manageable way
• Additional Resources

Introduction to How SharePoint Permissions Work

Microsoft SharePoint, as you probably know, is made up of multiple objects. An Object can denote a Site, List, Library, Folder, List Item, or Document as far as this guide is concerned. Each of those objects has what is known as a Role Assignment. A Role Assignment is where an account (such as a person), or a group is assigned a permission level to the object. For example: ‘Brett Lonsdale’ (account) is assigned ‘Contribute’ Permission Level to the Team Site (object) named ‘Site A’.

Illustration of a User Account assigned Permissions to a Folder

There are a total of thirty-three different permissions that can be assigned to each user and are made up of the following (Hence the need for a SharePoint 2016 Permissions Guide!)

• 18 Site Permissions
• 12 List Permissions
• 3 Personal Permissions

Each of these individual permissions grant the user the ability to perform an action or to view some content. We will explain each of them; however, some examples of permissions are: Add Items, View Items, and Create Subsites.

To make managing permissions easier, the individual permissions are organized into Permission Levels. So each time you add a new user, you don’t need to work out which individual permissions to assign to the account, but simply select a permission level.

SharePoint Permission levels

• Full Control
• Design
• Edit
• Contribute
• Read
• Limited Access
• View Only
• Approve
• Manage Hierarchy
• Restricted Read

Note: The latter three permission levels may or may not show depending on the SharePoint Features you have enabled.

Later in this SharePoint 2016 Permissions Guide we will explore the permissions individually and how they are organized into the SharePoint Permission Levels.

Screenshot of the SharePoint 2016 Permission Levels

We will be explaining each of these permission levels throughout this document, but for now it is just important to understand that there are lots of permissions categorized into permission levels. The below diagram from left to right shows the hierarchy of the permissions from the user account through to the individual permissions.

Illustration of the Permissions Assignment from Active Directory User Account through to the Permission.

Now that we have discussed the permissions and permission levels, we can begin to understand User accounts, Active Directory Security Groups, and SharePoint Groups.

To illustrate using groups, imagine a company which has 300,000 users. In some cases, all 300k users should have Read permissions to some SharePoint Team Sites. Without groups, you can imagine what a pain that would be to manage. However, assigning all employees to the team site to give them all Read permissions, is actually just one single role assignment thanks to the way groups work.

The Active Directory is made up of user accounts and active directory groups. We are concerned here with Active Directory Security Groups rather than the Active Directory Distribution Groups, since Active Directory Distribution Groups cannot be used to assign permissions in SharePoint. Each user in the organization that authenticates on the network is likely to have a User Account in the Active Directory. Departments, locations, or projects may also have Active Directory Security Groups which can be used to assign multiple users permissions to an object in SharePoint. For example, you may find there is a Active Directory Group called Sales that represents the Sales department.

It is possible to assign permission levels to a user account or an active directory security group directly, although this is not necessarily a good practice. Instead, you should assign permissions by adding Active Directory User Accounts or Active Directory Security Groups (Domain Groups) to a SharePoint Group.

Whether you should assign permission levels to a SharePoint Group or to a Active Directory Security Group is often debated. Microsoft themselves have changed their mind a few times on the best practice. In our view, you are likely to end up with a mixture of the two. However, Active Directory Groups are often frowned upon as a tool to assign permissions for one reason: you cannot see the members of the Active Directory Security Groups from within the SharePoint 2016 Permission pages. You as a Site Collection Administrator are therefore putting your trust in the Active Directory Administrators to ensure that the membership of the AD Groups are kept up to date. On the other hand, if they are well maintained, they allow you to easily manage the permissions! If you need to remove permissions should someone leave the organization, you can remove them from one place and effectively remove their permissions to lots of content in one action.

When you create a new SharePoint Team Site, you are given the option as to whether the Team Site should have unique permissions or inherit its permissions from the parent site. If you select Unique Permissions, you have the option of creating three new SharePoint Groups. These SharePoint Groups are named sitename Owners, sitename Members, and sitename Visitors. The newly created groups are assigned permission levels as follows:

The SharePoint Groups are a great way to assign permissions to the given site, since you can simply add AD User Accounts and AD Security Groups into the SharePoint Groups, resulting in those users being assigned permissions. You can then clearly see the permission levels assigned to each account.

Important Note: The Edit Permission Level is a very powerful permission level. Users with Edit permissions have the permission ‘Manage Lists’ which enables them to delete entire lists within the site. The Contribute Permission Level is much better suited to users who will be creating content. You should consider creating a new SharePoint Group which is assigned the Contribute Permission Level, and then making this new SharePoint Group the default group for the Team Site. The reason for making it the default group is important when users click “Share”. If you share the site, users are placed by default into the members group and therefore receive Edit permissions. By changing the default SharePoint Group for the team site, they will receive Contribute (via your custom SharePoint Group) when Share is clicked.

The “Set Up Groups for this Site” page is very misleading when it comes to the Members group for the team site. The wording in the description implies that users receive Contribute Permissions when in fact they receive Edit.

Screenshot of the Set Up Groups for this Site page

Screenshot showing that the Members Group is assigned Edit Permissions by Default and not Contribute.

To top

Assigning Permissions

Since you have now grasped the concept of how the permissions are assigned to an object, let’s look at how we physically go about assigning permissions to users within our team sites. There are several ways whereby this can be achieved, including:

• Adding Members to a Group
• Adding Permissions Directly
• Sharing Permissions

Adding Members to a Group

You can add members to a group at the time of Team Site creation if you are using Unique Permissions for the site. After the site has been provisioned, you will need to navigate to the Users and Groups page under Site Settings.

To add members to an existing SharePoint group:

1. Click the cog in the top right hand corner of your SharePoint Page (not the one in your browser window), and choose Site Settings.

2. Click People and groups from the Users and Permissions category.

3. Select the relevant group on the left hand navigation pane.

4. Click New, Add Users to this Group.

5. Enter the account name and click Share.

The user you selected will now be a member of this SharePoint Group and will receive permissions to the site and the content within the site that inherits permissions. It is important to note that any subsites that inherit permissions from this page will also be accessible by the user, and also within any site in the site collection that makes use of the same SharePoint Group.

Assigning Permissions Directly

It is possible to assign permissions directly, although we would strongly discourage it. If you have assigned direct permissions, it is very difficult to manage those permissions going forward. If the user leaves the organization, you need to find each object to which the user is assigned permissions, and remove them. This can be like finding a needle in a haystack.

To assign permissions directly:

1. Click Site Actions, Site Settings as you did in step 1 of the “Adding Members to a Group” section above.

2. Click Site Permissions from the Users and Permissions category.

3. Click Grant Permissions from the Grant section of the Permissions ribbon.

4. Click the Show Options link to expand the options within the dialog box.

5. Enter the account name and select a permission level.

Any direct permissions will show as per the below screenshot on the SharePoint Permissions Page:

Sharing Permissions

Clicking Share is a method of assigning permissions which was introduced in SharePoint 2013. Users are encouraged to Share sites, lists, and libraries, and also folders or items. The tricky thing is that the behaviour for permission inheritance varies depending on which type of object was shared. For example, If you click Share on a site, the user that you shared the site with will be added as a member to the Default group for the site.  (As noted above, the default group is the Members Group, which would assign Edit Permissions to the User.) If you Share a list or a library, the permission inheritance is broken for the library and the user will receive Edit permission. If you share a folder or an item, permission inheritance is also broken on that item, and the user is assigned Contribute permission.

To Share a Team Site, click Share in the top right hand corner of the page as shown below:

Screenshot to show the Share option within a SharePoint Team Site

To Share a List or a Library, click Shared With, and then Invite People from the Document Library ribbon as shown below:

The below image shows the direct permissions assigned to Rio when Share has been clicked at Library level.

To Share a folder or an item, click the ellipses (…) on the item or folder and choose Share.

You can also click ‘Invite People’ at the point of Folder creation as shown below:

Quite bizarrely, when Sharing Folder or Item permissions, Contribute is the permission assigned. However, the dialog box seems to indicate that you are granting Edit permissions.

To top

Reporting on Permissions

Within the SharePoint user interface, SharePoint 2016 permission reports can be produced at the object level. The permission reports display any direct permissions, and permissions assigned to each group.

To report on permissions at Site Level, click the Site Actions, Site Settings link, and then click Site Permissions from the Users and Permissions Category.

Permission Report at Site Level

To report on permissions at list or library level, you need to navigate to the Library Settings page by clicking the Library Settings link from the Library ribbon within the SharePoint list or library. From there you can click onto Permissions for this document library from the Permissions and Management category.

Accessing the Library permission page

To access the permission reports on a list item, document or folder, you need to perform five clicks. Click the ellipses against the item,  followed by the ellipses on the first popup dialog, then Advanced, Shared With, and then Advanced again.

Screenshot showing the steps to view the permissions page for a list item or document

Screenshot showing the dialog box to open the permissions page for a document

Each report contains a yellow banner that provides you with information about the state of the permissions for that object. For example, if you produce the permissions report on a Site, the yellow banner will indicate if the permissions are inherited within that site or not, and also whether the site itself contains any child objects such as lists and libraries, or folders and documents, that may have broken permission inheritance.

Beneath the yellow banner is the list of assigned permissions. Users or Active Directory Groups with Direct Permissions are displayed along with any SharePoint Groups. If users are added to a SharePoint Group, or via an Active Directory Group that is nested within a SharePoint Group, you will need to navigate into that group to view the members.

Note: It is important to point out that members of the Active Directory Groups will not be enumerated. So you must have an understanding of who is a member of each AD group.

A quick method to check an individual’s permissions is to use the Check Permissions button. If you want to double check that a specific user is granted permissions perhaps via an AD Group, then performing a Check Permissions will show whether the user has permissions or not even if you cannot see them in the permissions report. For example, Benjamin is granted Edit Permissions as he is a member of the Subsite1 Members Group via an Active Directory Group called Sales.

Check Permissions in the SharePoint Permission Reports

To top

An Explanation of the Permissions and Permission Levels

The out-of-the-box permission levels and their relevant permissions are detailed below. It is possible to create new custom permission levels which are scoped to the site collection and can be used anywhere within the site collection.

 Creating your own custom permission level

If the out-of-the-box permission levels don’t provide you with what you are looking for, it is possible to create your own custom permission level. The custom permission level will be scoped to the site collection, and therefore you need to navigate to the top level site within the site collection in order to create a custom permission level. An example of a custom permission level may be something between Contribute and Read. You may, for example, want your users to be able to create, read, and edit content, but not delete any content. There is also an easy way to create a custom permission level rather than to work out which of the permissions above you want to use within your permission level. You can copy an existing permission level, provide it with a name, and then refine the permissions assigned to the permission level.

To create a custom permission level:

1. Navigate to the top-level site within your site collection.

2. Choose Site Actions, Site Settings.

3. Click the Site Permissions Link from the Users and Permissions category.

4. Click the Permission Levels button in the Manage category of the Permissions tab.

5. Rather than click ‘Add a Permission Level’, click the closest permission level to the one that you want to create e.g. Contribute.

6. Scroll to the bottom of the permission level, and click ‘Copy Permission Level’

7. Provide a Name and Description for your custom permission level.

8. Deselect the permissions that you want to remove, or add more permissions. In this example, we will remove the Delete Items and the Delete Versions permissions.

9. Click Create. You now have your own custom permission level which we will also make use of in the next section when creating groups.

Note: It is important that you should never alter an out-of-the-box permission level. This will lead to confusion between different site collections. Always create your own custom permission level.

To top

SharePoint Groups

As well as the default SharePoint Groups within a SharePoint Team Site, it is also possible to create your own SharePoint groups and assign different permissions to those groups to objects within the site collection. An important thing to note is that you cannot nest SharePoint Groups. For example, if you create a new SharePoint group called ‘Sales’ which contains a number of sales people, you cannot add that SharePoint Sales Group to the [Sitename] Members Group. The Sales SharePoint Group would have to be assigned a permission level. That is one advantage of using an Active Directory Group. You can add Active Directory Groups to a SharePoint Group. So a [Sitename] Members SharePoint Group could be made up of domainname\marketinggroup and domainname\salesgroup. Furthermore, it is possible to nest AD groups at the Active Directory server. So you could in fact have an AD Group called ProjectX which has the domainname\marketing and domainname\sales nested within it.

The default SharePoint Groups are very useful to assign permissions to a local object such as the site, a list or library, folder or item. We know that adding users to a Members group will typically give the users Edit permissions, and adding them to the Visitors group will give them Read permissions. However, you could take a SharePoint Group that you have created, and assign it perhaps Contribute Permissions to Site A, and Read permissions to Site B. This is where we find Active Directory Groups more useful, since you can add a Sales Active Directory Group to a Members group in Site A and know that the sales people will therefore get Edit permissions. However, you can use that same Active Directory Group and add it to a Visitors SharePoint Group site even in another site collection, and the same group of people would receive Read permissions.

An advantage though to creating your own SharePoint Groups is that you as a user can manage the membership, whereas with AD Groups, the membership is maintained by IT.

To create your own SharePoint Group:

1. From any site within the site collection, choose Site Actions, Site Settings.

2. Click People and Groups from the Users and Permissions Category.

3. Click More… on the left hand navigator.

4. Click New, New Group.

5. Provide a name and a description for your group. Make this as descriptive as possible. That way other Team Site Owners may make use of your group rather than duplicate it.

6. Set the Group Owner. This is important! Firstly, make note of the options that come after the Group Owner field. The options beyond the Group Owner field specify who can alter the membership of the Group. The default is the Group Owner. So, think what will happen if this group owner were to leave the organization? That would mean that nobody can modify the membership of this group. You also cannot add more than one user to the Group Owner field. Additionally, you cannot add a Active Directory Security Group to the Group Owner Field. Therefore, our recommendation is to add the Top Level Site sitename Owners group as the owner of your new group.

7. The Group Settings section contains two sections: Who can view the members of the group and who can edit the membership of the group.

8. The  Membership Requests section allows you to specify whether users can request to leave or join the group. The default is set to No.

9. Membership requests can be automatically accepted. Again the default is No. You can set the email address of the user who will accept or decline the group membership request.

10. You can then specify what permissions the Group will have to the current site. This is optional, and keep in mind that you can assign it different permissions to another site. Take note that you can also assign it the custom permission level that we created earlier.

11. Upon clicking Create, your group will be created and you can begin to add members to it.  You can assign permissions to the group anywhere within the current site collection.

Setting the Default Group for a Site

You can also set the Default Group for a site. The default group is used when you ‘Share’ permissions. Remember that when you Share permissions to the site, the users by default are added to the members group which has Edit permissions. Giving everyone Edit permissions is not a good idea. So, this is a way to be able to assign permissions lower than Edit by default when users are invited to the site via Share.

When should we use Active Directory Groups instead of SharePoint Groups?

It shouldn’t be a decision as to whether you use Active Directory Groups or SharePoint Groups, but more an understanding as to which one you should use for certain circumstances.

Active Directory Groups are controlled by the Active Directory Administrators. They control who are members of what groups and would need to be kept informed of any staffing changes to your departments. If your AD groups are not kept up to date, you should consider using SharePoint Groups as an alternative. Active Directory Groups offer a single point where users can be removed which effectively changes their permissions throughout SharePoint. For example, if a user changes departments, or is new to a department, permissions can be granted simply by adding the user to the appropriate AD group.

Another advantage to the AD Groups is that they can be used in any site in any site collection across the SharePoint Farm, whereas SharePoint Groups are scoped to the site collection. AD Groups can also be nested whereas SharePoint Groups cannot.

The major advantage of SharePoint Groups is that they can be controlled by the users. Members can be added and removed without the need to make any change requests to IT. You can also visibly see the members of a SharePoint Group within SharePoint whereas you cannot see the members of an AD Group within the SharePoint user interface. For that reason, it is difficult to know whether the correct people have the correct permissions to a given object.

To top

SharePoint Permission Inheritance

By default, objects in SharePoint all inherit permissions from their parent object. Subsites inherit permissions from their parent site, lists and libraries inherit permissions from the site that contains them, root folders inherit from the list or library that contains them and subfolders inherit from the parent folder. Items including documents inherit permissions from their parent list or folder.

At any point permission inheritance can be broken. Permission inheritance is usually broken because you want to grant a new user permissions to a child object, or you want to remove permissions from a group or user of a child object. Permission inheritance can be changed using the ribbon on the permission pages of each object, and sometimes also by clicking Share. Clicking share on a list/library or on a folder/item will result in the permission inheritance being broken on that object. Sharing a site will not break the site’s permission inheritance, but instead add the invited user to the default SharePoint Group for the given site.

Too many broken permissions can be a bad thing, and permission inheritance should only be broken if necessary. There is a limit to the number of unique permissions that you can have on items in a list or library in SharePoint 2016 of 50,000. The limits and boundaries for lists and libraries can be found here.

Regardless of the actual limit, it is a known fact that the more unique permissions you have, the more Access Control Lists you need to manage. E.g. removing a user’s permissions is much easier if most of the objects are inheriting permissions. Performance when rolling up content due to the security trimming for the current user is also affected by the number of unique permissions.

If you find that you are breaking permission inheritance a lot, you may want to question your site’s design. Would it be better for instance to increase the number of site collections, or the number of lists in an effort to have less Access Control Lists?

Breaking permission inheritance can be achieved by navigating to the permissions page of the given object, which was discussed at the top of this guide.

Screenshot to show the Stop Inheriting Permissions button

The button will toggle to an inherit permissions button once permission inheritance has been broken.

To top

Limited Access

Limited Access is nothing to be concerned about. Sometimes people wish to remove Limited Access. There is absolutely no need. Let’s consider that you have granted unique permissions to a user named ‘Carl’ on a Folder or document within a Team Site. If Carl didn’t already have permissions to the Site that contained the folder, then limited access would be granted to Carl at the Site level. Limited Access is applied so that Carl can navigate to the folder. He won’t be able to see any other content within the site unless he has specifically been granted permissions to it also. Limited Access is therefore granted automatically. It is sometimes a bit misleading and that is due to the fact that SharePoint does not enumerate the Active Directory Groups. If Carl was a member of an AD group with let’s say Edit permissions, and unique permissions were assigned to Carl at the item level. Limited Access would show for Carl in the out-of-the-box permission reports, despite him actually having Edit permissions to the site. For that reason, the Check Permissions button is extremely useful to double check ‘Limited Access’ permissions.

Although it is possible to remove Limited Access, you shouldn’t. Here is a good explanation why: http://wendy-neal.com/2014/07/lesson-learned-removing-limited-access-permissions-overrides-item-level-security-settings-sharepoint/

 Groups and Permission Inheritance

When you break permission inheritance on an object, groups are sometimes overlooked. When you break permission inheritance, the SharePoint Groups that had permissions to the object will still have permissions to the object unless those groups are removed. So, inadvertently, you could “Share” permissions at a parent site which adds a new member to the default group. The default group of the parent site would still have permissions to the subsite even though its permission inheritance was broken. To avoid this, you would need to consider removing the group in question.

To top

Assigning Permissions in a manageable way

SharePoint Permissions can get messy!

Your goal with regards to SharePoint Permissions should be to make them as manageable as possible whilst still ensuring that only the right people can see your content or work with your content.

To make your life simpler, it is recommend to limit as much as possible the number of unique permissions within your SharePoint Team Site. The more unique permissions there are, the more places you need to remove users or change their permissions. Remember that clicking ‘Share’ at document level is going to break permission inheritance on those documents. Perhaps instead, you could consider having another document library containing different types of documents and assign permissions at the library level. e.g. Quotations could go into one document library and Invoices in another. Permissions can be assigned to the appropriate user at library level rather than unique permissions set on each quotation or invoice within the same library.

Groups should be used as much as possible and educate yourself on the domain groups or other groups available to you at Site Collection level. Understand that SharePoint Groups could in fact be used to grant permissions to the members within other sites of the same site collection.

To top

Additional resources

10 SharePoint Permissions Tips

SharePoint 2010 Permissions Guide

SharePoint Online Permissions in Modern Sites

We hope that you found this SharePoint 2016 Permissions Guide useful. If you did, please share it! Please contact brett@lightningtools.com if you have any suggestions for edits.

By Brett Lonsdale

Lightning Tools also offer a permissions management and reporting tool called DeliverPoint. You can find out more on our website about DeliverPoint for SharePoint On-Premises or SharePoint Online.