How to Make Sense of SharePoint Permissions
Permissions in SharePoint are about as scary as spiders are to most people. This doesn’t have to be the case if you arm yourself with the knowledge to make informed decisions. In this blog post, I’ll walk you through all the different options, as well as a few scenarios to help you make sense of it all.
First of all, permissions can be managed from various apps and platforms. Three years ago, our only choices for SharePoint were SharePoint Groups and Security Groups. However, with the launch of Office 365 Groups in September 2015, how we deal with permissions has forever changed… and it was made a lot easier.
In SharePoint On-Premises, a site can be created using a couple of different options:
- Unique Permissions
- Inherited Permissions (from site or site collection)
When we select unique permissions, it will allow us to create new SharePoint Groups, which by default will have the following permissions:
- Site Owners
- Site Members
- Site Visitors
In SharePoint Groups, you can add members, which is done in SharePoint, not Active Directory. This is not good practice as the members will stay in the Groups even when disabled on Active Directory.
Creating Security Groups in Active Directory is a better way of handling members (users) who join and leave the company.
For example: if you have a Human Resources Security Group, people will be added or removed from this Group as directed by Payroll.
You can still use SharePoint Groups and add the Security Groups to them, just not single users.
Standard Permission Levels
Once members (Security Groups) are added to these SharePoint Groups, permissions can be configured. The standard groups are set up for Full Control, Edit, and Read.
Below you’ll see the default permissions in SharePoint:
Figure 1: Default Permissions in SharePoint
Your Site Members Group will automatically have Edit rights. I would change this to Contribute, as Edit rights can also delete Apps.
Add Your Own Permission Levels
It’s entirely possible to create your own permission levels. However, since I don’t want to complicate my permissions, I always add Contribute, cannot delete.
This enables users to add content without being able to delete content. I don’t do this to limit the functionality that users have, but when launching new Intranets and Sites, this comes in handy.
SharePoint Online integrates with the Office 365 Apps and Services, which allow us to use “Security Groups” or identities that are already created in other applications. SharePoint and Security Groups can still be used (as explained above) for SharePoint On-Premises.
Office 365 Groups
As mentioned, Office 365 Groups supplies a communal workspace through Outlook. Users can create a Group in Outlook, which provisions a shared mailbox, calendar, and distribution list. This also applies the permissions to the members who would use that “workspace.”
The most popular way of creating Office 365 Groups would be through Outlook, Yammer, or Microsoft Teams.
Our blog post, “Everything You Should Know About Microsoft Teams,” explains what happens when an Office 365 Group is created through the Teams creation process. As many Office 365 Groups were created through Outlook (before the launch of Teams), many companies were suddenly faced with how to address their existing Groups and duplication, due to creation of new Microsoft Teams.
Towards end of 2017, the functionality to connect new Microsoft Teams to existing (old) Office 365
Groups was officially released. Problem solved.
“When you delete a group, you are permanently removing the group team site,
group conversations, email messages, Yammer messages, files, calendar events,
and any other related information.
If you deleted the group by mistake, you can ask your IT admin
to recover the group within 30 days of it being deleted.”
Azure Active Directory
Office 365 Groups are similar to the Security Groups we used to create for our File Shares, so you can still create these Security Groups directly in Azure Active Directory.
So, why do I prefer using Office 365 Groups? Well, I can create these without access to Azure, and they’re created at the time that I’m creating the environment that I need to work with my Team (i.e. Outlook, Teams, Yammer).
By now, you might be asking why I’m elaborating about Teams in a blog about permissions. Well, most of your SharePoint Site provisioning will happen through Teams.
Let’s recap that: When a Microsoft Team is created, it provisions an Office 365 Group, Distribution list, Security Group (Group Identity in Azure Active Directory for permissions), Shared Mailbox, Shared Calendar, SharePoint Site (Collection), Planner, OneNote, Group in Stream, and Workspace in PowerBI.
When you build a Microsoft Team for Human Resources, they will have the following:
- Microsoft Team
- SharePoint Site (called Human Resources)
- OneNote, Planner, Shared Mailbox, Shared Calendar
- Distribution List (called Human Resources, which can be used in Outlook)
- Security Group used for the permissions (in Azure Active Directory)
Figure 2: Microsoft Team Members & Owners
Here are the Groups that are automatically added to the SharePoint site. (Yes, they’re SharePoint Groups, but wait until you see what’s inside.)
Figure 3: SharePoint Groups
In the Members group, you’ll notice that it does not have people added for permissions, but rather, the “Security Group” created for the Team has been added inside this SharePoint Group:
Figure 4: Group added in the SharePoint Group
The Owner and Members of the Team automatically gets Site Collection Administration on the SharePoint Site as well. But keep in mind that it could be dangerous on a SharePoint site.
I would use Office 365 Groups for permissions in SharePoint going forward and would create as many of my SharePoint sites as possible through Microsoft Teams.
SharePoint Team Sites
SharePoint Team Sites also create Office 365 Groups, but these just don’t have a Microsoft Team that accompanies it. The same rules apply though, and if you do create a Microsoft Team later, you’ll be able to link it to the existing Office 365 Group or SharePoint Team Site.
SharePoint Communication Sites
These sites do not have Office 365 Groups associated with them. They’re created with SharePoint Groups by default, with no members added. You would add members to these groups or add existing Office 365 groups into these SharePoint Groups.
Access Request Settings and Sharing of Site, Files & Folders
On the Permission Settings Page, you’ll notice Access Request Settings. This is where you can configure Access Request Emails (from the SharePoint side). This is also where you allow members to share the site or content externally.
Personally, I switch this off. SharePoint allows you to share content, apps, and sites externally with people, giving them the same permission levels you have. When it’s a site created through the Microsoft Team, I prefer the Member asking for a new member to be added on the Microsoft Team side, who then adds the person to the Office 365 Group.
Figure 5: Access Requests / Sharing
Inheritance of Permissions
Permissions are set up to always inherit, and when you add apps to a SharePoint, the apps will inherit the same permissions as the “parent.” The same goes for channels in a Team: each channel inherits the permission from the Team (Office 365 Group).
Permissions can be changed on the following levels:
- Site Collection
- Site (subsite)
- Application (Document Library or List)
- Folder (in a Document Library)
- Item (Document in a Library or Folder)
I train my users to NOT “break” permissions down below the Application level. If possible, permissions should stay the same throughout the site and all apps, folders, documents, and items.
Yes, there are exceptions! Let’s take another look at the Human Resources example.
Let’s say they have a Team with many channels (each channel is a folder in the SharePoint Document Library). On the SharePoint site, they’ve added other Apps which are used (Libraries and Lists), and currently, everyone one in the Team has access to everything (Edit rights).
Now, HR has a requirement for a library, which only selected people should have access to, not the whole Team. I advise against this every single time. Either create a new Microsoft Team specifically for that group of people (I’m sure they share other content as well) or share a folder from OneDrive.
Keep your Microsoft Team and SharePoint site simple, or you’ll spend the rest of your days micro-managing the permissions.
OneDrive for Business
Content in OneDrive is NOT shared, at least until you share it. Many users are nervous when using their company’s OneDrive, but no one can see your content until you share it.
Sharing Files from OneDrive
This has become so much easier. All you need to do is right-click on a file and click on Share.
Figure 6: Share files from OneDrive
You can even share files directly from the Office Application now:
Figure 7: Share from Office File
Type of Permissions and Expiry Dates
Keep in mind that you can set the permissions on the file, as well as the expiration date when sharing from OneDrive for Business.
Figure 8: Sharing settings and Expiry Dates
Delve uses Office Graph to compile data around you and the colleagues you work with. It organizes content on what could be most relevant to you.
You'll only see documents you have access to.
You can see your private documents and other documents that you have access to.
Other people can see their documents and documents that they have access to.
Figure 9: Microsoft Delve
Permissions is not something to be taken lightly. Keep up to date with any changes and updates to features and ensure that your users and Team members understand permissions and the impact they have on the security of your data.
Furthermore, risk can be mitigated by trusting your users with the knowledge and the tools to manage their environments.
Tracy is a Microsoft MVP and an energetic, hyperactive adrenaline junkie who sees challenges and issues as opportunities and thrives on improving processes, environments and the general quality of life. Her broad knowledge about IT and Business gives her the ability to communicate on both levels and convey meaningful requirements and narrow the (ever present) gap between the two.