Permissions Management in SharePoint 2013

Contents Overview............................................................................................................................................................................. 2 SharePoint Role Assignment ...................................................................................................................................... 4 SharePoint Groups vs. Active Directory Groups .................................................................................................. 6 Permission Levels ............................................................................................................................................................ 7 Action Plan ........................................................................................................................................................................ 9

Page 1 of 11

Permissions Management in SharePoint 2013 Security is always one of the most critical points in any Content Management System. Knowing who I am and what I can see or do in the system is essential. This sounds obvious but actually it's always very complex—in SharePoint 2013 as well. This article will cover an important segment of SharePoint administration and it has been prepared by Agnes Molnar, a SharePoint Server MVP. Agnes Molnar is International Consultant, ECM & Search Expert, and SharePoint Server MVP. She has been working with SharePoint technologies since 2001, and has developed dozens of SharePoint and implementations for commercial and government organizations. A coauthor and contributor to several SharePoint books, Agnes is a regular speaker at technical conferences and symposiums around the globe.

Overview When talking about security, we can identify two major steps in every system: authentication and authorization. 

Authentication is the process when the system identifies me, gets answer to the question "Who are you?", and verifies if you really are who you say you are.



Authorization is the process of verifying what you can see or do, or in other words —“you are permitted to do what you are trying to do.” Authorization always presupposes successful authentication.

Page 2 of 11

As SharePoint does role based on access control, the next thing to be aware of and understand is the role assignment. Role assignment has three main components in SharePoint: 

User or Group - the person or group of persons who gets the role.



Security Scope - the subject



Permission Level - the level of permission(s) the user or group is assigned to the subject.

Let me show you some examples: 





"Jeff needs to edit this document." o User: Jeff o Security Scope: this document o Permission Level: edit "Chris has to change the settings of this list." o User: Chris o Security Scope: this list o Permission Level: change the settings (admin) "HR and Marketing have to be able to read everything on this site." o Groups: HR, Marketing o Security Scope: this site o Permission Level: read

Page 3 of 11



"Why Gary can see these files in ‘Search’?!” o User: Gary o Security Scope: these files o Permission Level: read

SharePoint Role Assignment In SharePoint, there are several levels of available security scopes. These levels are organized into a well-defined hierarchy; therefore, we have a very clear inheritance — by default, all the permission settings are inherited from the parent level to its children. These levels are:    

Site List/Library Folder Item/Document

It’s also worth noting that we have permission inheritance by the site hierarchy as well, by default; every site inherits the role assignment from its parent.

In this case, using the default settings, every list and document library inherits the role assignments from the site (and the site inherits from its parent site), as well as the folders, subfolders and items inside. These settings can be, for example:   

Group Marketing has contribution (read or write) access to everything; Group Sales has read access to everything; Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

Page 4 of 11

If you use the default settings (inheritance) on each level, these groups will have read (Marketing) and contribution (HR) access to every list and library, every folder and subfolder, every item and document. For example, if you have a document library “Campaigns” with a folder for each year (2013, 2012 etc.), the Marketing group, Jeff, Joe, and Jim can add new documents, open and edit the existing ones, while the members of the Sales group will be able to read these documents but not modify them. But of course, you can break this inheritance by defining custom role assignment, on any level. In this case, you have the default role assignment on the site level (either set on this site or inherited from its parent site), but it’s not inherited to, and below the folder where you create the custom role assignment.

For example, let’s say we have the very same role assignment on site level:   

Group Marketing has contribution (read or write) access to everything; Group Sales has read access to everything; Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

But you have a specific folder in the document library “Campaigns” for the current year (2014) where you want the group ‘Sales’ to have contribution access as they might have to add or modify the current documents. In this case, you have to break the permission inheritance. The default role assignment after this will be identical with the current settings, but you can change it according to your needs:   

Group Marketing has contribution (read or write) access to everything; Group Sales has contribution (read or write) access to everything; Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

Page 5 of 11

Of course, you can do this on any level. On one hand, this is good as you can have as custom and complex permission settings on your content as you want. On the other hand, it’s a very big challenge and might be a huge risk due to its complexity. Note: In SharePoint 2013 and Office 365, it’s very simple to share documents or even folders, lists and libraries with your colleagues. This makes the end users’ lives much easier, but can be a real challenge for the administrators.

SharePoint Groups vs. Active Directory 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 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.

Page 6 of 11

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

Page 7 of 11

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.

Page 8 of 11

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 and exploring 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. Documentation Toolkit for SharePoint is free for 30 days - download free trial.

Page 9 of 11

Page 10 of 11