• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SharePoint 2013 Governance - Managing Permissions
 

SharePoint 2013 Governance - Managing Permissions

on

  • 7,647 views

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.

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.

Statistics

Views

Total Views
7,647
Views on SlideShare
7,153
Embed Views
494

Actions

Likes
5
Downloads
149
Comments
0

6 Embeds 494

http://www.sharepointsharon.com 449
http://www.aetio.com 25
http://cloud.feedly.com 10
http://aetio-public.sharepoint.com 8
http://digg.com 1
http://wwww.sharepointsharon.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    SharePoint 2013 Governance - Managing Permissions SharePoint 2013 Governance - Managing Permissions Presentation Transcript

    • SharePoint 2013 Permissions What’s changed for managing access to sites Sharon Richardson www.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 permissions posted to SlideShare in January 2010 http://www.slideshare.net/JoiningDots/sharepoint-2007-site-
    • 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 Method Pros Cons Best use: • 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 AD group Site Collection 1 Site Collection 2 SP group Site SP group Site Added to Added to Added to Permissions granted Permissions granted 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 DS group Site Collection 1 Site Collection 2 Site Site Added to Permissions granted Permissions granted 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 with If 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 X X 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 templates Group 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 2013 http://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 Groups http://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 2013 http://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 Richardson www.sharepointsharon.com / @sharepointguide The End