SharePoint 2013 Permissions

What’s changed for managing access to sites

Sharon Richardsonwww.sharepointsharon.com / @sharepointguide

ReadMe.First

This presentation is based on the release of SharePoint Online included with Office 365 as of September 2013. It is entirely possible that features may change after publishing this presentation and render some or all of its contents redundant…

Usual disclaimers apply:

All content is for information purposes only with no warranties or guarantees regarding accuracy. Use at your own risk.

Product names, logos, brands and other trademarks referred to within this presentation are the property of their respective trademark holders (that would be Microsoft).

Copyright © 2013 Joining Dots Ltd. All rights reserved. That said, we don’t mind the slides being re-used for non-commercial purposes

ReadMe.Too

This presentation is a brief summary about how to approach controlling access to SharePoint sites designed for Slideshare. It is not a technical presentation but does assume a basic understanding and familiarity with information security and SharePoint

There is a corresponding blog post on the web site:http://www.sharepointsharon.com/2013/10/sharepoint-2013-permissions

And finally, we’ve discussed this topic before:

Managing SharePoint 2007 site permissionsposted to SlideShare in January 2010

http://www.slideshare.net/JoiningDots/sharepoint-2007-site-permissions

The Basics

The following content applies to most versions of SharePoint

Assigning permissions

Permissions can be set per site, per app (list/library) and per content (folder, file or list item) within a list or library

Permissions can be inherited from the parent. This is the default option when creating new sites, lists/libraries, folders and items within lists or libraries

As a rule of thumb, permissions should start as open as possible and become more restrictive as you go deeper into the hierarchy within a site collection.

Choices to manage permissions

Per User

Per SharePoint

Group

Per Directory

Group

Method

Pros

Cons

Bestuse:

• Add users individually to the resource

• Set permissions per user

• Add users to a SharePoint group

• Set permissions per SharePoint group

• Add users to a Directory group (AD DS)

• Set permissions per Directory group

• Lowest overhead across site collections

• Requires centralised management

• Delegated admin and can view membership

• Struggling to think of any these days…

• May have to duplicate across site collections

• Largest overhead to maintain

• Quick demos and very small deployments

• Want to delegate control to site owners

• Granular confiurations and large deployments

Microsoft recommendations – Part 1 The old way

Add users to Active Directory groups. Add Active Directory groups to SharePoint groups. Assign access permissions to SharePoint groups

ADgroup

Site Collection 1

Site Collection 2

SPgroup Site

SPgroup Site

Added to

Added to

Added to

Permissionsgranted

Permissionsgranted

The standard Microsoft approach for all solutions: add users to a security group, add the security group to a resource group, assign permission for a resource to the resource group

Microsoft recommendations – Part 2 Since June 2010

Add users to Active Directory Domain Services groups (AD DS). Assign permissions to AD DS groups. Do not use SharePoint groups

AD DSgroup

Site Collection 1

Site Collection 2

Site

Site

Added to

Permissionsgranted

Permissionsgranted

New approach recommended because changes to membership of SharePoint groups triggers indexing and can affect performance

Realistic approach – Part 1

Use AD DS Groups where possible Best performance / can nest and re-use for other services When a user needs to be added to a group, you only need

to add them once to the appropriate Directory groups

Best uses: Groups that will contain the same users and will be re-used

across multiple site collections – saves time/effort When a large number of groups will need to be managed

with frequent changes to memberships When information security requirements demand a strict

change management procedure for controlling access permissions

Realistic approach – Part 2 Use SharePoint Groups for ease of use in some scenarios

Site owners can manage the site permissions by adding people to groups within just their site

Membership can be displayed on site pages using the ‘Site Users’ web part

Best uses: Team site collections, where site management is most likely to

be delegated to site owners within the department/team Specialist sites, where group membership is likely to be unique

and there is a need for non-IT roles to view/manage membership Small deployments where SharePoint day-to-day administration

is delegated as much as possible due to limited IT resources

What’s changed in SharePoint 2013?

The following content applies to SharePoint 2013/SharePoint Online

‘Sharing’ instead of ‘Securing’

New terminology is used for changing permissions and controlling who can access sites and content. Throughout the user interface (UI), the word ‘Share’ is used.

In some places, it can look a little confusing…

Clicking this link will allow people to ‘share’ the site with others

Sharing is everywhere

It’s easier than ever to share folders and documents, just like those pesky file sync/share tools like DropBox*

* We love DropBox really

Sharing can get messy

With folders and documents, clicking ‘Share’ behaves differently to sharing sites. Users cannot be added to groups. Instead, they are given item-level permissions

This prevents them being given access to more than they should but could impact performance for large lists and libraries

Lists behave differently to libraries – you can’t share items direct at all. Instead you have a ‘Shared with’ link that takes you the permissions page for the item

Beware sharing more than you want

When you click the ‘Share’ button to share a site, you may assume you are just sharing that specific site…

You would be assuming wrong!

When you click Share for a site, the default is to add the users to the first group in the site with permission to Edit content… If the site is inheriting permissions from a parent site, that group may have permission to edit a lot more than you realise…

Beware who you share withIf sharing with external users has been enabled for the site collection, then anybody with Full Control permission for a site can share it with external users, i.e. anybody outside the organisation

In this image, I’m inviting the one and only Bill Gates to check out my site

Note: only users with Full Control can do this, and only in site collections where external sharing has been enabled. It is off by default. But the external user can be granted equivalent access – right up to Full Control of the site!

Sharing isn’t always sharing

A standard dialogue box is used when adding users to any SharePoint group, regardless of activity

e.g. if you decide to click the ‘Share’ button and add a user to a site, you need to select what group to add them too. You are sharing access

But if you have gone into Site Settings to set up a new group you might not have assigned any permissions yet. You are not sharing access, just sorting out group membership

Sharing challenges recommendations

When changing permissions by sharing content with people, you can only add them to SharePoint groups available to the current site. Domain groups will not be listed

i.e. Sharing will not follow Microsoft’s recommendation for using Domain groups rather than SharePoint groups for permissions

For practical reasons, most deployments will benefit from a mixed approach. Use domain groups when possible, use SharePoint groups when necessary or when practicality trumps performance

What hasn’t changed that should

To see the full list of groups, click the More… link in the navigation bar on the left of the page (circled in red)

It’s a minor annoyance that you’ll spot as soon as you click the New button from this page to create a new group

Within Site Settings, when you click on People & Groups, the next screen doesn’t show you a list of people and groups, it shows you the membership of the first group in the list

Governance and Administration Matters

Will try and highlight which bits are only applicable to certain versions

Guidelines for managing access

Only enable external access on those site collections you intend to share content with people outside your organisation

Only grant Full Control site permissions to non-IT roles who have been given training in how to manage their sites. And budget for refresher training and periodic audits to review

Keep permissions as simple as possible. You do not need groups to identify business roles, only to manage different permissions. Share at the highest level possible by default. Avoid creating custom roles or granular (‘fine grained’) permissions other than for exceptions

Optimise the design

If only certain functions need to share content with users outside the organisation, use site collections to separate and control what content can be accessed by external users

Scenarios that require granular permissions management should be given dedicated site collections. They may even warrant dedicated web applications (for those in control of their servers)

Scenarios that require granular permissions management should use Active Directory Domain Services groups if possible for performance gains

Collaborative team sites that are most likely to share documents individually should be kept small in size, particularly the libraries

Pre-configure/Automate what you can Have a central resource mailbox for access requests.

Configure all attempts to access sites to prompt users to request access, and forward the request to the central mailbox for review by IT

For sites that are intended to be ‘shared’ internally or externally with control delegated to site owners, set-up default SharePoint groups to make permissions granted as clear as possible

For sites that are intended to be shared, break inheritance for all top-level sites to avoid accidentally sharing more than intended. i.e. each top-level site should have its own unique set of permissions

…and document the manual steps Provide clear guidelines on how access to sites is being

managed and when more granular permissions are acceptable or not (e.g. unique permissions per sub-site, library or item)

Use a consistent naming method for SharePoint groups so that people become familiar with differences in access permissions

Beware the default new ‘Edit’ permission. When sharing sites and content, site owners should always click ‘Show options’ and ensure the correct group is selected

Example: Team Site Collection

SharePoint Group Permission Purpose

<Site> Owners Full Control Delegated site management

<Site> Team Edit Team participation in the site

<Site> Contributors Contribute Use for shared contributions

<Site> Visitors Read Use for shared viewing

Teams

Finance Legal IT

XX X X

= site

= broken inheritance

Directory group ‘Everyone excluding external users’ added to Visitors group by default

Site Owners trained to use only Contributors or Visitors group when sharing the site outside the team

Reference: What do the different permissions allow people to do?

This bit is specific to SharePoint 2013 but the basics apply to all

Default Groups Part 1

The following are the default groups created automatically for team sites in SharePoint 2013

Group name

Permission Level

Comments

Owners Full Control Use (sparingly) when delegating management of sites

Members Edit Use for participants who will be adding and updating content

Visitors Read Use for people who will be reading but must not change content

Viewers View Only Use to allow people to view but not download content

Default Groups Part 2

The following are additional groups created for other site templates, specifically the Enterprise Publishing templatesGroup name

Permission Level Comments

Restricted Readers

Restricted Read + Limited Access

Can’t see version history or permissions

Style Resource Readers

Read to Master Page gallery and Restricted Read to Style library

Don’t remove from root site in site collection

Approvers Approve + Limited Access Can approve content before it is published

Designers Design + Limited Access Can change visual layout

Hierarchy Managers

Manage Hierarchy + Limited Access

Can change the structure

Default Permissions Part 1

Permission

Access granted Notes/Comments

View Only Can view pages and lists/libraries (browser-only). Cannot download (or view in client applications)

Default for ‘Viewers’ group in 2013.

Limited Access

Enables access to specific content without having full access to site. Built-in, cannot be edited. This is used when sharing individual documents

Do not remove!

Read Can view pages, lists/libraries and items, can download and view in client applications

Default for ‘Visitors’ group. No change from previous versions

Restricted Read

Same as Read but cannot see permissions or version history

No change from previous versions.

Default Permissions Part 2

Permission

Access granted Notes/Comments

Contribute Can add or change items on pages and in lists/libraries

Used to be the default for ‘Members’ pre-2013. Can no longer delete items

Edit Can add, edit and delete lists and libraries. Can add, edit and delete items within lists/libraries

New permission for 2013 and now the default for ‘Members’

Design Can view, add, modify, customise, approve and delete the layout of site pages using the browser or SharePoint Designer 2013

Altered in 2013 as some perms have been moved to ‘Edit’.

Full Control

Full permissions including site creation and deletion and full access to all site settings

No change to previous versions

Default Permissions Part 3

Comments:

The new ‘Edit’ permission makes sense because many organisations have wanted a permission that does not include ‘delete’. That is now the role of the ‘Contribute’ permission

However, when the ability to delete is required, ‘Edit’ now grants more permissions than the old ‘Contribute’ such as adding and deleting lists/libraries too (previously required ‘Design’)

That said, the Recycle Bin remains your friend and accidental deletions can be easily recovered. (Up to 90 days on Office 365, period to be defined for on-premise installations, default is 30)

References & Further Reading Overview of site permissions in SharePoint 2013

http://technet.microsoft.com/en-us/library/jj219771.aspx

Define permission levels and groups in SharePoint 2013http://technet.microsoft.com/en-us/library/cc262690.aspx

Permission levels and permissions in SharePoint 2010 (Windows SharePoint Services 3.0)http://office.microsoft.com/en-gb/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx

Clarifying guideance on SharePoint Security Groups versus Active Directory Domain Services Groupshttp://blogs.msdn.com/b/kaevans/archive/2013/05/06/clarifying-guidance-on-sharepoint-security-groups-versus-active-directory-domain-services-groups.aspx

Software boundaries and limits for SharePoint 2013http://technet.microsoft.com/en-us/library/cc262787.aspx#ListLibrary

SharePoint 2013 Permissions

For feedback, comments and questions, please post to the corresponding blog post:

http://www.sharepointsharon.com/2013/10/sharepoint-2013-permissions

Sharon Richardsonwww.sharepointsharon.com / @sharepointguide

The End