The Ultimate Guide to

SharePoint Permissions
Best Practices

1
 Table of Contents

Introduction 3

Chapter I Understanding SharePoint Permissions

SharePoint Administration Roles 4

Default SharePoint Permission Levels 6

SharePoint Groups 7

Advanced Permissions 8

Chapter II Managing SharePoint Permissions

Entities that Can Be Granted Permissions 11

Objects that Permissions Can Be Granted for 12

How to Manage SharePoint Permission Groups 13

How to Assign and Edit SharePoint Permissions 14

How to Customize Permissions Levels 14

Permissions Inheritance 16

Chapter III SharePoint Permissions Best Practices

Use groups to manage user permissions 17

Minimize the use of item-level permissions 17

Build a structure that ensures permissions inheritance 18

Conduct regular permissions attestations 19

Use separate site collections for external sharing 19

Disable anonymous sharing 19

Final Word 20

About Netwrix 22

2
 Introduction

SharePoint has a very flexible model for permissions assignment. You can regulate
access rights at various levels that are inherited by lower levels of the hierarchy, and
you can also create exceptions that break the inheritance of permissions. Moreover,
you can assign permissions to groups or directly to users.

This flexibility can be very useful, but it has an important downside: It often results in
a tangled permissions structure that is difficult to understand and manage, especially
when several people are responsible for SharePoint environment. Nevertheless, it’s
critical to set SharePoint permissions correctly and manage them effectively; in fact,
this process can make or break the security of your SharePoint and the information
stored in it.

This guide will help you understand the layers of SharePoint permissions, administra-
tive roles and permissions management best practices, so you can build a transparent
and secure SharePoint environment in your organization.

Introduction 3
 I. Understanding SharePoint
Permissions

SharePoint permissions control the access that employees, partners, third-party

suppliers and others have to your SharePoint content. You can choose who can read
specific information and who cannot. SharePoint permissions extend not only to dis-
play data in lists and document libraries, but also to search results and even the user
interface. For instance, if you do not have permissions to a specific document list, then
you will not see any documents from that list in your search results. This functionality
helps protect sensitive data from people who should not see or distribute it.

SharePoint Administration Roles

The following figure lists the main SharePoint admin roles and which system compo-
nents they can manage:

Figure 1.1
SharePoint admin roles and
system components, which they
can manage

Chapter I | Understanding SharePoint Permissions 4


Server and Farm Roles
Shared Services Roles
Web Application
Policies
Chapter I | Understanding SharePoint Permissions
Let’s dig deeper into the admin roles for the various components of the SharePoint
infrastructure.
Windows Administrator. When SharePoint is installed on a Windows Server, the
local Administrators group on that server is automatically added to the SharePoint
Farm Administrators group. As a result, these local administrators (Windows
Administrators) have full control permissions on the SharePoint farm — they can
install applications and software and manage Internet Information Services (IIS)
websites and Windows services. However, by default, they have no access to site
content.
Farm Administrator. Members of the Farm Administrators group have full control
permissions to all SharePoint farms; that is, they can perform all administrative
tasks in SharePoint Central Administration for the server farm. For example, they
can assign administrators to manage service applications, features and site collec-
tions. This group does not have access to individual sites, site collections and their
content, but a Farm Administrator can easily take ownership of any site collection
and get full access to its content simply by adding himself or herself to the site
collection’s Administrators group on the Application Management page.
Service application administrator. These administrators are selected by the Farm
Administrator. They can configure settings for a specific service application in a
farm. However, they cannot create service applications, access any other service
applications in the farm, or perform any farm-level operations, such as topology
changes. For example, the service application administrator for a search applica-
tion in a farm can configure settings for that application only.
Feature administrator. A feature administrator is associated with one or more spe-
cific features of a service application. These administrators can manage a subset
of service application settings, but not the entire service application. For example,
a feature administrator might manage the Audiences feature of the User Profile
service application.
The web application level does not have a unique administrator group, but farm
administrators have control over the web applications within their scope. Members of
the Farm Administrators group and members of the Administrators group on the local
server can define a policy to grant permission to individual users at the web application
level. The following polices are available:
Anonymous policies. Defines the access restriction to be applied to users who are
not authorized in the domain: no policy, deny write access or deny all access.
Permission policies. Defines a set of permissions that can be granted to users or
SharePoint groups for a site, library, list, folder, item, document or other entity.
You can use the default permissions policies or create custom ones.
5

Site Collection Roles
Default SharePoint Permission Levels
By default, SharePoint defines the following permission levels:
Chapter I | Understanding SharePoint Permissions
User policies. A high-level set of permissions that is applied to a web application
and inherited by all site collections. Using a user policy, you can grant any user or
AD group unique permissions to a particular web application and all site collections
within it.
User permissions. Defines which advanced permissions site collection administra-
tors can use to create unique permissions for a certain web application. (I don’t
know why Microsoft didn’t call this a “policy,” too, since it works like a policy.)
Site collection administrator. These administrators have the Full Control permission
for all sites in a site collection. They have Full Control access to all site content in
that site collection, even if they do not have explicit permissions on that site. They
can audit all site content and receive any administrative message. A primary and
a secondary site collection administrator can be specified during the creation of
a site collection.
Site owner. By default, members of the Owners group for a site have the Full Con-
trol permission level on that site. They can perform administrative tasks on the site,
and on any list or library within the site. They receive e-mail notifications for events
such as the pending automatic deletion of inactive sites and requests for site
access.
Full Access. The user can manage site settings, create sub-sites, and add users to
groups.
Design. The user can view, add, update and delete approvals and customizations,
as well as create and edit new document libraries and lists on the site, but cannot
manage settings for the whole site.
Contribute. The user can view, add, update and remove list items and documents.
Contribute is the most common right for regular SharePoint users, since it enables
them to manage documents and information on a site.
Read. The user can view list items, pages and download documents.
Edit. The user can manage lists and list items and contribute permissions.
View Only. The user can view pages, list items and documents. Documents can be
viewed only in the browser; they cannot be downloaded from a SharePoint server
to a local computer.
6
 Limited Access. The user can access shared resources and specific assets. Limited
Access is designed to be combined with fine-grained permissions (not inherited,
unique permissions) to enable users to access a specific list, document library,
folder, list item or document without giving them access to the whole site.
The Limited Access permission cannot be edited or deleted.

SharePoint Groups
SharePoint groups enable you to manage sets of users instead of individual users.
A group can include individual users created in SharePoint, as well as users or groups
from any identity management or domain services system, such as Active Directory
Domain Services (AD DS), LDAPv3-based directories, application-specific databases and
identity models such as Windows Live ID. You can organize your users into any number
of groups, depending on the size and complexity of your organization or site.
SharePoint groups cannot be nested.

User-defined SharePoint groups do not have specific access rights to the site. However,
there are predefined SharePoint groups that do grant members specific access permis-
sions. The set of predefined groups depends on the site template you are using. Here
are the predefined groups for a team site and their default permissions to the
SharePoint site:

Visitors Read

Members Edit

Owners Full Control

Viewers View Only

And here are the predefined groups for the publishing site template and their default
permissions:

Can view pages and documents, but cannot view

Restricted
historical versions or information about permis-
Readers
sions.

Chapter I | Understanding SharePoint Permissions 7

 Have Read permission to the Master Page Gal-
Style Resource lery and Restricted Read permission to the Style Li-
Readers brary. By default, all authenticated users are mem-
bers of this group.

Can view, add, update, delete, approve and cus-

Designers tomize the layout of site pages using a browser or
SharePoint Designer.

Can edit and approve pages, list items, and docu-

Approvers
ments.

Hierarchy
Can create sites, lists, list items, and documents.
Managers

Note that all these groups and their permissions can be changed.

The best practice is to add regular users who only need to read information to the
Visitors group and add users who need to create or edit documents to the Members
group. This is because users in the Members group can add, change or remove items
or documents, but they cannot change the site structure, settings or appearance.
Similarly, users in the Visitors group can see pages, documents and items but cannot
perform add or remove operations.

Advanced Permissions
The default groups and permission levels in SharePoint provide a general framework
for permissions that is useful for many types of organization. However, they might not
map exactly to how users are organized or the many different tasks they perform on
your sites. If the default permission levels do not suit your organization, you can create
custom groups, change the permissions included in specific permission levels or create
custom permission levels.

Chapter I | Understanding SharePoint Permissions 8


SharePoint Site
Permissions
These permissions affect site
and personal settings, the
web interface, access and
site configuration.
Chapter I | Understanding SharePoint Permissions
Create and change permission levels on a subsite and assign
Manage Permissions
permissions to users and groups
View Web Analytics Data View site usage reports
Perform all administration and content management actions
Create Subsites
for the site
Manage Web Site Add, change and delete HTML pages
Add and Customize Create subsites such as team sites, publishing sites and news-
Pages feed sites
Apply Themes
Apply a theme or borders to the site
and Borders
Apply Style Sheets Apply a style sheet (.CSS file) to the site
Create a group of users that can be used anywhere within the
Create Groups
site collection
Browse Directories Enumerate files and folders in a site using SharePoint
Use Self-Service Site
Create a site using self-service site creation
Creation
View Pages View pages in a site
Enumerate Permissions Enumerate permissions on a site, list, folder, document or list
item
Browse User Information View information about site users
Manage Alerts Manage alerts for all site users
Use the SOAP, Web DAV, Client Object Model or SharePoint De-
Use Remote Interfaces
signer interfaces to access the site
Use features that launch client applications in the site (users
Use Client Integration
without this permission have to download documents locally,
Features
work with them and then upload the revised documents)
Open Open a site, list or folder and access items inside that container
Edit Personal User Change one’s own user information, such as by updating a tele-
Information phone number or title or adding a picture
9

SharePoint List
Permissions
These permissions affect
the management of lists,
folders and documents
and the viewing of items
and application pages.
SharePoint Personal
Permissions
These permissions affect
the configuration and
management of personal
pages.
Chapter I | Understanding SharePoint Permissions
Manage Lists Create and delete lists, list columns and public views of a list
Discard or check in a document that is checked out by another
Override List Behaviors
user
Add Items Add items to lists and documents to document libraries
Edit items in lists and documents in document libraries, and
Edit Items
customize web part pages in document libraries
Delete items from lists and documents from document
Delete Items
libraries
View Items View items in lists and documents in document libraries
Approve Items Approve or reject a new version of a list, item or document
Open documents using server-side file handlers (the docu-
Open Items
ments will not be downloaded to the local computer)
View Versions View past versions of a list item or a document
Delete Versions Delete past versions of a list item or a document
Create alerts to track changes to lists, libraries, folders, files
Create Alerts
or list items
View Application Pages View forms, views, and application pages
Manage Personal Views Create, change and delete personal list views
Add/Remove Add or remove personal web parts
Personal Web Parts
Update Personal Add or edit personalized information in personal web parts
Web Parts
10
 II. Managing SharePoint
Permissions

Access control relies on authentication (verifying that the user is who they claim to
be) and authorization (determining what the user should have access to). SharePoint
performs authorization but it does not perform any authentication; it relies on the
underlying Internet Information Services (IIS) and authentication providers to handle
that.

Since SharePoint 2010, the standard authentication has been claims-based authentica-
tion. There are different types of claims-based authentication; the industry standards
are WS-Federation, Security Assertion Markup Language (SAML) and OAuth. However,
Microsoft baked into SharePoint a claims engine, the Security Token Service (STS),
which can understand many different authentication approaches. Out of the box,
SharePoint supports standard Windows Authentication (NTLM, Basic and Kerberos),
Forms Based Authentication (FBA) and SAML.

Entities that Can Be Granted Permissions

Authorization in SharePoint is controlled by permissions assigned to the following en-
tities:

Active Directory groups

Roles provided by Forms Based Authentication

SAML attributes

SharePoint groups

A specific user (though best practices recommend not assigning permissions at this
level in SharePoint)

Chapter II | Managing SharePoint Permissions 11

 Objects that Permissions Can Be Granted for
Permissions can be set on a variety of SharePoint items:

SharePoint farm Administrative permissions

Web application Anonymous policy, user policy, user permissions

Shared Services Service app and feature administrative permissions

Site collection Site collection administrative permissions,

permissions

Subsite Permissions

Document library
Sharing Permissions
or list

Folder in the docu-

Sharing permissions
ment library or list

Separate file Sharing permissions

For all of these objects, you can assign permissions to the entities listed in the previ-
ous section, such as SharePoint security groups, roles, attributes or specific users. (As
noted earlier, however, the best practice is to use security groups or roles for assigning
user permissions instead of adding permissions directly to a user account.)

The permission assignments for an object determine whether access to it is granted

or blocked. A typical SharePoint user would not, for example, have access at the farm,
service application or even web application level; instead, they would be granted
permissions to data at the site collection level or lower using the corresponding
SharePoint permission groups.

Chapter II | Managing SharePoint Permissions 12

 How to Manage SharePoint Permission
Groups
Microsoft SharePoint groups enable you to manage sets of users instead of individual
users. A group can include individual SharePoint users, as well as users or groups from
any identity management or domain services system, such as Active Directory Domain
Services (AD DS), LDAPv3-based directories, application-specific databases and identity
models such as Windows Live ID.

You can organize your users into any number of groups, depending on the size and
complexity of your organization or site. However, SharePoint groups cannot contain
other SharePoint groups (that is, they cannot be nested).

There are two ways of assigning permissions to a SharePoint site via groups: The first
one is to add a user to a SharePoint group, and the second one is to give an AD securi-
ty group access directly to the site or put it in a SharePoint group that has permissions
on the site.

To create a SharePoint group, go to Site Permissions in Site Settings and click the
Creating a SharePoint “Create Group” button. Enter a name and description for the group. Then specify the
group group owner; the users who can view and edit the group’s membership; whether to
allow users to request membership or request to leave the group; and the group’s per-
missions for the site. Then click “Create” to create the group.

Figure 2.1
Creating a SharePoint group

Chapter II | Managing SharePoint Permissions 13

 To delete a group, use the “People and Groups” menu in Site Settings. Choose the
Deleting a SharePoint group, click the “Edit” button and then click the “Delete” button.
group

To add members to a SharePoint group, from the “People and Groups” menu, click
Changing group the name of the group in the left pane and then click “New” and “Add Users”, as shown
membership below. Enter one or more usernames you want to add to the group, and then click
“Share”.

Figure 2.2
Changing group membership

To remove a user from a group, select the user you want to delete, click “Actions”, and
then click “Remove Users from Group”.

How to Assign and Edit SharePoint

Permissions
The ability to manage permissions to SharePoint resources is primarily limited to
members of the Site Collection Administrators (who can manage the root site and all
its subsites) and Site Owners groups (who can manage specific subsites). However,
any end user can edit permissions to the content and locations that they own.

To modify the permissions for a site collection or site, the Site Collection Administra-
tors or Site Owners should choose "Site Settings" and edit the SharePoint permissions;
lower level permissions, such as permissions to document libraries or lists, are accessi-
ble within the settings pages for those specific securable objects.

How to Customize Permissions Levels

SharePoint does not include every permission level an organization might require, so
it enables you to customize the permissions levels and create new ones, either from
scratch or by cloning an existing permission level and making permissions changes.

Chapter II | Managing SharePoint Permissions 14

 Having tailored granular permissions sets enables you to better control what end
users can do in a way without all the complications and risks of assigning permissions
directly to individual users.

Navigate to the “Site Settings” page, click “Site Permissions” and then click the “Permission
Customizing Levels” menu. To customize an existing permission level, click its name on the “Permis-
an Existing sion Levels” page. On the “Edit Permission Level” page, change the description and add
or remove permissions as you require.
Permission Level

To create a new custom permission level, you must be logged in as a SharePoint Farm
Creating a New Administrator, Site Collection Administrator or Site Owner. Navigate to the “Site Set-
Custom Permission tings” page and click “Site Permissions”. Next, click on the “Permission Levels” menu item:
Level from Scratch

Figure 2.3
Creating a new custom
permission level

On the “Add a Permission Level” page, enter the name of the new permission level and a
description. Then select the check boxes next to the list, site and personal permissions
that you want the new permission level to include. To save your new permission level,
click “Create”.

To clone an existing permission level, go to the “Permission Levels” page and then click
Creating a New on the permission level you want to clone.
Custom Permission
Level by Cloning
Figure 2.4
Cloning an existing permission
level

Then click the “Copy permission level” button, name the new permission level, modify it
as needed, and then save it.

Chapter II | Managing SharePoint Permissions 15

 Permissions Inheritance
By default, subsites, libraries and lists inherit permissions from the site in which they
were created (the parent site). In addition, there are the policies defined at the web ap-
plication level that I described earlier. All site collections inherit permissions from the
web application’s user policy and anonymous policy, which grants or denies access to
user accounts. Web applications also inherit user permissions, which define which per-
mission levels can be used for creating unique permissions for site collections. The
web application level also has a permission policy, which defines the high-level permis-
sion types for user policy.

If you break permissions inheritance, the subsite, document library, website or file will
be able to form its own unique permissions, but, as stated earlier, only the permission
levels regulated by the web application’s user permissions will be available.

Therefore, we have two types of inheritance, which are tied to policies configured on
the web application level:

User policy, which is inherited by all lower level site collections.

User permissions, which are inherited by all site collections advanced permissions.
This inheritance cannot be broken at lower levels.

Any permissions changes at the parent level site (list of items, document library) will
not affect child elements with unique permissions, and unique permissions will always
win when they conflict with parent ones.

As you can imagine, this model of inheriting permissions from higher level elements
How to Break does not meet all security requirements. For example, multiple users might need ac-
Permissions cess to a certain document library, but only a few of them should be able to read one
of the documents in that library. Similarly, you also might need:
Inheritance
Subsite permissions that differ from those for the parent site collection

List or library permissions that vary from those of the parent site

Folder permissions that differ from those of the parent library

File permissions that are different from the parent library or folder

Currently, the only way of achieving these goals is to break inheritance for the specific
item. You edit user permissions as required, removing any that are not necessary.
This strategy is effective, but assigning unique permissions to specific user accounts
creates management headaches and can introduce security gaps. Therefore, you
should avoid breaking inheritance whenever possible.

To break inheritance for a given object, select that object, click "Stop inheriting permis-
sions" and then remove or add users or groups as needed.

Chapter II | Managing SharePoint Permissions 16

 III. SharePoint Permissions
Best Practices

Because there are so many layers of SharePoint permissions and ways to assign them,
it can be challenging to ensure transparent and manageable permissions structure.
Understanding and following best practices when it comes to SharePoint permissions
can help you with that.

Use groups to manage user permissions

The security boundary object defined in SharePoint is always the SharePoint group.
Permission levels in SharePoint are assigned to SharePoint groups; by default, site
permissions consist of specific SharePoint groups with their default permission levels,
making a group the perfect container.

Therefore, you should set permissions on either a SharePoint site group or an Active
Directory group. In environments where Active Directory is not the core authentication
mechanism, the group could be a Forms Authentication Role or even an attribute from
a Security Assertion Markup Language (SAML) claim.

Using groups for permission assignment helps ensure permissions are in line
with the least-privilege principle. It comes down to the inheritance of permissions for
users based on their group memberships. As users change roles or leave the organiza-
tion, removing them from security groups instantly removes their access to sites, their
subsites, and all files and folders in the hierarchy. In contrast, when access rights are
assigned at the user level, permissions are rarely revoked in those situations, putting
your content at unnecessary risk.

Minimize the use of item-level permissions

Though assigning unique item-level permissions in SharePoint can address a need

quickly, it will make your life harder in the long run. Item-level access should be
a fallback — used only if all other options are too complicated for management and
implementation.

We find broken inheritance and unique permissions again and again on files in file
shares, which leads to NTFS or share permissions being allocated and then never
removed. However, unlike file servers, SharePoint does not provide an easy way to
identify unique permissions and remedy them easily, so they put the security of
SharePoint at risk.

Chapter III | SharePoint Permissions Best Practices 17

 Using higher-level containers like libraries or folders instead of files to assign permis-
sions helps you achieve limited user access and control. Components such as Informa-
tion Rights Management (IRM) can reduce the need for item-level permissions. Once
permissions are broken and individual users directly granted access, the SharePoint
attack surface increases, even if the users are able to only view items, let alone if they
were assigned Full Control permissions.

Another area where item-level permissions have a significant impact is SharePoint

search. One of the items retrieved as part of the search mechanism is the Access
Control List (ACL) for an object. If inheritance is broken and item-level permissions
have been added, then the search crawl engine has to iterate that before it can access
the content. The more item-level permissions there are, the longer it can take to crawl,
which can delay critical investigations.

Build a structure that ensures permissions inheritance

It is much easier to manage permissions when there is a clear hierarchy of permis-

sions that are inherited from the parent. It becomes more difficult when some lists in
a site have fine-grained (unique) permissions applied, and when some sites have sub-
sites with unique permissions and others with inherited permissions. So, it is a best
practice to, as much as possible, arrange sites and subsites, lists and libraries so they
can inherit most permissions from parent.

Here is a tangled SharePoint permission structure made simple for you:

Figure 3.1
SharePoint permission structure

Chapter III | SharePoint Permissions Best Practices 18

 Conduct regular permissions attestations

Regular privilege attestations help you spot excessive access rights in a timely manner,
as well as identify unauthorized broken inheritance, which could lead to security or op-
erational issues.

Use separate site collections for external sharing

SharePoint is all about collaboration and sharing of documents, files and other
content. Sometimes, users need to share content externally for legitimate business
reasons. That capability is now built into the product.

Protecting the sharing of content with external users is vitally important to the busi-
ness. Best practices are to block external sharing unless there is a business reason for
it and to isolate all external sharing sites into a single site collection so you can control
what can and cannot be shared externally. This approach reduces the risk of privilege
misuse and attacks on the information on your other sites.

Disable anonymous sharing

Having the ability to share content outside of the organization without requiring any
authentication is appealing to users, especially if the organization restricts email
attachments. SharePoint makes it easy: Users can send anyone a link that allows them
to download and even edit a particular file.

However, it is possible to disable anonymous sharing. This is recommended to miti-

gate the risk of internal users sharing content externally that shouldn't be shared. In
addition, in the event of a data security breach, you need to be able to see the whole
picture, and anonymously shared content is much harder to identify.

Chapter III | SharePoint Permissions Best Practices 19

 Final Word

SharePoint is an invaluable collaboration platform that many organizations use to

share content both internally and with partners, contractors and others. Creating
a clear and manageable permissions structure is essential to ensuring the security
of the content stored in your SharePoint environment.

The best practices detailed here provide a high-level view of how to get started.
For more detailed information, check out the following resources:

How-to | How to Get a SharePoint Permissions Report

How-to | How to Detect SharePoint Permission Changes

How-to | How to Determine Who Deleted a File on Your SharePoint

Free Guide | SharePoint Auditing Quick Reference Guide

Blog Post | Most Useful SharePoint PowerShell Commands

Blog Post | Best SharePoint Reporting Tools

Webinar | Top Critical Changes to Audit in SharePoint

Webinar | The 3 Pillars of SharePoint Security

Final Word 20
Netwrix Auditor for SharePoint

Get control over SharePoint permissions and make sure

that important data is not overexposed

See who has access to what within site collections

Understand how permissions were granted

Identify broken inheritance

Download Free 20-Day Trial

21
 About Netwrix

Netwrix Corporation is a software company focused exclusively on providing

IT security and operations teams with pervasive visibility into user behavior, system
configurations and data sensitivity across hybrid IT infrastructures to protect data
regardless of its location. Over 10,000 organizations worldwide rely on Netwrix to
detect and proactively mitigate data security threats, pass compliance audits with less
effort and expense, and increase the productivity of their IT teams. Founded in 2006,
Netwrix has earned more than 140 industry awards and been named to both the Inc.
5000 and Deloitte Technology Fast 500 lists of the fastest growing companies in the
U.S.

Netwrix Auditor is an agentless data security platform that empowers organizations

to accurately identify sensitive, regulated and mission-critical information and apply
access controls consistently, regardless of where the information is stored. It enables
them to minimize the risk of data breaches and ensure regulatory compliance by
proactively reducing the exposure of sensitive data and promptly detecting policy
violations and suspicious user behavior.

For more information about Netwrix, visit www.netwrix.com.

Contact Us Corporate Headquarters Phones netwrix.com/social

300 Spectrum Center USA: 1-949-407-5125

Drive Suite 200 Toll-free: 888-638-9749

Irvine, CA 92618 EMEA: +44 (0) 203 588 3023

22