Share via

Best Practices for Authorizing User Access to SharePoint Sites Using SharePoint Groups/Permissions/Inheritance

  • Article

The Office support topic “ Introduction: Control user access with permissions ” explains three SharePoint security features that work together to help you control user access to sites and content on sites. These features are:

  • SharePoint groups
  • Permission levels
  • Permissions inheritance and site structure

Using these three features, what are best practices for SharePoint security design and authorizing user access?  Following is a concise summary of my recommendations (applicable for SharePoint on-premises & online).

Best practices for SharePoint security design -- as much as possible:  

  • Establish a clear hierarchy of permissions and inherited permissions
  • Arrange sites (webs) and sub-sites, 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 authorizing user access to SharePoint:

  • 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 Active Directory (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 grant permissions (to some securable object) via assigning a permission-level directly to an individual user.  Instead, always grant individual user permissions by selecting a SharePoint group to add them into. Then, the user simply inherits the permission-level of their group membership.
  • Don’t assign permissions directly to AD groups. Instead add AD group as member of SharePoint group.
  • Don’t customize the default permission-levels. Instead create new custom permission-levels, if required.

Which of following practices is better for granting users site-level access?  It depends…

Users ==> SharePoint Groups

  • This practice tends to work better for “Collaboration” sites (e.g., Team sites, Community sites, etc.).

Users ==> Active Directory Groups ==> SharePoint Groups

  • This practice tends to work better for organizational Intranet sites (e.g., company Intranet portal).

Often a combination of above approaches will make most sense.  For example, consider a project team’s collaboration site.  Perhaps they choose to add individual users into the Owners and Contributors groups in SharePoint, granting users update access to the site.  But then they add an AD group representing a much larger organizational role-based membership into SharePoint’s Visitors group, by default granting all those AD group members read access to the site.

Note: Use of  AD groups could be applicable for both SharePoint on-premises and online (if directory synchronization services implemented).  For SharePoint Online if no directory synchronization and user accounts are cloud-managed, you could similarly use Office 365 Security groups instead of AD groups.

REFERENCES

Introduction: Control user access with permissions
https://support.office.com/en-US/article/Introduction-Control-user-access-with-permissions-AB2D1AB1-07CF-4C69-BDD9-390BFD787B26

What is permissions inheritance?
https://support.office.com/en-us/article/What-is-permissions-inheritance--06BB1ED1-D150-42F4-9600-FB261D4B590C?ui=en-US\&rs=en-US\&ad=US

Create, Edit, or Delete an Office 365 Security Group
https://support.office.com/en-us/article/Create-edit-or-delete-a-security-group-55C96B32-E086-4C9E-948B-A018B44510CB

Comments

  • Anonymous
    August 31, 2015
    Thanks for sharing