SharePoint Security: Hard limits and recommended practices

This summarizes the hard limits and recommended guidance for Groups, Access Control Lists (ACLs) and securable objects in SharePoint 2007.

Unique accounts or groups per SharePoint Group: ~2000. This is the identical with the guidance for any large SharePoint list as covered by the Working with large lists in Office SharePoint Server 2007 whitepaper. Lists can handle thousands of items, but performance of a Views (i.e. while viewing or updating membership) will degrade after 200 items and become unacceptable towards 2000 because the underlying SQL queries are not paged or filtered. Note that the next limitation (see Users per SharePoint ACL, below) will affect the ability to index any item (or list) you apply such a large ACL to. Resolution: Use a third-party tool to manage large SharePoint Groups or re-think your design to include AD groups. Mitigation: When possible, rather than assigning users membership in a SharePoint Group, assign users to an AD group and then assign the AD group membership to the SharePoint Group.

Users per SharePoint ACL: Query results must not exceed 64k, or ~1000 users per ACL. When exceeded, the "Parameter is incorrect" error is thrown causing crawling to fail on the item. This issue affects indexing, but does not otherwise affect SharePoint. The limit is noted by Joel Oleson in the comments of a "2003 to 2008 security changes" post and the Best Practices for SharePoint Search article on TechNet. The issue is not SharePoint-specific and will affect any content crawled with large ACLs including file system objects like Network Shares. KB article 885482 describes the cause as "The maximum buffer size of the InitializeAcl function is 64 KB. Therefore, the maximum size of an ACL in Windows, including the access control entries (ACEs) that are contained in the ACL, is 64 KB." Resolution: Either exclude the item from indexed content, or remove entries from the ACL. Mitigation: This is a rare issue normally avoided through sound design. However, since AD groups are not expanded when the ACL is read, assigning individuals to AD Groups rather than SharePoint Groups will mitigate the limit.

Active Directory groups per-user: 1024. Each membership increases a user's "SID count" and the limit on the token bag is 1024. When the limit is exceeded the error reads, "During a logon attempt, the user’s security context accumulated too many security IDs." The whitepaper Addressing Problems Due to Access Token Limitation discusses the issue in depth, and KB 906208 describes the error. Consider this limit if AD groups are to be used to manage SharePoint groups. Resolution: Remove the users from one or more AD groups to reduce the SID count. You can verify the issue with the Group Membership Evaluation feature of the Ntdsutil.exe tool. Mitigation: Manage users in SharePoint Groups rather than AD groups if growth would require any user to be a member of more than 1024 groups.

Recommended Guidance
The Plan for Software Boundaries whitepaper contains guidelines for "people objects" but its guidance for security principals is (politely) less-than-useful. For example, the guidance that "You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users" says nothing about how many people can (or should) be added to a SharePoint Group and ignores the SID limits of AD groups. It would also lead you to believe that it's an acceptable option to use local Windows security groups to manage permissions rather than domain accounts. In a nutshell, that would be a bad idea if your farm will ever have more than one server.

There are many MSDN and TechNet articles with recommendations on what granularity of permissions is "right" but the one simply named Plan site security is the most detailed and provides the best example. To summarize and disambiguate the best practices and recommendations:

1. If many securable objects share the same ACL, then group them into a container with that ACL. This applies equally to list items within lists, or libraries within sites. If the permission change is a temporary state in a securable object's lifecycle (for example to assign reviewer permissions during a workflow) then reset the permissions to inherited when the temporary state is complete (e.g. at the end of the workflow). [Update 2008-09-12 TB] Avoid unique permissions on folders, as Flat views will not secure folder content as expected.
   
   
2. The more ACLs you create, the more ACLs you have to manage. I know, I know, it's self-evident, no? How I wish it were. A problem of some articles is that they can be interpreted to recommend moving the problem rather than solving it. For example: "Minimize the use of custom or fine-grained permissions. The more fine-grained permissions that are applied, the more difficult it is to track who has access to what." Well duh. The problem is that not applying permissions does not remove the business need to have permissions. If the issue is the tools and not the limits of the platform, the correct guidance should be "if management or reporting tools don't work the way you want. . . ." Better, it deserves to be a recommendation of its own.
   
   
3. If management or reporting tools don't work the way you want, then build or buy better management or reporting tools. DeliverPoint is one option. [I'll continue update this post as others are suggested.]
   
   
4. Understand the strengths and weaknesses of managing users in SharePoint Groups vs. Active Directory. A strength of SharePoint Groups is allowing the same people responsible for building teams in an enterprise to form their own groups. IT has been the bottleneck for too long. Advantages of SharePoint groups are decentralized maintenance, isolation by Site Collection, the ability to query it with the API without adding to DC load, and the ability to integrate it as necessary with external Authorization Providers (AD, FBA, etc.). This last point makes SharePoint groups preferable for extranets and mixed authentication zones, allowing internal users to authenticate through AD and external users through another AuthZ provider.
   
   AD Domain Groups may be preferred for central management and a standardization of tools. Unfortunately these tools are not usually built for or available to users outside of IT and support services. AD groups are also not visible from within SharePoint without custom code or third-party components.
   
   Unless your AD groups are subject to strict discipline so that "Help Desk" only contains people from Help Desk, and not people who for any reason one day needed access to the Help Desk's files (e.g. senior management or Gladys from accounting), it is best to start fresh with new AD groups for SharePoint. Since 95% of companies did not have that discipline when securing network shares, you should start fresh unless you can both prove that your AD groups are clean, and policies are in place so groups will not be corrupted when people start applying them to SharePoint.
   
   [Update 2008-09-12: This entire section was rewritten based on TB's suggestions. The earlier version preferred ADGroups to SPGroups solely by virtue of central management.]
   
   
5. If you break inheritance on many lists for the same users, clean up duplicate Limited Access entries in the containing site. When you configure a list or list item to use unique permissions and add a user to it who is not listed as a member of the site, so as to not break navigation the user is automagically given Limited Access -- bare-minimum read access -- to the site that contains the list. All fine and dandy until it hapens again and a duplicate entry is created. Resolution: Remove the duplicate entries by hand or automated utility.
   
   
6. Do right for the Business. Sometimes to meet a business need you need to break from the recommended guidance. There is "recommended guidance," and then there are hard limits imposed by the platform that you should not break without raising flags and shooting off fireworks. The appropriate solution may be at odds with "recommended guidance" and that's okay. Your goal is to simulate the business, not to change the business. When conflict happens, help the business understand its choices. Make any conflict crystal clear to the people paying the bills and suggest alternatives. If the conflict is a hard platform limit with an eventual breaking point, provide all the options to mitigate the issue and make sure that the person with the power to make the decision understands the eventual consequence of the decision. You cannot stop someone above you in the food chain from blowing his or her own foot off. This is natural selection. You can only prove that you asked them not to, and escalated alerts to the issue as danger became imminent.

Thanks to Dennis Shtemberg from Infusion for getting the ball rolling with his research on uniquely-permissioned items per list, Todd Klindt for a great dialogue, corrections and help to tease apart the issues, Todd Bleeker for taking the time to review this post and make it better, and Joel Oleson and Keith Richie for their clarifying the ACL issue and their earlier work on the subject. Todd and Keith are co-authors of DeliverPoint.

Fixed or Unproved [Last Updated: 2008-09-26]

This section contians the guidance that either no longer applies, or never did.

Unique list-item permissions per list: 600 to 1000. Resolved by WSS and MOSS SP1. When you assign unique permissions to list items in a given list, when the critical point is exceeded the error is displayed: "Operation is not valid due to the current state of the object" and the following event is logged in Event Viewer: "Unknown SQL Exception 156 occured. Additional error information from SQL Server is included below. Incorrect syntax near the keyword 'SET'. Incorrect syntax near ')'. Incorrect syntax near the keyword 'with'. If this statement is a common table expression or an xmlnamespaces clause, the previous statement must be terminated with a semicolon." Resolution: When any list item with unique permissions is deleted, the list works again. When any list item with inherited permissions is deleted, the issue persists. Mitigation: If many items will share the same ACLs, then group them into a separate list or library and apply the ACL to the list or library. If the permission change is a temporary state in a list item's lifecycle (for example to assign reviewer permissions during a workflow) then reset the permissions to inherited when the temporary state is complete (e.g. at the end of the workflow). 

Users listed in a Site Collection's User Info Gallery (aka SPWeb.SiteUsers): 1500 to 2000. No evidence can be found to support this guidance, and believe it to be a misinterpretation of the limit on ACL size. If you've been affected, please comment with further detail. 

A user is added to this list (and assigned an ID unique to the Site Collection) when a user is a) explicitly assigned a permission level on a securable object, or b) when a user is named as a member of either a SharePoint group or an Active Directory (AD) Group and that group is assigned a permission level on a securable object and the user then contributes to the site. Note that prior to WSS 3.0, just visiting a site added the member to the list, and now the user needs to actually contribute. When a user is deleted from the list either through the API or the User Info Gallery, the entry is marked "Deleted" but not removed [Update 2008-09-12: Corrected by KR]. Resolution: If you pass the limit, you need to remove users from the list. The difficulty is figuring out which are no longer listed in Created By and Last Modified By fields. Displaying or editing a list item with a reference to a deleted entry results in an error. Mitigation: 1) Create Site Collections such that each will serve up to 1000 contributors. [Deleted: "Create AD groups for readers." Not necessary as readers aren't added to the list.] Monitor the size of the SiteUsers list, and consider routines to prune rows from it where contributors are no longer named on sites in the collection (e.g. in Created By, Modified By, or Assigned To columns). 2) Either assign AD groups, or a combination of AD groups and individual users (the exceptions who do not logically belong in the AD group) to SharePoint Groups unless this will lead to SID count issues (see Active Directory Groups per User, below).