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 de-centralized. By that I 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 de-centralizing 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. e.g. 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.
Throughout this SharePoint 2016 permissions guide, we will explore the following:
- Introduction to How SharePoint Permissions work.
- An Explanation of the Permissions and Permission Levels
- What happens when I or one of my users clicks “Share”?
- Exploring SharePoint Groups
- When should we use Active Directory Groups instead of SharePoint Groups?
- SharePoint Permission Inheritance
- Assigning Permissions in a manageable way
Introduction to How SharePoint Permissions Work
Microsoft SharePoint as you probably know is made up of multiple objects which will be referred to as objects throughout this SharePoint 2016 Permissions Guide. An Object can represent 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 being where an account (such as a person), or a group is assigned a permission level to the object. For example ‘Brett Lonsdale’ is assigned ‘Contribute’ Permission Level to the Team Site 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 you never have to work out each time you add a new user, which individual permissions to assign to the account, but simply select a permission level. The permission levels include:
- Full Control
- Limited Access
- View Only
- 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.
I recently spoke to a representative of a company who has 300,000 users. In some cases, all 300k users had 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 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. Each department, location or project may also have an Active Directory Security Group 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 my 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 into 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 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:
|Group Name||Permission Level|
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 the 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 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.
Hopefully we have now grasped the concept of how the permissions are assigned to an object, let’s look at how we physically go about the assigning of 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:
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 the 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 I would strongly discourage it. If you have assigned direct permissions, it is very difficult to manage those permissions going forward. If the user retires from the organization, you need to find each object that the user is assigned permissions to 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:
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 (By default, 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 direct permissions. If you share a folder or an item, permission inheritance is also broken, and the user is assigned direct permissions.
Permissions Remain Inherited
Permissions Inheritance Broken
|Site||x||Edit (Through Members Group)|
|Library||x||Edit (Direct Permissions)|
|Folder/Item||x||Contribute (Direct Permissions)|
To Share a Team Site, click Share at 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 and not Edit. Albeit the dialog box would indicate that you are granting Edit permissions.
Reporting on Permissions
Within the SharePoint user interface at least, 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. If for example, 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
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.
Permission Level Category
|List||Manage Lists||Create & Delete Lists. Add/Remove Columns. Add/Remove Public Views||x||x||x|
|Override List Behaviors||Discard/Check In a Document checked out to another user. Override Read/Edit only their own items setting.||x||x|
|Add Items||Add Items to a list or library||x||x||x||x|
|Edit Items||Edit items in lists. Edit Documents. Customize Web Part Pages in document libraries||x||x||x||x|
|Delete Items||Delete items in lists and libraries||x||x||x||x|
|View Items||View items in lists and libraries||x||x||x||x||x||x|
|Approve Items||Approve a minor version of a list item or document||x||x|
|Open Items||View the source of documents with server side file handlers. e.g. User can open the document but cannot download to their local computer.||x||x||x||x||x|
|View Versions||View past versions of a list item or document||x||x||x||x||x||x|
|Delete Versions||Delete past versions of a list item or document||x||x||x||x|
|Create Alerts||Can create Alerts on lists and items||x||x||x||x||x||x|
|View Application Pages||View forms, views and application pages. Enumerate lists.||x||x||x||x||x||x||x|
|Site||Manage Permissions||Create and Change Permission Levels on the site and assign permissions to users and groups||x|
|View Web Analytics data||View Reports on Web Site Usage||x|
|Create Subsites||Create child sites of the current site||x|
|Manage Web SIte||Perform All Admin Tasks. E.g. the Site Settings menu item||x|
|Add & Customize Pages||Add, Change, Delete HTML pages or web part pages using SharePoint Designer or similar||x||x|
|Apply Themes and Borders||Apply a theme or borders to the entire web site||x||x|
|Apply Style Sheets||Apply a style sheet (CSS file) to the web site||x||x|
|Create Groups||Create a group of users for use anywhere in the site collection||x|
|Browse Directories||Enumerate files and folders in a web site using SharePoint Designer||x||x||x||x|
|Use Self Service Site Creation||Create a Web Site using Self Service Site Creation.||x||x||x||x||x||x|
|View Pages||View pages in a site||x||x||x||x||x||x|
|Enumerate Permissions||Enumerate permissions on the site, list, folder, document or item.||x|
|Browse User Information||View information about users of the web site||x||x||x||x||x||x||x|
|Manage Alerts||Manage alerts for all users of the web site||x|
|Use Remote Interfaces||Use SOAP, Web DAV, Client Side Object Model etc||x||x||x||x||x||x||x|
|Use Client Integration Features||Use features such as launch client applications. Without this, documents can only be worked on locally and then uploaded||x||x||x||x||x||x||x|
|Open||Allows the user to open the Web Site, List, Library or Folder. e.g. container to get to an item.||x||x||x||x||x||x||x|
|Edit Personal User Information||Allows a user to change his or her own user information such as picture.||x||x||x||x|
|Personal||Manage Personal Views||Create, Change, and Delete Personal Views of Lists||x||x||x||x|
|Add/Remove Personal Web Parts||Add or Remove Personal Web Parts on a Web Part Page||x||x||x||x|
|Update Personal Web Parts||Update Web Parts to display personalized information||x||x||x||x|
Creating your own custom permission level
If the above 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 in-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.
As well as the default SharePoint Groups within a SharePoint Team Site, it is also possible to create your own 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 an Active Directory Group. With Active Directory Groups, you can add them to a SharePoint Group. So a 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 I personally find Active Directory Groups more useful, since I 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, I 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 was 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, my 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 who 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 good. 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?
As far as I am concerned, 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.
|AD Groups||SP Groups|
|Can be Nested in a SharePoint Group||Yes||No|
|Membership Changed by a User||No||Yes|
|Membership enumerated in SharePoint Permission Reports||No||Yes|
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 should have on items in a list or library in SharePoint 2013 of 50,000. The limits and boundaries can be found here: https://technet.microsoft.com/en-us/library/cc262787.aspx. At the time of writing, I do not know if that limit has been increased for SharePoint 2016 Permissions, but there have been at least some increases in the limits: http://mstechtalk.com/comparing-sharepoint-2016-boundaries-and-limitations-with-sharepoint-2013-2010/
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.
Limited Access is nothing to be concerned about. Some people I have spoken to express their 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.
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.
There are some other Permissions tips that can be found here:
I hope this Permissions Guide has proven useful. Please contact email@example.com if you have any suggestions for edits.
The permissions guide is also available for SharePoint 2010 which can be found here: https://lightningtools.com/sharepoint_2010/sharepoint-2010-permissions-management-guide/
We hope that you found this SharePoint 2016 Permissions Guide useful. If you did, please share it!