SharePoint 2013 Permission Level Best Practices

In order to view, change, or manage a site, the permission level a user has needs to allow them to authenticate it. The permission level will control all of the permissions to a site and to the child objects that will inherit that site and its permissions. When a user doesn’t have the right level of permissions, then they aren’t able to perform their tasks. If they have too much permission, they could be performing tasks you don’t want them to.

The default permissions in place are View Only which allows the user to view pages, lists, and documents but they can’t change or delete anything and Limited Access which is permissions for the user to view specific lists, documents, and more. However, they don’t have the ability to access all of the elements on a site.

When this permission level is removed, the group members may not be able to navigate the site to successfully access items. This can be true even if they do have the right permissions to access a given item within that site.

  1. Read Offers permission to view items on the site pages.
  2. Edit Permissions to add, edit, and delete lists or documents.
  3. Contribute Permissions that allow a user to add or change items on the site pages, in lists, and document libraries.
  4. Design Permissions for a user to view, add, update, approve, delete, and to customize the layout on site pages. This is due using the browser or through SharePoint Designer 2013.
  5. Full Control All permissions are given

These permissions are given by default with the publishing template:

  1. Approve Permissions for a user to edit and approve pages, documents, or lists.
  2. Manage Hierarchy Permissions for a user to edit sites and pages, documents, or lists.
  3. Restricted Read Permissions for a user to view pages and documents. However, they can’t see historical version or permissions data.

You will have a general framework in place with the default groups and permissions offered. They cover the various organizational types and roles that may be considered. Yet there could be different set up for your organization in terms of the way it is mapped out. You have the option to customize permission levels or groups if the defaults aren’t going to be sufficient to meet the needs of your organization.

You need to determine if there is a need for custom groups. If you decide there is, the process isn’t hard for creating them. It won’t reduce the level of security that your site has either. There are some situations when you will want to create custom groups rather than relying on the default groups. For example, you have only a few user roles in your organization that fit the default groups, there are well known names for unique roles in your organization that will be performing different tasks in sites, you want to maintain a 1 on 1 relationship between the SharePoint groups and Windows security, if your organization has a security group called Web Site Managers, you may be able to use that same name as a group to easily identify it, or you have other group names you prefer to use.

The decision to customize permission levels isn’t too difficult, but it isn’t as easy as the decision to customize the SharePoint groups. If you decide to customize the permissions that are assigned to a permission level, you have to keep track of the change. You also have to verify that it works for all the groups and sites that will be affected when that change is implemented. Finally, you have to make sure that the change won’t have a negative effect on the security in place or the capacity of the service to perform.

If you customize the Contribute permission level so that it includes the create Sub Sites permission then the members of the Contributors groups will be able to create their own sub sites. This can open up the window for malicious use or posting of content that you don’t approve of. When you customize the Read permission level so that it includes the View Usage Data permission, then all of the members of the Visitors group will now be able to see usage data. That can result in some performance issues.

You should only customize the default permission levels if there is a default permission level that includes all permissions with the exception of something users need to do their job completely so you want to add it or there is a default permission level that users do not have to have but they already are able to use it. The goal then is to remove it so that they can’t do tasks you don’t want them to be able to perform.

Never customizes the default permission levels if your organization is worried about security or a specific permission due to a given permission level. If you need to make that particular permission unavailable to all of your users, you can turn off the permission for all web applications through the server farm. This is a much better option than changing the permission levels.

Should you need to make many changes to the various permission levels, you will need to create a customize permission level. It will need to include all of the permissions that you need. You may wish to create additional permission levels if you would like to remove several permission from a specific permission level or you would like to define a unique set of permissions for a new permission level.

To create a permission level, you can create it and then select the permissions that you want. Some of the permissions though will depend on other permissions being in place. If you clear one, that could also clear others that depend upon it.