Monday, September 14, 2015

SharePoint Site Permissions

Other than adding or updating site content, one of the most frequent tasks for a SharePoint site owner or delegated team member to do is to ensure the proper people have the proper level of access to the site's content, and also to ensure that unauthorized people aren't able to access content they shouldn't have access to. Modifying SharePoint site permissions can be fairly simple, or very complex depending on the complexity of your site and what rights people need to the various subsites, lists/libraries and items contained in a site. TechNet has a good general overview of site permissions in SharePoint 2013 here. You should also read through these TechNet articles:

There are a few key ways to reduce the complexity of managing SharePoint site permissions:
  • Identify a specific couple or few team members who will be tasked with control permissions, including approving or declining access requests. The old adage "too many hands in the pot spoils the soup" applies here. Ensure those people have read sufficient documentation and/or have been trained to be able to take on the role of managing permissions.
  • Use standard SharePoint naming conventions for groups (e.g., [site/list/library name] Owners group for people needing Full control rights, Members group for people needing Contribute rights, and Visitors group for people needing Read rights).
  • Do not break inheritance of subsites, lists/libraries or items unless truly necessary. The TechNet permissions overview article has a section on permissions inheritance. Breaking inheritance means having to separately manage the subsite, list/library or item you break inheritance on.
  • Use SharePoint groups, not AD groups. One may think it would be easier to just have the team in an AD group, then add that AD group to the site or list permissions, thereby granting rights to all the people in that AD group. However, the average person does not know how to see the people contained in the AD group, and you cannot see the members of an AD group in SharePoint. This can both increase complexity, and reduce security since you don't necessarily know who is in the AD group.
  • Add people to SharePoint groups rather than adding individual users to site, list/library or item permissions. This allows you to see at a glance who is in the group and know what level of permissions all of those people have.
One final note regarding Project Server PWA sites: Site permissions should never me modified on PWA sites because site permissions is controlled at the Project Server level. 

No comments:

Post a Comment