Export (0) Print
Expand All
11 out of 17 rated this helpful - Rate this topic

Plan site permissions in SharePoint 2013

Published: July 16, 2012

Summary: Learn about how to plan site permissions for SharePoint 2013 to provide secure access to sites and content.

Applies to:  SharePoint Foundation 2013 | SharePoint Server 2013 

This article helps you plan access control at the site collection, site, subsite, and site content (list or library, folder, item or document) levels.

This article does not address planning the security of your entire server or server farm. For more information about planning other aspects of security, such as authentication methods and authentication modes, see Plan authentication in SharePoint 2013.

In this article:

Plan for site permissions

When you create permissions, you must balance the ease of administration and performance against the requirement to control access to individual items. If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site content.

Use the following guidelines to plan site permissions:

  1. Follow the principle of least-privileged: Users should have only the permission levels or individual permissions they must have to perform their assigned tasks.

  2. Use standard groups (such as Members, Visitors, and Owners) and control permissions at the site level.

    • Make most users members of the Members or Visitors groups. By default, users in the Members group can contribute to the site by adding or removing items or documents, but cannot change the structure, site settings, or appearance of the site. The Visitors group has read-only access to the site, which means that they can see pages and items, and open items and documents, but cannot add or remove pages, items, or documents.

    • Limit the number of people in the Owners group. Only those users that you trust to change the structure, settings, or appearance of the site should be in the Owners group.

  3. Use permission levels instead of assign individual permissions.

note Note:
  1. You can create additional SharePoint groups and permission levels if that you must have more control over the actions that the users can take. For example, if you do not want the Read permission level on a specific subsite to include the Create Alerts permission, break the inheritance and customize the Read permission level for that subsite.

  2. SharePoint Foundation 2013 and SharePoint Server 2013 use Check Permissions to determine a user or group’s permissions on all resources in a site collection. You can now find both the user's directly assigned permissions and the permissions assigned to any groups of which the user is a member by checking permissions for a specific site or site content.

Plan for permission inheritance

It is much easier to manage permissions when there is a clear hierarchy of permissions and inherited permissions. It becomes more difficult when some lists in a site have fine-grained permissions applied, and when some sites have subsites with unique permissions and others with inherited permissions. As much as possible, arrange sites and subsites, and lists and libraries so they can share most permissions. Separate sensitive data into their own lists, libraries, or subsites.

For example, it's much easier to manage a site that has permission inheritance as described in the following table.

Securable object Description Unique or inherited permissions

SiteA

Group home page

Unique

SiteA/SubsiteA

Sensitive group

Unique

SiteA/SubsiteA/ListA

Sensitive data

Unique

SiteA/SubsiteA/LibraryA

Sensitive documents

Unique

SiteA/SubsiteB

Group shared project information

Inherited

SiteA/SubsiteB/ListB

Non-sensitive data

Inherited

SiteA/SubsiteB/LibraryB

Non-sensitive documents

Inherited

However, it is not as easy to manage a site that has permission inheritance as shown in the following table.

Securable object Description Unique or inherited permissions

SiteA

Group home page

Unique

SiteA/SubsiteA

Sensitive group

Unique

SiteA/SubsiteA/ListA

Non-sensitive data

Unique, but same permissions as SiteA

SiteA/SubsiteA/LibraryA

Non-sensitive documents, but with one or two sensitive documents

Inherited, with unique permissions at the document level

SiteA/SubsiteB

Group shared project information

Inherited

SiteA/SubsiteB/ListB

Non-sensitive data, but with one or two sensitive items

Inherited, with unique permissions at the item level

SiteA/SubsiteB/LibraryB

Non-sensitive documents, but with a special folder that contain sensitive documents

Inherited, with unique permissions at the folder and document level

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.