SharePoint Permissions - SPDocKit

SharePoint Permissions Introduction to SharePoint Permissions

MATIJA HANŽIĆ

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

Whitepaper

of 18

Whitepaper SharePoint Permissions

About Matija

Matija Hanžić, 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.

of 18


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

of 18


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

of 18


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

of 18


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


context.Load(web, w => w.SiteGroups);


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

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


foreach (var user in spGroup.Users)

{

Console.WriteLine(user.Title + " - " + user.LoginName + " - " + user.PrincipalType);

}

of 18


Example 3 – Add a user to a SharePoint group using CSOM

//add new user to a SharePoint groups


context.Load(web, w => w.SiteGroups);


var newUsr = web.EnsureUser("[email protected]");

context.Load(newUsr);


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

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


spGroup.Users.AddUser(newUsr);


of 18


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.

of 18


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.

of 18


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.

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.

http://technet.microsoft.com/en-us/library/cc721640(v=office.15).aspx

of 18


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);



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 contributeRole = web.RoleDefinitions.GetByName("Contribute");

context.Load(contributeRole);


foreach (PermissionKind basePermission in Enum.GetValues(typeof(Microsoft.SharePoint.Client.PermissionKind)))

{

if (contributeRole.BasePermissions.Has(basePermission))

{

Console.WriteLine(basePermission);

}

}

of 18


Example 3 – Copy a permission level using CSOM

//create a copy of the Contribute permission level with no Delete List Items base permission


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



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.SharePoint.Client.PermissionKind)))

{

if (basePermission == PermissionKind.DeleteListItems)

{

continue;

}

if (contributeRole.BasePermissions.Has(basePermission))

{

contributeNoDelete.BasePermissions.Set(basePermission);

}

}

web.RoleDefinitions.Add(contributeNoDelete);


of 18


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

group’s 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.

of 18


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.

of 18


Sample Demo 3 - Permission Management

Example 1 – List all directly assigned permissions

//list all directly assigned permissions on a securable object


context.Load(web, w => w.RoleAssignments

.Include(assignment => assignment.Member,

assignment => assignment.RoleDefinitionBindings));


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


context.Load(web, w => w.RoleAssignments); context.ExecuteQuery();

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



var newUsr = web.EnsureUser("[email protected]");

context.Load(newUsr);


var newRoleDefinitionBinding = new Microsoft.SharePoint.Client.RoleDefinitionBindingCollection(context);

newRoleDefinitionBinding.Add(contributeRole);

web.RoleAssignments.Add(newUsr, newRoleDefinitionBinding);


of 18


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

of 18


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

of 18


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. Let’s 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!

of 18


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:

[email protected].

And what do others think?

“I love this

tool!”

Jim Ehrenberg,

SharePoint Pros,

Inc.

“It is more than

awesome!”

Agnes Molnar,

SharePoint MVP

“A SharePoint

Consultant’s

Swiss Knife!”

Adis Jugo,

SharePoint MVP

http://www.spdockit.com/

http://www.spdockit.com/features/generate-sharepoint-farm-documentation/

http://www.spdockit.com/features/manage-sharepoint-permissions/

http://www.spdockit.com/features/sharepoint-best-practices-reports/

http://www.spdockit.com/features/enforce-sharepoint-governance-policies/

http://www.spdockit.com/features/monitoring-sp-farm-health/

mailto:[email protected]

SharePoint Permissions - SPDocKit

Documents

Transcript of SharePoint Permissions - SPDocKit