Permissions – A Critical Piece of the SharePoint Picture

Introduction

Permissions act as the gateway and firewall to your SharePoint objects. The fact that SharePoint is (generally) available to all your staff in house and via the Internet is good news for ease of access, but would be bad news for data security if permissions aren’t set properly.

Permissions can be one of the most complicated areas to manage in SharePoint, and if not managed well can turn people off of SharePoint very quickly. For example, if I’ve stored something in SharePoint that I believed to be private, and other people see it, my faith in SharePoint is forever shaken.

The Basics

In SharePoint you give people access by granting permissions to “Securable Objects”. Securable Objects include sites, lists, libraries, folders, documents, and list items. You cannot apply permissions to particular columns (fields).

Though you can grant permissions to any and all of these securable objects, it is best to keep it as simple as possible and try to grant permissions only at the site level, and use permissions inheritance (see below) to flow down to the contained objects.

Sometimes, maybe even often, we need to apply permission to individual document libraries, lists, folders, etc. However, it is important to keep these individual permissions as minimal as possible, since each unique permission set requires attention and management.

In other words, it’s important to balance the need for protecting SharePoint objects, against the administrative overhead associated with managing that protection. For example, if the finance department must have the budget numbers locked down, then you would apply unique permissions to their document library or folder. But if a finance staff member leaves or is hired, we need to remember that the finance documents have unique permissions and you will need to look at them.

We find it useful to think of SharePoint permissions in terms of “who can do what to what “. This captures the three main things that we talk about with permissions people or groups, permission levels, and SharePoint objects. See the graphic below.

Inherited and Unique Permissions

Inheritance is an important concept. Consider a parent site that contains a document library. If the document library is set up to inherit permissions from the parent site, then you need only manage the parent permissions; the document library permissions are taken care of automatically. However, if the library requires unique permissions (the opposite of inherited), then you need to manage those permissions separately and uniquely from the site level permissions. Whereas this is often necessary, having unique permissions does create additional administrative overhead for the site administrator(s).

The same thinking and structure applies to inheriting from a site to a list or library, or from a list to a folder or an item in that list, or from a library to a folder or document in that library.

Best Practices

We always create a table in Word or in SharePoint list that captures “who can do what to what”. This is very useful for designing, applying, and maintaining permissions in SharePoint as it creates a structured view it is much easier to read than going into SharePoint and clicking on the permissions screens. I have such a template if you need one.

One of the practices we highly recommend is to apply permissions only at the group level. You can set individual permissions, to say John Smith has access to this document library, however we recommend instead of creating a group with a meaningful name, such as ACCOUNTING CLERKS, setting permissions such that ACCOUNTING CLERKS have read access to the library, and then adding John Smith to that group. This creates a structure that is somewhat self-documenting, and makes it easier to change her missions if John Smith leaves or is replaced, or has an assistant join him. The changes to permissions come about just by changing the group membership. In some environments this can be done with active directory groups, with a similar approach and thinking.

Summary

So the simplest of all permission structures, and the one easiest to maintain, and easiest to understand (for example if a new SharePoint administrator takes over the site) would be as follows:(we recognize there are a few cases where the where the simple structure will work, but it is a starting point to which we would strive to remain close)

1. Permissions applied only at the site level, with permissions inherited to everything else in the site.
2. Standard group names and permissions level: Site-name Owners with full control, Site-name Members with contribute access, Site-name Visitors with read-only access.
3. Site admins (1 or 2 people) are added to the owners group. .
4. Site users (all of the regular users) are added to the members group.
5. Visitors (if any) are added to the visitors group.
6. When staff or contractors are added or removed from the business, they are added or removed from the appropriate SharePoint group.

Please comment below and share if this blog post helped you, or if you have any questions.

Happy permissioning!

Gerry Brimacombe, Lightlever Systems Inc.

P.S. For a 9-minute video with key "How-To’s" for setting permissions in SharePoint see this video.

by Gerry Brimacombe via Everyone's Blog Posts - SharePoint Community