Whitepaper

SharePoint Permissions
Introduction to SharePoint Permissions

MATIJA HANI

ACCELERATIO LTD. | Savska cesta 182, 10000 Zagreb, Croatia

Whitepaper SharePoint Permissions

About Matija

Matija Hani, a Faculty of Electrical Engineering

and Computing (FER) graduate, is a software
developer at Acceleratio, Ltd. He is currently the
lead software developer for the SPDocKit team.
This means that he spends most of his days
creating innovative solutions for SharePoint
admins. In addition to working at Acceleratio,
Matija enjoys spending time in the company of
good friends and colleagues followed by great
food and fine wine.

Page 1 of 18
Whitepaper SharePoint Permissions

Content

ABOUT MATIJA 1

CONTENT 2

SHAREPOINT PERMISSIONS 3

Introduction to permissions management 3

1. SharePoint Principals 4
Sample Demo 1 - Users and Groups 5

2. Securable Objects 7

3. SharePoint Permissions 8
Sample Demo 2 Manage Permission Levels 10

Role Assignments 12
Sample Demo 3 - Permission Management 14

Users with Privileged Access 15

Farm Administrators 15
Site Collection Administrators 15

Item-Level Permissions 16

CONCLUSION 17

SPDOCKIT ULTIMATE SHAREPOINT ADMIN TOOL 18

Page 2 of 18
Whitepaper SharePoint Permissions

SharePoint Permissions
Introduction to permissions management

All enterprises need tools and procedures to keep content secure. SharePoint comes
with a powerful set of tools that help you control access to content. The following
white paper will cover some concepts related to content security in a SharePoint farm.

Regardless of the environment in which you are trying to secure your content, you face
the challenge of identifying the following elements:

1) Principals: users or groups that need permissions

2) Securable Objects: objects that users can access only with permission

3) Permissions: the level of access a user has to securable objects

Page 3 of 18
Whitepaper SharePoint Permissions

1. SharePoint Principals

In SharePoint, permissions
are assigned to principals.

Principals can be SharePoint

users (SPuser) or SharePoint
groups (SPgroup).

A user in SharePoint is a person who has a user account from any authentication
provider supported by the Web application (Windows, ASP.NET membership provider,
etc.). Both AD users and AD groups are represented as SPUser objects.

A SharePoint user is defined at a site collection level, which means that if the same AD
user has permissions for multiple site collections, that user will have access to
multiple SPUser objects with different IDs for each site collection.

To access the list of users for a particular site, you should use the
following SPWeb properties:

SPWeb.SiteUsers
- a collection of all users in the site collection
SPWeb.AllUsers
- a collection of all users who are members of the current subsite
SPWeb.Users
- a collection of all users who have been directly given permissions for the
current subsite

Page 4 of 18
Whitepaper SharePoint Permissions

A SharePoint group is defined at a site collection level. It can only contain users (AD
users and AD groups). You cannot put SharePoint groups inside
other SharePoint groups.

The list of SharePoint groups can be accessed by using the following SPWeb properties:

SPWeb.SiteGroups
- a collection of all groups in the site collection
SPWeb.Groups
- a collection of all groups in the current subsite

Sample Demo 1 - Users and Groups

Example 1 List all SharePoint groups CSOM

//List of SharePoint groups on a site
var web = context.Web;
context.Load(web.SiteGroups);
context.ExecuteQuery();

foreach (var spGroup in web.SiteGroups)

{
Console.WriteLine(spGroup.Title + " - " + spGroup.Description);
}

Example 2 List all members of a SharePoint group using CSOM

//read all groups members for a SharePoint group
var web = context.Web;
context.Load(web, w => w.SiteGroups);
context.ExecuteQuery();

var spGroup = web.SiteGroups.GetByName("Demo Site Members");

context.Load(spGroup, group => group.Users);
context.ExecuteQuery();
foreach (var user in spGroup.Users)
{
Console.WriteLine(user.Title + " - " + user.LoginName + " - " +
user.PrincipalType);
}

Page 5 of 18
Whitepaper SharePoint Permissions

Example 3 Add a user to a SharePoint group using CSOM

//add new user to a SharePoint groups
var web = context.Web;
context.Load(web, w => w.SiteGroups);
context.ExecuteQuery();

var newUsr = web.EnsureUser("user@contoso.onmicrosoft.com");

context.Load(newUsr);
context.ExecuteQuery();

var spGroup = web.SiteGroups.GetByName("Demo Site Members");

context.Load(spGroup, group => group.Users);
context.ExecuteQuery();

spGroup.Users.AddUser(newUsr);
context.ExecuteQuery();

Page 6 of 18
Whitepaper SharePoint Permissions

2. Securable Objects

Securable objects can be sites, lists,

libraries, folders, documents, or
items.

Permissions on securable objects

are, by default, inherited from the
parent object.

This means that, by default,

everything within a site collection
will inherit permissions from the
root web.

You have the ability to stop inheriting permissions from any object. When you stop
inheriting permissions, all groups, users, and permission levels will be copied from the
parent object to the child object. After that, changes made to the parent object will no
longer affect the child object (and vice versa).

All securable objects (SPWeb, SPList, SPListItem) implement the SPSecurableObject

class. The most important members and methods of the SPSecurableObject class are:

SPSecurableObject.HasUniqueRoleAssignments
- a flag indicating whether this object inherits permissions from the parent
object
SPSecurableObject.RoleAssignments
- a collection of all permissions assignments for the current object
SPSecurableObject.BreakRoleInheritance()
- a command to stop inheriting permissions from the parent object
SPSecurableObject.ResetRoleInheritance()
- a command to delete unique permissions for this object and restore
permission inheritance from the parent object

Breaking inheritance allows you to uniquely secure your content, but you should keep
in mind that every uniquely secured scope you create increases the number of places
where you need to perform updates when you need to change the permissions for a
user or group.

Page 7 of 18
Whitepaper SharePoint Permissions

3. SharePoint Permissions

Permissions in SharePoint control the

access levels that a user should have
for a particular piece of content.
For instance, you could allow a user
to read a document, but not delete it.
To perform a given task in
SharePoint, the user requires
permission.
Permissions in SharePoint (referred as
base permissions) are represented as
a list of tasks that a user is allowed to
perform.

SharePoint 2013 comes with 33 built-in permissions that help you define content
access levels. Permissions are categorized as list permissions, site permissions, and
personal permissions, depending on the objects to which they are applied:

Site permissions examples:

o Create subsites: Create subsites such as team sites, meeting workspace sites, and
document workspace sites.
o Manage permissions: Create and change permission levels on the website and
assign permissions to users and groups.
o Add and customize pages: Add, change, or delete HTML pages or Web Part
pages, and edit the website.

List permissions examples:

o Manage lists: Create and delete lists, add or remove columns in a list, and add
or remove public views of a list.
o Add items: Add items to lists, and add documents to document libraries.
o Edit items: Edit items in lists, edit documents in document libraries, and
customize Web Part pages in document libraries.
o Delete items: Delete items from a list, and documents from a document library.

Page 8 of 18
Whitepaper SharePoint Permissions

Personal permissions examples:

o Manage personal views: Create, change, and delete personal views of lists.
o Add/remove personal Web Parts: Add or remove personal Web Parts on a Web
Part page.
o Update personal Web Parts: Update Web Parts to display personalized
information.

A complete list of SharePoint permissions can be found in the following TechNet

article: User permissions and permission levels in SharePoint 2013 .

Base permissions are too fine-grained to be assigned directly to a user. Instead,

SharePoint introduces permission levels and permission policies.

o Permission levels (sometimes referred to as roles) are sets of permissions that

you can assign to individual users, groups of users, or security groups, based
on the functional requirements of the users and on security considerations.
They are defined at a site collection level and, depending on the site template,
you will get a set of default permission levels. For a team site, you will get: View
Only, Limited Access, Read, Contribute, Edit, Design, and Full Control. While
permissions cannot be customized, you can modify existing or create new
permission levels. The only permission levels you cannot change are Limited
Access and Full Control.
o Permission policies allow you to grant or deny individual permissions at the
web application level. Use permission policies for centralized management of
permissions for users and groups that require permissions on the entire web
application, to avoid managing their permissions at multiple site collections.
Keep in mind that any permission policy you define for a user cannot be
overridden on a permission level. For example, if you were to create a
permission policy with deny on Delete Items and apply it to everyone, you
could not override this at the site collection level, regardless of individual user
permission levels.

Page 9 of 18
Whitepaper SharePoint Permissions

Sample Demo 2 Manage Permission Levels

Example 1 List all permission levels on a site collection using CSOM

//List of all defined permission levels
using (var context = new ClientContext(_siteUrl))
{
context.Credentials = new SharePointOnlineCredentials(_username,
_securePassword);
context.Load(context.Web, w => w.Title, w => w.RoleDefinitions);
context.ExecuteQuery();

var web = context.Web;

foreach (var role in web.RoleDefinitions)
{
Console.WriteLine(role.Name + " - " + role.Description);
}
}

Example 2 List all details for a single permission level using CSOM
//detailed view of all base permission for the Contribute permission level

var web = context.Web;

var contributeRole = web.RoleDefinitions.GetByName("Contribute");
context.Load(contributeRole);
context.ExecuteQuery();
foreach (PermissionKind basePermission in Enum.GetValues(typeof(Microsoft.Share
Point.Client.PermissionKind)))
{
if (contributeRole.BasePermissions.Has(basePermission))
{
Console.WriteLine(basePermission);
}
}

Page 10 of 18
Whitepaper SharePoint Permissions

Example 3 Copy a permission level using CSOM

//create a copy of the Contribute permission level with no Delete List Items ba
se permission
var web = context.Web;
var contributeRole = web.RoleDefinitions.GetByName("Contribute");
context.Load(contributeRole);
context.ExecuteQuery();

var contributeNoDelete = new RoleDefinitionCreationInformation();

contributeNoDelete.Name = "No Delete Contribute";
contributeNoDelete.Description = "Contribute without delete items";
contributeNoDelete.BasePermissions = new BasePermissions();

foreach (PermissionKind basePermission in Enum.GetValues(typeof(Microsoft.Share

Point.Client.PermissionKind)))
{
if (basePermission == PermissionKind.DeleteListItems)
{
continue;
}
if (contributeRole.BasePermissions.Has(basePermission))
{
contributeNoDelete.BasePermissions.Set(basePermission);
}
}
web.RoleDefinitions.Add(contributeNoDelete);
context.ExecuteQuery();

Page 11 of 18
Whitepaper SharePoint Permissions

Role Assignments

Role assignments link the following

security elements:

SPPrincipal (who)
SPSecurableObject (where)
SPRoleDefinition (what)

You can alter the Role Assignments

collection for any SPSecurable
object with unique permissions or
at the root web.

Another consideration, before you grant permissions to a user, is whether to grant the
permissions directly to the desired user or to use a SharePoint or AD group.

In most cases, you should rely on granting permissions to groups and managing the
groups memberships. Tracking permissions for individual users on a number of
uniquely secured objects is time-consuming and error prone.

Using AD groups allows AD DS to manage the users for you, so you can centralize
security with other enterprise applications that also rely on AD DS. For ease of
administration, it is still preferable not to grant permission to AD groups directly, but
to instead add them as members of SharePoint groups. You should also avoid using
AD groups that contain nested groups.

Page 12 of 18
Whitepaper SharePoint Permissions

Example of granting permissions through AD groups:

Using AD security groups also has a downside: security groups in SharePoint sites do
not provide full visibility for everything that occurs on the site.

For example, when a security group is added to a SharePoint group for a specific site,
the site will not appear in the users My Sites. The User Information List will not show
activity to individual users until they have contributed to the site. In addition, security
groups that have a deep nested structure might break SharePoint sites.

Based on these advantages and disadvantages, you should use the following
guidelines:

o On small collaboration sites, add users directly to SharePoint groups to

enable full visibility.
o For intranet sites that are broadly accessed by your users, use security groups,
because in these cases, you do not care about tracking the individual users
who accessed the intranet site home page.

Page 13 of 18
Whitepaper SharePoint Permissions

Sample Demo 3 - Permission Management

Example 1 List all directly assigned permissions

//list all directly assigned permissions on a securable object
var web = context.Web;
context.Load(web, w => w.RoleAssignments
.Include(assignment => assignment.Member,
assignment => assignment.RoleDefinitionBindings));
context.ExecuteQuery();

foreach (var roleAssignment in web.RoleAssignments)

{
Console.WriteLine(roleAssignment.Member.Title + " - " +
roleAssignment.RoleDefinitionBindings[0].Name);
}

Example 2 Add permissions for a user on a securable object

//assing permissions to a user on a securable object
var web = context.Web;
context.Load(web, w => w.RoleAssignments);
context.ExecuteQuery();

var contributeRole = web.RoleDefinitions.GetByName("Custom Contribute");

context.Load(contributeRole);
context.ExecuteQuery();

var newUsr = web.EnsureUser("user@contoso.onmicrosoft.com");

context.Load(newUsr);
context.ExecuteQuery();

var newRoleDefinitionBinding = new

Microsoft.SharePoint.Client.RoleDefinitionBindingCollection(context);
newRoleDefinitionBinding.Add(contributeRole);
web.RoleAssignments.Add(newUsr, newRoleDefinitionBinding);
context.ExecuteQuery();

Page 14 of 18
Whitepaper SharePoint Permissions

Users with Privileged Access

Certain users in SharePoint have access to administrative task and can access all the
content on the site collection or even entire farm. These users are called farm
administrators and site collection administrators.

Farm Administrators
Members of the farm administrator groups perform administrative tasks in the
SharePoint central administration. They have the permissions to change web
application policies and site collection administrators. Therefore, they can grant
permissions to themselves to access any site, list, or document on your farm. You can
add individual users or AD groups to the farm administrators group.

Site Collection Administrators

Site collection administrators have full control of the entire site collection and can
perform any action on any object inside it. A site collection administrator might be any
of the following:

o A primary administrator assigned through central administration, who can only

be a user.
o A secondary administrator assigned through central administration, who can only
be a user.
o A site collection administrators group assigned from the site settings of the root
web, which can contain both users and AD groups.

To manage site collection administrators, you need to change the following properties:

SPSite.Owner
- primary administrator of the site collection
SPSite.SecondaryContact
- secondary administrator of the site collection
SPWeb.SiteAdministrators
- site collection administrators group

Page 15 of 18
Whitepaper SharePoint Permissions

Item-Level Permissions

A common requirement for a list is that a user should be able to read and edit items
for which he or she is the author. This can be accomplished by using the Item-Level
Permissions found under the Advanced Settings for a list.

You can specify the following read access:

Read all items

Read items that were created by the user

You can also limit the items a user is allowed to create or edit:

Create and edit all items

Create items and edit items that were created by the user
None

Page 16 of 18
Whitepaper SharePoint Permissions

Conclusion
The out of the box tools that SharePoint provides can help you secure your content
but are also limiting when it comes down to tracking certain permissions for a user or
managing permissions over time. Preparing an overview of the necessary permissions
is time-consuming. You need to be able to ask and answer questions such as the
following:

Who can access the document Executive Salaries? (Your answer to this question
should be a report of all users who can access the document, including group
members of the groups that have access.)
How can a user access this document? (Your answer will depend on whether
permissions have been directly assigned to the user or whether the user must be
a member of a SharePoint group or AD group to receive those permissions.)
Where does user X have permissions? (Your answer will be a list of all the
documents a user can access through both unique and inherited permissions on
a site collection level, or even a farm level.)

To answer these questions, you would either have to take a lot of time to track down
the answers through the SharePoint UI or develop a custom solution. Lets take a look
at some common situations when it comes to permissions management:

User X was fired and must have all permissions removed.

User X was transferred; the replacement is user Y.
New user Z was hired and must be assigned the same permissions as user X.

To accomplish these tasks on a site collection with a number of uniquely secured

scopes would be time-consuming and error prone. An option to copy or transfer
permissions does not exist in SharePoint out of the box.

To make permission administration easier, follow these best practices:

Avoid breaking permission inheritance whenever possible.

Avoid assigning permission directly to users rather than to SharePoint and AD
groups.
Assign permissions at the highest possible levels:
o Group documents that require unique permissions in separate document
libraries, sites, or even site collections.
o Use item-level permission rather than uniquely securing content at the
item level.
Avoid group nesting.
Or, use SPDocKit: the SharePoint admin tool which does all of the above for you!

Page 17 of 18
Whitepaper SharePoint Permissions

SPDocKit Ultimate SharePoint Admin Tool

What is SPDocKit?

SPDocKit is a unique tool that allows you to easily administer and

manage your SharePoint farm. You can use it to explore and
manage SharePoint permissions, keep an eye on your farm health
and compare and track changes on your farm in no time.

Why SPDocKit?

Create professional configuration documentation

Explore and manage SharePoint permissions
Optimize your farm according to best practices
Enforce governance policies
Monitor farm health and detect warnings on time

Try it!

Take SPDocKit for a spin: download it now. A 30-day free trial and
more info is available at www.spdockit.com.

If you have any questions, please contact us at:

sales@acceleratio.net.

And what do others think?

I love this It is more than A SharePoint

tool! awesome! Consultants
Jim Ehrenberg, Agnes Molnar, Swiss Knife!
SharePoint Pros, SharePoint MVP Adis Jugo,
Inc. SharePoint MVP

Page 18 of 18