User-centric permission management is one of SharePoint's biggest selling features and yet it is often misunderstood and, at times, poorly executed. Permissions are usually managed by IT, and they are often hesitant to relinquish control. We are however, seeing more and more of our clients attempting to decentralize permission management to capture value from the platform and to simplify the permission management process. Just handing over control to site owners though has proven to be a challenge. Site owners are usually business users who have been tasked with managing their team site's permissions by their manager. They are given complicated SharePoint permissions training material full of tech-jargon and are expected to just figure it out. This post is an attempt to simplify the permission management language and provide a clear overview for SharePoint site owners (particularly collaboration site owners).
When discussing permissions in SharePoint, one is really talking about access to information: who has access and what type of access he/she/they have. SharePoint empowers site owners to manage the permissions levels of their information and (if needed) it allows them to take a granular approach to permission management.
The most common permission structure for a team site is who has access to view, who has access to contribute, and who has ownership control over the site's content and/or the site.
- Securable object – "What" is having its accessed controlled
- User or Group – "Who" is being granted access
- Permission Level – "How Much" access is being granted
For each securable object on a SharePoint site, a site owner must ask these questions. We use a permission planning table to help capture the required information to these questions (shown later in the post).
The other important component of permission management is the concept of inherited permissions. By default, permission structures are inherited in SharePoint. This means that permissions set-up at the parent level automatically cascade down in the hierarchy, applying to every securable object on the parent site, as well as all securable objects on any sub-sites (also referred to as child sites).
Permission inheritance is the default to make managing permissions easier. This allows site owners to change permissions in one place and have it automatically reflected throughout their site structure.
Broken inheritance is when a site owner changes permissions on a child item or a child site within a site hierarchy. This creates a unique permission structure. Once permissions are broken, changes at the parent level will not cascade down to the child level that has a unique permission structure. In essence, when a site owner breaks permissions, they are in effect creating a new parent. Each unique permission structure must have their permissions managed separately.
Permissions can be re-inherited after they have been broken. Be aware though, once you re-inherit permissions, your unique permission structure ceases to exist (you can't get it back).
A great tool that we have found to help examine permissions inheritance is a free solution on Codeplex called Access Checker. Using this tool a site owner can, at a glance, quickly see where permissions are inherited and where permissions are broken within their site hierarchy.
Here are some helpful tidbits to keep in mind when managing permissions:
- It is easiest to manage permissions at the site-level. Wherever possible, avoid breaking permissions within a site! We recommend creating a sub-site when a unique permission structure must be applied.
- Managing permissions at the item level (rather than at the site level) will quickly become overwhelming for site owners and is the method most susceptible to errors (the wrong access being granted or restricted to the wrong users).
Users and Groups:
- ALWAYS user SharePoint Groups to grant access! Avoid assigning direct permissions to user accounts or Active Directory (AD) groups. By using SharePoint Groups, site owners can quickly change access to securable objects for many users at a time.
- AD Groups and user accounts can both be added as members to SharePoint Groups.
- SharePoint Groups cannot be added as members to other SharePoint Groups. They can however be the owner of a SharePoint Group.
- Be aware that SharePoint Groups can be used across a site collection. Before making changes to the membership of a SharePoint Group, check to make sure the group isn't being used elsewhere on the site collection.
AD Groups vs. User Accounts
- AD Groups: PROS
- Can be used anywhere on the intranet (not limited to a site collection)
- Can be email enabled
- IT controls (great for maintaining audit trails)
- AD Groups: CONS
- IT controls (only IT can create the group and edit its membership)
- No visibility within SharePoint into what accounts are within the AD Group
- User accounts: PROS
- Visibility (you can see group membership if the group owner allows this)
- Site owners can control membership (they can have the ability to add and remove user accounts from SharePoint Groups without IT)
- User accounts: CONS
- Limited audit trail
- Must be manually entered into every SharePoint Group
- Rule of thumb:
- Use AD Groups if audit trails are important
- Use AD Groups for large groups of users (i.e. All Employee Groups)
- Use individual user accounts if site owner control over access is important
- Use individual user accounts for sites where access is limited
- We have seen very few scenarios where permissions levels other than full control, contribute, and read are needed. Wherever possible, stick to these three and maintain the SharePoint group naming convention of Owners, Members and Visitors.
- In unique permission structures, SharePoint helps you quickly set-up Owner, Member, and Visitor groups (People and Groups > Groups > Set Up Groups)
Permission Planning Tool
For permission planning, we like to use this table (customized to match our client's collaboration site structure) to help site owners:
It's low-fi, but it always gets the job done :)