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 display 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 in the results of a search, you will not see any documents from that list. This permissions model helps protect sensitive data from people who should not see or distribute it.
The following figure shows which system components each of the main SharePoint admin roles can manage:
Here are the SharePoint server components and the corresponding administration roles:
Server and farm roles
- Windows Administrators — When SharePoint is installed on a Window 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) web sites and Windows services. But, by default, they have no access to site content.
- Farm Administrators — 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 collections. 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 administrators — 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 application in a farm can configure settings for that application only.
- Feature administrators — A feature administrator is associated with one or more specific 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.
Web application roles
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 individual users permissions at the web application level. The following polices are available:
- Anonymous policies — Defines the access restriction to be applied to users that 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.
- User policies — A high-level set of permissions that is applied to a web application and inherited by all site collections. Using 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 administrators 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.)
I’ll talk more about these policies later, in the discussion of inheritance.
Site collection roles
- Site collection administrators — These administrators have the Full Control permission level on 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 owners — By default, members of the Owners group for a site have the Full Control 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.
By default, SharePoint defines the following types of user permissions:
- 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. These rights are the most common rights for regular SharePoint users, enabling 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.
- 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.
There are two ways of assigning permissions to a SharePoint site via groups: The first one is by adding
a user to a SharePoint group, and the second one is giving an AD security group access directly to the site or putting it in a SharePoint group that has permissions on the site.
SharePoint groups enable you 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.
User-defined SharePoint groups do not have specific access rights to the site. You can organize yours users into any number of groups, depending on the size and complexity of your organization or site. One important thing to mention is that SharePoint groups cannot be nested.
However, there are also predefined SharePoint groups that do grant members specific access permissions. A set of predefined groups depend on the site template you are using. Here are the predefined groups for a team site and its default permissions to the SharePoint site:
- Visitors — Read permissions
- Members —Edit permissions
- Owners — Full Control permissions
- Viewers —View Only permissions
And here are the predefined groups for the publishing site template and their default permissions:
- Restricted Readers — Can view pages and documents, but cannot view historical versions or information about permissions.
- Style Resource Readers — Have Read permission to the Master Page Gallery and Restricted Read permission to the Style Library. By default, all authenticated users are members of this group.
- Designers — Can view, add, update, delete, approve and customize the layout of site pages using a browser or SharePoint Designer.
- Approvers — Can edit and approve pages, list items, and documents.
- Hierarchy Managers — Can create sites, lists, list items, and documents.
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.
Assigning Permissions on Objects
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 or list — Sharing Permissions
- Folder in the document library or list — Sharing permissions
- Separate file — Sharing permissions
Best practices for permissions assignment
You get the opportunity to regulate access rights at various levels. If necessary, you can create exceptions (unique permissions) in setting permissions on lower levels of the hierarchy, and you can also stop the inheritance of permissions. For example, you can create unique permissions to a particular document library and prevent it from inheriting permissions from its parent.
As a best practice, you should design the higher level permission structure in as much detail as possible and minimize the number of exceptions. The more unique permissions you create at different levels, the harder it will be to audit and control access rights. Keep in mind that there are third-party tools that simplify permissions auditing and monitoring. For example, Netwrix Auditor for SharePoint can report on the current state of your SharePoint permissions, as well as the state at an earlier point in time, and alert you when anyone changes permissions.
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 application 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 permission 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 permission 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 permissions 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 permission changes at the parent level site (list of items, document library) will not affect the child elements with unique permissions, and unique permissions will always win when they conflict with parent ones.
Best practices for permissions inheritance
It is much easier to manage permissions when there is a clear hierarchy of permissions 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 subsites 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:
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.
These permissions affect site and personal settings, the web interface, access and site configuration:
- Manage Permissions — Create and change permission levels on a subsite and assign permissions to users and groups.
- View Web Analytics Data — View site usage reports
- Create Subsites — Create subsites such as team sites, publishing sites and newsfeed sites
- Manage Web Site — Perform all administration and content management actions for the site
- Add and Customize Pages — Add, change and delete HTML pages
- Apply Themes and Borders — Apply a theme or borders to the site
- Apply Style Sheets — Apply a style sheet (.CSS file) to the site
- Create Groups — Create a group of users that can be used anywhere within the site collection
- Browse Directories — Enumerate files and folders in a site using SharePoint
- Use Self-Service Site Creation — Create a site using self-service site 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 Remote Interfaces — Use SOAP, Web DAV, Client Object Model or SharePoint Designer interfaces to access the site
- Use Client Integration Features — Use features that launch client applications in the site (users without this permission have to download documents locally, 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 Information — Change one’s own user information, such as by updating a telephone number or title or adding a picture
These permissions affect the management of lists, folders and documents and the viewing of items and application pages:
- Manage Lists — Create and delete lists, list columns and public views of a list
- Override List Behaviors — Discard or check in a document that is checked out by another user
- Add Items — Add items to lists and documents to document libraries
- Edit Items — Edit items in lists and documents in document libraries, and customize web part pages in document libraries
- Delete Items — Delete items from lists and documents from document 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 Items — Open documents using server-side file handlers (the documents 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 — Create alerts to track changes to lists, libraries, folders, files or list items
- View Application Pages — View forms, views, and application pages
These permissions affect the configuration and management of personal pages:
- Manage Personal Views — Create, change and delete personal list views
- Add/Remove Personal Web Parts — Add or remove personal web parts
- Update Personal Web Parts — Add or edit personalized information in personal web parts
