Blog written by:
Chris Ang
SharePoint Architect
CCNA, MCPD, MCTS, A+
Intro
While SharePoint is a great collaboration and communication tool, managing and understanding user permissions in SharePoint can be quite exhausting for administrators.
This is because of two main reasons.
Firstly, just like file servers, SharePoint has local groups (SharePoint Groups) that can contain AD groups and users. However, unlike file shares, wherein server local groups are not frequently used on the shared folders, SharePoint local groups are very common. This can make it complex to manage, more so in large organizations where the SharePoint administrative team maybe a different one than the team managing Active Directory.
Office 365: Although Office 365/SharePoint Online does not have an exact equivalent to Active Directory groups, the closest thing would be Azure Active Directory Security Groups. Office 365 Groups are similar but behave differently as these types of groups cannot be as readily re-used as an AD Security Group can. ThreeWill has a great article on this.
See this article for creating Azure AD Security Groups for Office 365 and SharePoint Online
Also see Office 365/SharePoint Online Security Groups
Secondly, the permissions in SharePoint themselves are quite complex in nature. Unlike NTFS file systems, which only contain Full, Modify, Read & Execute, List, Read and Write, in SharePoint (on-premise and SharePoint Online/Office 365) you have 12 permissions types for lists. These include 3 for “personal” actions like views and 18 different types for sites too! All these permissions types can be grouped into “permission levels”. To illustrate this complex structure, let’s take the example of the default “Contributor” site permission level. This contains 8 of the 12 permission types. In addition to the built-in permission levels, administrators can build custom permission levels as well. Having numerous lists and several items or folders with unique permissions makes it tough to see the various embedded permission levels from one single interface.
Moreover, a particular user, group or SharePoint Group can be given multiple permission levels on a particular list or site, rendering it rather difficult to track as to what kind of access the user has been granted and what they could do with the data!
(Source: https://blog.varonis.com/why-do-sharepoint-permissions-cause-so-much-trouble/ )
These issues increase the complexity for administrators to report on user access and getting those reports is quite cumbersome since the SharePoint Out-of-Box “Check Permissions” function is very limited. Also, the fact that the process of Out-of-Box reporting is a manual one and needs to be done for every site (using ‘Check Permissions’), adds more to the problem as there can be hundreds or thousands of sites. Also, checking permissions at the site level repeatedly is tiring and inefficient.
Over time, a proliferation of security changes can be overwhelming and difficult to capture an overview of the current state of security settings in the various locations in all of the sites you need to manage.
Regardless of whether you are using Office 365/SharePoint Online or SharePoint on-premise, it is common for SharePoint to grow large and have security settings across multiple web applications, site collections, sub-sites, lists, folders and even items.
Efficient Reporting System is the Need of the Hour
SharePoint’s collaborative approach has come under a cloud several times recently when an NSA leak led to a security breach and this was attributed to the organization’s use of SharePoint. In this particular case, the system administrator who leaked the sensitive data, had privileges across a variety of systems. And the culprit in question had access to data, which shouldn’t have been with him in the first place.
(Source: https://cipherpoint.com/2014/06/sharepoint-security-impacts-from-snowden-and-wikileaks-breaches/)
Hence, the need to have the right mix of security controls through efficient permissions in the right architectural approach has become a high priority for organizations. Users need to be granted permissions for efficient collaboration but it’s very crucial to know which user has what kind of information and whether the information is really a “need to know” kind. Therefore, the reporting system also needs to be customizable and powerful to keep up with the enterprise data security requirements.
We have a blog post that includes a PowerShell script to find Users with direct access to SharePoint Lists or List Items here.
(Source: http://www.slideshare.net/bobbyschang/sharepoint-permissions-worst-practices)
Setting up SharePoint Permissions
Let’s now look at some of the Best Practices for SharePoint security design and setting up user access, which are applicable for both SharePoint on-premises and SharePoint Online/Office 365.
Security Design
- Structure the hierarchy of permissions and inherited permissions. Arrange the sites, sub-sites, lists and libraries according to the permissions they have. Try to keep a consistency in permission structure across sites so it is simplified. For example, only allow certain areas to have ‘unique’ permissions, and mark/document them clearly. This needs to be done early in the planning phase to establish the data structure and how it can match permission requirements.
- Grant permissions at the highest possible level. Permissions granted too deep in a list or library make it difficult to manage. Especially if you do not have a good permission reporting tools to identify these ‘deep-assigned permissions’ easily.
- Reduce the number of unique and fine-grained permissions. This seems obvious, but often it is done in a quick decision that opens up security issues. Plan how it will be managed before you grant fine grained/item-level permissions. Try to isolate these into only specific libraries you can manage (and ‘identify’ as having ‘uniquely permissioned items’ within them) and not across multiple libraries that you do not track which ones have uniquely granted permissions.
- Note that having uniquely permissions Items or folders will have a negative impact on performance and responsiveness for page loads.
Authorizing User-Access to SharePoint
- Permission levels must be granted to users only to the extent actually required to perform their assigned tasks. Too often I see environments where an administrator will find the easiest way to make things work is “OK, let’s grant that account full control”, it works so then job done. However, settings and security changes like this can be forgotten and if not reported on, can lead to loopholes in your environment quickly. In addition, accounts/users with too much control could also grant other accounts access. Only grant the permission required, provide ‘least privileged access’ as a rule of thumb to avoid headaches later.
- Restrict the number of users in the Owners (Full Control) Group.
- Use the Active Directory (AD) groups for securing SharePoint resources across multiple site collections when several users require similar access.
- Try to reuse existing role-based AD groups where possible instead of creating new AD groups for SharePoint. This will minimize overhead. If easier to view the SharePoint groups by ‘name’, then add the existing role-based AD Groups to these SharePoint groups. That way, employee on-boarding and off-boarding is simplified and AD Administrators do not need to double their efforts and adding/removing to both role-based AD Groups AND SharePoint groups (which they also may not be trained on).
- Avoid assigning permissions to individual users; rather, add the user as member of the appropriate SharePoint group or Active Directory security group. This reduces the overall number of individual user access across the system leading to better management.
- As briefly mentioned above, this is debatable, but I personally would recommend don’t grant permissions directly to AD Groups. Instead, add the AD group as member of the SharePoint group.
- Don’t customize the default permission-levels; instead, create new custom permission-levels when needed.
- Document your SharePoint environment permission and security structure to help understand how to keep it consistent and identify potential problem areas and issues before they arise.
While these are some of the recommendations for setting up permissions and designing the security structure, a combination of these approaches often works best for any organization.
(Source: https://blogs.technet.microsoft.com/marj/2015/07/05/best-practices-for-authorizing-user-access-to-sharepoint-sites-using-sharepoint-groupspermissionsinheritance
https://support.office.com/en-us/article/Roadmap-Grant-permissions-for-a-site-10682AF5-E6F2-4176-96AB-D990AD143ADE )
Common Issues & Best Practices for Fine-grained Permissions
Sometimes, it is inevitable, and you may want to limit the user access to the site or its contents.
For example, you want to give access to only certain files and not the whole library or folder. Or you may want to provide access to all but restrict editing access to only some members in the team. In such scenarios, fine-grained permissions can be set beyond the default levels.
However, use of fine-grained permissions can lead to performance issues and can be difficult to manage. Hence, certain steps must be taken and best practices followed to avoid its incorrect usage that can lead to potential problems.
The key is to Plan where and when to grant unique fine-grained permissions. Identify where these are allowed to be set, and keep those libraries in check and managed.
Limit Issues
- Too many views in a list
SharePoint has a built-in limit of 50,000 uniquely permissioned items (‘scope’) per list or document library. To overcome this, follow these best practices:
– Only set unique permissions on folders and other similar parent objects.
– Avoid creating too many objects with unique permission below an object that already has many ‘uniquely permissioned objects’.
– If you still need more than 50,000 uniquely permissioned objects in a list or document library, then you need to move some items to a different list or library. - Modify the built-in uniquely permissioned items limit
By using Windows PowerShell script, one can also change the built-in ‘scope’ limit. - Too many members in a permission ‘scope’
You may already be aware that whenever the membership of the associated permission ‘scope’ changes, a binary ACL (Access Control List) is calculated. This happens even when a new limited access member is added. Now, as the number of scope membership rises, the times required to recalculate binary ACL also increases. This problem multiplies further with the addition of more number of users at a child object’s unique scope, which causes the parent scopes to be updated with the new Limited Access members. Therefore, each time the binary ACL has to be recalculated leading to higher processing times even though the resultant ACL remains the same.
To avoid this, the following best practice is recommended:
– Make use of group membership instead of individual user membership while setting permission scopes. This leads to single group being updated with Limited Access rights instead of each user being updated, which shortens the time for Limited Access rights push and recalculation of ACL on the parent scope objects.
– Wherever possible, use a domain group instead of SharePoint group because in the case of the latter, the crawl will be of the entire index which is more time consuming.
(Source: https://technet.microsoft.com/en-us/library/dn169566.aspx https://technet.microsoft.com/en-us/library/cc262787.aspx https://technet.microsoft.com/en-us/library/dn169567.aspx )
Processing and Reporting Best Practices
• In order to quicken the processing of items in the view, you must ensure that you don’t have too many items at the same level of hierarchy in the document libraries.
• Use event handlers with help of methods like SPEventReceiverType.ItemUpdating and SPEventReceiverType.ItemUpdated methods to register events and control edit permission. This helps make security decisions based on metadata without affecting the view-rendering performance.
• Reporting on fine-grained permissions across multiple sites is difficult to track. To overcome this, you need to reduce the number of scopes above an item.
(Source: https://technet.microsoft.com/en-us/library/gg128955.aspx )
Removing or Changing User Access
Administrators need to manage the user access to SharePoint site effectively and removing users who have left the organization or changed their roles, is an important part of this process. This is required not only to secure the resources on the site but also to stop sending alerts to them from the site.
The process of removing or changing user access becomes simpler if you assign permission levels to groups instead of individual users. A SharePoint group not only contains a set of individual users but also Active Directory Domain Services (AD DS) groups. Even in SharePoint Groups, it is better to apply permissions and then add AD Groups within the SharePoint Groups, which identify the user role, so that it becomes easier to find the user access and modify in required places.
For example, a SharePoint Group called “HR Benefits Contributors” is a SharePoint group that allows users in that group to add/edit/read HR Benefits forms. Within that SharePoint group would be an AD Group called “HR Users”, for example, consisting of users who are able to update those forms as needed. Then we could have another SharePoint Group called “HR Benefits Readers” who have read access and in that group is “Internal SharePoint Users” domain security group that allows everyone in the company to access these forms read-only. The AD Group “Internal SharePoint Users” can be re-used across multiple sites and is better than “All Domain Users” AD Group because sometimes you may want to exclude contractors or other AD Users from certain content (if not right now, it could be required in future).
(Source: https://technet.microsoft.com/en-us/library/cc261972.aspx )
Understanding Permission Levels
Permissions levels in SharePoint are a set of permissions that are assigned to a specific SharePoint Group. Along with the groups, permission levels are also defined at the site collection level and are directly inherited from the parent object by default. When a user or group is added to SharePoint, the permission levels get automatically applied to them when granting access. Apart from default permission levels, you can also customize permission levels for different groups. While establishing the security of your SharePoint site, you need to decide how to group the different users and what kind of permission levels need to be assigned for each one of them.
Each kind of SharePoint site by default includes certain SharePoint groups. For example, a Team Site automatically includes Owners, Members and Visitors Groups. On the other hand, a Publishing Portal Site includes these three groups as well as additional groups like Approvers, Designers, and Managers etc. When a site is created SharePoint creates a pre-defined set of groups. But in addition, an administrator can create custom groups and permission levels.
We will explore the 3 default groups and the associated permission levels here:
Owners
They have full-control and all SharePoint permissions. This group can be used to grant people with Full Control permissions to the SharePoint site.
Members
They have the Edit default permission level, which includes all permissions in Read as well. This group is used to grant Edit permissions to users of the SharePoint site.
The Edit Permission Level has the following permissions by default apart from the Read Permission Level – View, add, update and delete items. Add, edit and delete lists. Delete versions, browse directories, edit personal user information, and manage personal views. Add, update or remove personal web parts.
Visitors
They have the Read default permission level only and are not authorized to edit. This group is used to grant people with Read permissions to the SharePoint site.
The Read Permission Level has the following permissions by default – Open, View items, versions, pages and application pages. Browse user information, create alerts, use self-service site creation, use remote interfaces and use client integration features.
The lists and libraries in each of these groups will automatically inherit the permissions from the site level itself.
Common Issues in Granting Access
One of the common problems with user access is the misinterpretation of “Edit” rights. For example, when users are granted access through the “Members” group, which by default has Edit rights, the users will have the ability to edit and DELETE entire lists instead of merely adding or editing documents. However, this is not favorable and often not the intention in the first place.
The Members group is usually for Power Users, who are well aware of the rights, what kind of administrative changes are possible and their consequences. Hence, in this case, one can create a 4th customized group called “Contributors” for all or specific libraries or lists with a defined “Contribute Permission Level” that gives the users the rights to add or edit documents but not delete whole lists or make any administrative changes.
(Sources: https://technet.microsoft.com/en-us/library/cc262690.aspx , https://support.office.com/en-us/article/overview-best-practices-for-managing-how-people-use-your-team-site-95e83c3d-e1b0-4aae-9d08-e94dcaa4942e#__toc259623116 )
Currently working at Cognillo (https://www.cognillo.com), he has helped architect and develop SharePoint Enterprise products for customers such as the U.S. Navy, U.S. Army, U.N. Security Council of Netherlands, Australian Government, U.S. Dept of Treasury, U.S. Dept of Justice, Canadian Dept of Defense, Scotiabank, JPMorgan CHASE Bank, Intel, Ford Motors, Microsoft, NASA, DARPA, SNC Lavalin, Penguin Books, and more.
He is a proud father of 2, and when he has any spare time, he loves to paint portraits of his kids.
- What is SharePoint? A Beginner’s Guide to MS SharePoint Software - October 8, 2018
- Beginner’s Guide: Windows PowerShell – How to Use Tutorial for Dummies - October 8, 2018
- Remote PowerShell to Manage SharePoint on-premises - August 14, 2018