Share via

SharePoint 2013 Site Collection Permission

  • Article

Hey Y'all,

First of all some of the bland off the shelve information. Security model has several objects that are very important to consider Rights, Role/Role Definition (Permission Mask), Groups, and Users.

 

Right – This is a unique action within a Site Collection. There are 33 different rights divided into 3 groups(List, Site, and Personal) these can have dependencies on each other and SharePoint will add/remove rights based on those dependencies ie. If I select Add Items it will automatically select View Items, View Pages, and Open. You can add multiple Rights to a Role Definition.

Role/Role Definition – Is a grouping of rights to create a Role which defines what users can do within the site collection. There are 7 Role Definitions defined OOB you can choose to use them or create your own, they are Full Control, Design, Edit, Contribute, Read, Limited Access, and View Only. These can only be defined at the Site Collection level, subsites will inherit them and cannot create their own. You can assign one Role to multiple groups but you cannot assign multiple roles to one group.

Groups – There are 2 types of groups that you need to consider in SharePoint, Active Directory Groups and SharePoint Groups. You want to assign your roles to SharePoint Groups and then add Active Directory Groups into the SharePoint Groups. You can have multiple Active Directory Groups in each SharePoint Group. NOTE: You can assign Roles to Active Directory groups but this is not recommended.

Users – Is the identity of your users within the User Profile Service which is connected with an Active Directory account, you can add these to SharePoint Group, or Roles. The recommendation is that you don’t use them and instead use active Directory groups There are several reasons for this the first being the 64 bit acl issue (Acl’s have to be under 64 bits or weird things happen), the second is that Search crawls permissions separate from content and by adding active directory groups you will make less changes in SharePoint thus having smaller crawls.

 

To inherit or not inherit… 

You want to break inheritance as little as possible, there are several reasons for this but I the main ones are simplicity of managing permissions, Less issues with Security breaking, Less crawling by Search service. Along the same lines do not break inheritance at the item level, instead create folders and break inheritance on it.

 

Customizing Security…

How do I recommend customize security? Creating your own Role Definitions, as an example I have a customer who wants to restrict Site Collection Owners from adding Subsites or changing permissions. They have created their own role definitions that allows owners to do everything but those two actions (I have attached the functions and code that I wrote for them so they could automate the site creation).

You had mentioned that you have a group that does a specific task in the Site Collection and you are maintaining that list. I think it would be better to have a group with a customized role definition for these users that way they only get the permissions they need for the task. Which leads to the bigger picture for me which is that Site Collections should follow least privilege just like our service accounts do, users should not be able to do only what they need to do. This will help to prevent mistakes which would have led to a helpdesk ticket, as well this will help to prevent possibilities of malicious activities. As well this will allow Site Owners to change people in this position without having to work with you, allowing them to be self-sufficient and less headache for you.

The last comment I do have is that not all actions in a site collection are clearly tied to a specific Right, but they definitely are connected to a Right. To help with this I suggest that keeping it simple should always be on your mind as you design security, as well once you have a design that you think will work to test it for every action looking at things like installing apps, creating subsite, creating pages, etc. 

 

Best practices….

Best practices for SharePoint Security permissions

  • Establish a clear hierarchy of permissions and inherited permissions

  • Arrange sites and subsites, and lists and libraries so they can share most permissions

  • Break permission inheritance as infrequently as possible

  • Assign permissions at the highest possible level

  • Minimize unique and fine-grained permissions 

  • Avoid security design for large list/library in which all or most content must be uniquely secured (item-level)

Best practices for Authoring user access

  • Do follow the principle of least privilege. Users should have only the permission levels they need to perform their assigned tasks.

  • Do limit the number of people in the Owners (Full Control) group.

  • Do consider using AD groups for securing SharePoint resources across multiple site collections when a standard set of users require similar access.

  • Do reuse existing organizational role-based AD groups where feasible rather than creating new AD groups just for SharePoint.

  • Don’t assign permissions directly to individual users.  Instead add user as member of appropriate SharePoint group.

  • Don’t assign individual permissions. Instead use permission-levels.

  • Don’t assign permissions directly to AD groups. Instead add AD group as member of SP group.

  • Don’t customize the default permission-levels. Instead create new custom permission-levels, if required.