SharePoint Permissions

Whitepaper SharePoint Permissions Introduction to SharePoint Permissions MATIJA HANŽIĆ ACCELERATIO LTD. | Savska cesta 182, 10000 Zagreb, Croatia ...
Author: Martina Wilson
16 downloads 2 Views 1MB Size
Whitepaper

SharePoint Permissions Introduction to SharePoint Permissions

MATIJA HANŽIĆ

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

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.

Page 1 of 18

Whitepaper

SharePoint Permissions

Content ABOUT MATIJA

1

CONTENT

2

SHAREPOINT PERMISSIONS

3

Introduction to permissions management

3

1. SharePoint Principals Sample Demo 1 - Users and Groups

4 5

2. Securable Objects

7

3. SharePoint Permissions Sample Demo 2 – Manage Permission Levels

8 10

Role Assignments Sample Demo 3 - Permission Management

12 14

Users with Privileged Access Farm Administrators Site Collection Administrators

15 15 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("[email protected]"); 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

SharePoint, permission.

a

given

the

user

task

in

requires

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 o o

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

List permissions examples: o o o o

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

Page 8 of 18

Whitepaper

SharePoint Permissions

Personal permissions examples: o o o

Manage personal views: Create, change, and delete personal views of lists. Add/remove personal Web Parts: Add or remove personal Web Parts on a Web Part page. 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 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.

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 o

On small collaboration sites, add users directly to SharePoint groups to enable full visibility. 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("[email protected]"); 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

o

be a user. 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. 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!

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: [email protected].

And what do others think?

“I love this

“It is more than

“A SharePoint

tool!”

awesome!”

Consultant’s

Jim Ehrenberg,

Agnes Molnar,

SharePoint Pros,

Swiss Knife!”

SharePoint MVP

Inc.

Adis Jugo, SharePoint MVP

Page 18 of 18