sharepoint 2013 governance - managing permissions
DESCRIPTION
Governance guidelines for managing access to sites and content for SharePoint 2013 and SharePoint Online (part of Office 365) with reference to what's changed compared to earlier versions.TRANSCRIPT
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