Microsoft Office 365 SharePoint Permissions can be very daunting to users who are expected to control security on business related content within an organization.
Microsoft SharePoint, and SharePoint Online are designed to allow the business user to make decisions on who can have access to SharePoint Team Sites, SharePoint Lists, and the List Items or Documents within the sites that they manage. This is known as de-centralized permissions management. In other words, it is better for the users who work within the business processes (departments or projects) to manage the permissions, as they know who should have access to their content better than an IT Help Desk perhaps would. Of course, a Help Desk user would also require access themselves to the content in order to manage permissions which in itself is a risk when it comes to confidential information. Therefore, Site Owners or Site Collection Administrators are given the responsibility to manage the SharePoint Permissions within their respective departments.
Without the proper understanding and training, Microsoft Office 365 SharePoint Permissions can become a mess. Information Workers tend to Approve Share Requests too quickly without thinking of a smarter way to grant permissions, thus leading to unnecessary broken permission inheritance on documents, folders and list items. Broken Permission Inheritance on these items leads to difficulty trying to report on who has permissions to what, and also difficulty in removing the direct permissions granted to an employee now leaving the company. Adding Users to Groups without the understanding of what else those groups has access too is also a problem. Innocently, you may accept a share request, not realising that the same default group for the shared site also has permissions to many other sites which perhaps the user in question should not have access too. There are many other issues with Office 365 SharePoint Permissions that can be easily addressed with a bit of careful planning, thought and education. Before we dive into resolving those issues, let’s first understand the architecture around SharePoint Permissions.
Users in Microsoft Office 365 can be granted permissions in several different ways:
- User is assigned a direct permission on an object such as a site, list, or document.
- User is directly a member of a SharePoint Group, and the SharePoint Group is assigned permissions to an object such as a site, list, or document.
- User is a member of an Active Directory Group, and the Active Directory Group is assigned a direct permission to an object such as a site, list, or document.
- User is a member of an Active Directory Group, and the Active Directory Group is nested within a SharePoint Group, and the SharePoint Group is permissioned on an object such as a site, list, or document.
- User is a member of an Office 365 Group. The Office 365 Group is essentially the same as a Active Directory Group and can be nested in a SharePoint Group or directly assigned permissions to an object such as a site, list, or document.
There are some organizations that have a strict rule against using Active Directory groups, and some against using SharePoint Groups. However, in most organizations, you will find there is a mixture of all of the above.
User is assigned direct permission on an object such as a list or document
It is possible to completely skip using groups. You can literally assign a permission to a user on an object such as a site, list or document. The problem with this is manageability. The reports will actually be quite nice to read (if not lengthy). You will however see a nice report showing each users permissions against an object with no obscurity. However, ask yourself what would happen if someone was to leave the company. You would never have enough time to trawl through every single site, list, folder, document or list item to check whether that particular user was granted permissions. Then you would have to delete the permissions. It would be crazy to consider this model for that reason. However, people do it! Why do they do it? Well, if you click ‘Share’ on a document, or a folder, you’ll be doing exactly that. You will be breaking the permission inheritance on the folder or document, and the user will be granted direct permissions. This can be avoided with a bit of thought and planning which we will discuss in the Sharing section below. Of course, you could simply disable the user in Office 365 which would stop them from authenticating. However, they will still show up in permission reports and SharePoint Groups which will lead to confusion in the workplace.
This method is quite nice. When you create a new Team Site which has Unique Permissions, you will have the option to create three new groups named sitename_Owners, sitename_Members, and sitename_Readers. The Owners group will be granted Full Control to the Site, Members will be granted Edit (from SharePoint 2013 onwards), and Readers will be granted Read permissions to the site. You can very easily add users to these groups and they will receive the relevant permissions. Here is the problem… Wouldn’t it be nice if you had your departments of users which could be added as members of these groups to save adding individuals? We could then put ‘Sales’ into our Members Group for a given site, ‘Marketing’ into the Readers Group for a given site etc… That’s where SharePoint Groups alone won’t help. You cannot nest a SharePoint Group into a SharePoint Group! You can however, add an Active Directory Group into a SharePoint Group! More on that idea in a moment. The other problem is with the permissions assigned to these groups. The Edit permission is a powerful permission. The Read permission is not. Users with Edit permissions get the ability to delete an entire list or library of documents if they so choose. What’s worse, is that when you click ‘Share’ at a site level, the user you shared the site with will become a member of the Members group, and that members groups has Edit Permissions by default! <- Read that bit again and think about it for a moment. If you want a way to work around this issue, Read the bit about Default Groups below.
User is a member of an Active Directory Group, and the Active Directory Group is assigned a direct permission to an object such as a site, list or document.
You would typically find that your organization has already given thought and planning around the departments within the organization and that AD Groups already exist for those departments. Therefore, you can simply grant the AD Group direct permissions to Sites, Lists, Documents, Folders and Items. The user will be granted permission, and most importantly there will be a single point of removal should that user decide to leave the organization. In return, you as a user give up a bit of control! You cannot (using SharePoint) see the users within those groups and neither can you change the membership of them. Also, the permission reports will only tell you that the AD Group has permission, but you won’t see the individuals. DeliverPoint overcomes this problem in the permission reporting by enumerating the AD Groups.
This method is better than the above, since as a user you do get a bit more control and manageability. You can add AD Groups to existing SharePoint Groups. Therefore adding Sales to Members, and Marketing to Readers isn’t a problem. You still cannot enumerate the AD Groups unless you use DeliverPoint, but it will be a nice balance giving you a single point of removal and flexibility on which AD Groups get permissions to your content.
Surely, this is the perfect option. Office 365 Groups are new to Office 365 and at the time of writing have been in the product for around a year. Office 365 Groups are in fact AD Groups, but you get the ability to manage the members! So the only drawback to the above has been addressed using Office 365 Groups and nesting them within SharePoint Groups to assign permissions. The out-of-the-box permission reports still won’t show you a nice list of users with permissions to your site, but at least you have some ability to work out the permission structure. DeliverPoint still helps in this regard.
Sharing
With Office 365 SharePoint Permissions, it is now possible to ‘Share’ a Site, List, or item with another party. So, firstly let’s talk about who can Share! Any users who themselves have at least ‘Contribute’ permissions can Share a Site, List, Library, Document or Folder. It won’t automatically grant permissions unless you yourself have Full Control. If you don’t have Full Control, an access request is made to the email address specified for Access Requests at the Site Collection Level. The email provides the approver with the ability to grant or deny permissions. That ‘should’ work fine, so why doesn’t it? Consider that a sales person needs permissions to an Excel workbook that contains product pricing. That seems like a legitimate request. The business logic makes sense! A sales person should be able to see the product pricing. So, the approver clicks Approve and the permission is granted. What has actually happened, is that the documents permission inheritance is now broken and no longer inherits its permissions from the library. Also, the user has been granted a direct permission of either Contribute or Read (depending on choice when clicking Share). What should have happened is that the Approver thinks for a moment. Is there a better way whereby I can give this Sales person permissions to this Product Pricing sheet? Should they for example have permissions to the entire library, or the site? Perhaps it would be better to add them to a SharePoint Group or AD Group which would mean I don’t break permission inheritance and I don’t have a nightmare on my hands when I try to remove this users permissions in the future. Or I don’t have a nightmare wondering why I have so many documents with broken permission inheritance. The other REALLY important thing to understand, is that the behaviour is different for Sharing at Site, List and Item level. The below will help you understand what happens when you click share at any of these levels.
Sharing at Site Level
When you click Share at site level, the sites permission inheritance is not affected. The user being granted permissions is given access via the default group. The default group unless you have changed it will be the Members group. The members group has Edit permissions by default.
To avoid giving users Edit Permissions, I would recommend changing the default group, to a group with lower permissions. See the Default Group section below.
Sharing at List/Library level
When you share a list or a library, the permission inheritance for the library is broken. The default permission level granted to the user is ‘Edit’.
To avoid breaking permission inheritance on the list and assigning Edit permissions to a user. I would recommend thinking carefully about where documents are stored. Rather than a single document library within a site, consider multiple document libraries for different types of documents for different groups of users. This would avoid sharing a document library and granting Edit permissions each time someone requires access.
Sharing at List Item, Folder or Document level
When you share at item level, the permission inheritance for the item is broken, and the user is granted ‘Contribute’ permissions. Note that even though the combo box in the top right hand corner says ‘Can Edit’. The actual permission assigned is ‘Contribute’.
To avoid breaking Office 365 SharePoint permissions inheritance on individual documents, consider where documents are created. Perhaps plan for multiple document libraries and set permissions at library level rather than granting permission on an adhoc basis. Consider granting Office 365 SharePoint permissions at Site level through existing groups rather than simply accepting access requests on individual documents.
In the next section, we’ll look at Default Groups and how they can be used to your advantage to avoid inadvertently granting Edit permissions to individual users. An article you could read to understand the differences between Edit and Contribute can be found here: https://lightningtools.com/blog/edit-vs-contribute-sharepoint-2013-permissions-levels/
Default Groups
As I have pointed out above, an advantage of changing the Default Group within a site, is that you can give a lower level of permission by default when a user clicks Share at site level. In SharePoint 2010 and earlier, the default permission level was Contribute. The problem with Edit permissions is that the user will have the ability to delete entire lists and libraries. The Edit permission is more ideally suited to power users who will be able to add/remove columns within SharePoint libraries. But it shouldn’t be the default permission level for most users. I would recommend considering Contribute to be the default permission level instead. To achieve this, the following steps will help:
Create a new SharePoint Group
- Click the Site cog and choose Site Settings.
- Under Users and Permissions click People and Groups.
- Click the More link on the Quick Launch bar.
4. Click New, New Group.
5. Provide a name for the Group and select the Contribute Permission Level.
6. Click Create.
Note: I would recommend changing the Group Owner to the Top Level Site Owners group. This ensures that more than one user can change the membership of the group.
Make the Group the Default Group
To make the newly created group the default group:
- Choose Settings, Make Default Group.
Test the Share function
Test the Share function by clicking Share, and share the site with another user. You should find the user becomes a member of your new group and therefore receives Contribute permissions rather than Edit.
Permission Levels
Microsoft Office 365 SharePoint Permissions Levels are similar to those in SharePoint 2013 and SharePoint 2016. By default, the Office 365 SharePoint permissions levels will include:
- Full Control
- Design
- Edit
- Contribute
- Read
- View Only
It is possible to create your own custom Office 365 SharePoint permissions level if you require something slightly different. For example, you may want a permission level which allows users to create items, and edit items, but doesn’t allow for items to be deleted. Creating a custom permission level can be performed at the top level site within the Site Collection. I would recommend copying an existing permission level, providing it with a useful name and description, and then refining the permission to suit your requirements.
More information on Permission Levels can be found here: https://lightningtools.com/blog/sharepoint-permission-levels/
Understanding Limited Access
Another question I often hear is “How can we remove Limited Access from users?”. Strangely, some SharePoint tools also claim to clean up Limited Access.
Limited Access is not an issue. Limited Access is a permission level granted to a user so that the user can access an item such as a document which has been shared with them. If the user doesn’t yet have permissions to the parent list/site of the item, Limited Access will be automatically granted to the user allowing them to navigate to the item they have been granted permissions to. You can’t simply remove Limited Access from a user, but if you don’t like seeing it, then you could remove the permission on the item whereby permissions were granted. The problem is finding out which object that is. SharePoint does display on the yellow banner a list of items that have unique permissions. However, there could be a lot of items! DeliverPoint provides you with a unique permissions report allowing you to find all sites, lists, and items that a user has specifically been granted permissions to.
The SharePoint Online user interface isn’t designed to allow for bulk operations when it comes to Office 365 SharePoint permissions management. Bulk operations are sometimes required though. If you consider situations such as a user leaving your organization, or even a user starting your organization. It would be useful to remove all direct permissions, and remove the user from a large number of groups in one action. Many tools offer the ability to manage permissions in bulk with operations such as Copy Permissions, Delete Permissions, Transfer Permissions, and Grant Permissions. However, most are designed for the central IT department and don’t offer an interface convenient for Site Owners and Site Collection Administrators. DeliverPoint allows for these bulk operations to be performed within the context of SharePoint. This allows department SharePoint Champions to manipulate permissions quickly as users leave and join their departments.
An alternative to using a third party tool, is to use PowerShell to manipulate permissions in bulk operations. The following link displays some useful Powershell commands for removing users from groups, and adding users in bulk. https://technet.microsoft.com/en-us/library/mt771884.aspx
