Secret SharePoint: Permissions and Inheritance
Locks and keys have been a standard way to protect our stuff for centuries. We’ve needed ways to protect our stuff since we started collecting it. Protection can be a difficult and expensive proposition. Consider the fortifications at Fort Knox and the effort that the Department of the Treasury uses to protect our gold reserves – regardless of our currency not being tied to our holdings in gold.
Permissions are Hard
Fort Knox has a no-access policy. There’s no looking, no touching, and definitely no taking. Effectively, they have permissions that are on or off. You either have access or you don’t. However, the permissions that we have in our environments are substantially more complex. Can someone create? Can they view? Can they change? Can they delete? This and the myriad of permissions that are available in SharePoint makes it difficult to ensure the right people have the right access to the right place.
Consider an organization with 100 people who have 10 different kinds of permission in 100 different places. That’s 100,000 combinations. That’s more than anyone could possibly manage. To make the challenge manageable, SharePoint offers three tools: Groups, Permission Levels, and Inheritance.
Rather than individually assigning permissions, we frequently assign permissions to groups and then the users in those groups inherit those permissions. SharePoint, in fact, supports two different kinds of groups – one of which has two variants itself. The first are SharePoint native groups.
Whenever a site is created, there are a set of groups created. These groups are Owners, Members, and Visitors. The Owners can do practically anything they would like. Members can contribute information to the site. Visitors are allowed to view what is in the site. These are SharePoint native groups. They contain Active Directory (AD) users or groups. Thus you can have a SharePoint Visitors group that contains the Active Directory Domain Users group to allow everyone in the organization to view the information in the site.
Active Directory groups, when in Office 365, come in two different forms. Office 365 and SharePoint Online are built on Azure Active Directory. This is a form of Active Directory that is hosted by Microsoft. It can either be synchronized with your local Active Directory or can be set up completely separately.
Microsoft introduced Groups as an offering that bundled the functionality of SharePoint with the email distribution and security properties of an Active Directory group. The result is that Office 365 Groups are an Active Directory group. You can assign permission to a SharePoint site to an Office 365 group, because, by their nature, they are simply Azure Active Directory groups with add-ons.
Groups collect users to simplify the number of items that we need to manage. Permission levels do the same for individual permissions.
Permission levels are groups for permissions. SharePoint includes 32 individual permissions, ranging from the obscure to the basic ability to view, create, modify, or delete items. These permission levels are a way to roll up these individual permissions into meaningful groupings like Full Control, Design, Edit, and Read. By rolling up permissions into levels, we have fewer items, and therefore fewer items to manage.
Perhaps the most powerful way to reduce the burden of creating permissions is to allow the permissions for child areas and items to follow those of the parent. Thus, a document library uses – or inherits – the same permissions as the site. Similarly, the folders in the document libraries inherit from the document library. If every one of the 100 locations share the same permissions, you can set them once for the entire site and you’re done. 100,000 combinations become maybe 20 or 30 combinations through the use of all of these techniques for simplification.
However, it’s rare that everything in an entire site or site collection will have exactly the same permissions. That’s why SharePoint allows you to break inheritance and allow items – at any level – to have their own unique permissions. For instance, permissions can be applied to a document library and all its items, a single folder and its items, or even an individual item. This allows you to balance the need for unique permissions with the desire to minimize the amount of work that must be done to manage permissions.
When describing permissions, it’s fitting to end with a caution. The caution is that SharePoint – by default – will limit access control list entries to 50,000 per document library. An access control list contains a record for each group or user that is assigned a permission. The limitation is because the work to process all those access control list entries can be taxing on the system. You can safely stay under this number by using groups and minimizing the places where you break inheritance. In particular, you should avoid setting unique permissions on individual files and instead attempt to use folders or other containers where possible. Inherited permissions don’t require additional access control list entries. Between this and using groups (which take one entry) instead of providing direct permission to users, you can minimize the number of access control list entries necessary.
Into the Matrix
If you’d like to see exactly how SharePoint maps permissions into permission levels and how this lines up with the default groups that SharePoint creates, you can get our SharePoint Security Matrix