SharePoint permissions management – SharePoint groups and permission levels

In the first part of this article we talked about SharePoint role assignment, now we are going to cover other important segments of the SharePoint permissions management in SharePoint 2013 – SharePoint groups and permission levels.

SharePoint Groups vs. Active Directory Groups

A small side note on the groups.
As you likely know, you can create groups in SharePoint, and sometimes, this might lead to confusion. When your SharePoint farm is domain integrated and AD authenticated, you have AD groups as well. The similarities of AD and SharePoint groups might be confusing, as well as the differences. Let me clarify some points here:

• AD groups can contain (AD) users, of course, but they can also be organized into a hierarchy: every AD group can contain other AD group(s). They are always managed outside of the scope of SharePoint; domain admins have the responsibility to add, remove or modify groups and manage the memberships.
• With SharePoint groups, the picture is a bit different. SharePoint groups can contain (AD) users and AD groups. There’s no hierarchy of SharePoint groups – a SP group cannot contain any other SP group. It’s a big limitation. But on the other hand, SharePoint groups are administered inside SharePoint; therefore you don’t need to contact the domain administrators for every single change like group membership changes.

SharePoint permission levels

When working with role assignments, Permission Levels are the next thing we have to understand. The most commonly used and known are ‘Read’, ‘Contribute’ and ‘Full Control’ in SharePoint, but there are many more. Outside the box, we get the following Permission Levels:

For the full reference of these levels, please refer to this TechNet article: User permissions and permission levels in SharePoint 2013

Each of these permission levels is a combination of elemental permissions. These elemental permissions can be organized into three groups:

• List Permissions
• Site Permissions
• Personal Permissions

For example, the Contribute Permission Level consists the following:

1. List Permissions:

• Add Items
• Edit Items
• Delete Items
• View Items
• Open Items
• View Versions
• Delete Versions
• Create Alerts
• View Application Pages

2. Site Permissions:

• Browse Directories
• Use Self-Service Site Creation
• View Pages
• Browse User Information
• Use Remote Interfaces
• Use Client Integration Features
• Open
• Edit Personal User Information

3. Personal Permissions

• Manage Personal Views
• Add or Remove Personal Web parts
• Update Personal Web Parts

Besides using these OOTB levels, you can create your custom levels too. For example, you might have a requirement for a permission level that has the basic Contribute permissions except ‘Delete’. It is used very often at customers who have specific policies for version management and item deletion.

Action plan

As you can see, Permission Management is a complex task in SharePoint, and needs a complex solution supporting:

• User and Group Management
• Role Management
• Checking and consolidating Role Assignments

Except documenting SharePoint farm settings, Documentation Toolkit for SharePoint provides a detailed SharePoint permissions explorer and options to create and export permission reports and this is why it is a very good and useful solution that can be used during a SharePoint permissions management process.