Update 17/8: apparently my explanation was not that clear so I added some extra details
An important thing to remember is the fact that SharePoint scales through the use of site collections. So if you have a fairly large implementation of SharePoint you will be typically using multiple site collections.
One of the things which has caused some serious problems in the past – but is not that clearly documented is the 2000 security prinicipals limit per site collection.
If you read through Plan for software boundaries – you see this
| Security principal | Approximately 2,000 per ACL (Access Control List) on any securable object (scope) | The total size of the ACL on scopes can be no larger than 64kb. Because each security principal is approximately 32 bytes in size, there can be no more than approximately 2,000 security principals or less for each scope. If this limit is reached, indexing of items in that scope, and all items below that scope, to fail. Also, because SharePoint Groups are expanded during the indexing process, having more than 2,000 users or Directory Groups in a SharePoint group and using that group for securing scopes may cause indexing of items secured with these groups, and all items below them, to fail. |
The scope they are talking about is according to me - site collection level. Every time you secure something in a site collection – meaning you assign a security principal (for developers –a SPPrincipal object) with it’s permissions set to a site, or a specific library/list or even to an individual document/item, an entry is added to a list of security principlas at site collection level. It is this list of security principals which has a limit of 2000 entries.
So no troubles if you are using 40 distinct Active Directory groups all over the places to assign security in thousands of individual documents – but when you are using more then 2000 individual users which are assigned a permission directly in one or more places within a site collection – you will get into trouble. There is no problem with Active Directory groups who contain thousands of individual AD users since they are not expanded.
The article only states problems when crawling but I also noticed some performance issues on SQL Server level where we needed to put in some extra processing power.
9 comments:
Hi,
The information in your post isn't completely accurate.
This specific software boundary or "magic number" has changed a couple of times over the last few years based on tests Microsoft did. As you are stating it is now recommending: Approximately 2,000 per ACL (Access Control List) on any securable object (scope).
Scope in this case means any scope on which you can assign permissions. It can be a site collection, a site, a list/library or an item. Now it's true that if you use groups that all groups are created on the site collection level. But as long as you don't assign any permissions to that group on the site collection level the group doesn't count as one of the 2,000 security priciples you can assign on a site collection.
This means that theoretically if you break inheritance on all sub sites you can hand out permissions to 2000 groups or users on each sub site and have many sub sites.
There is one "but" to this. The displaying of the groups in People and Groups will probably get slower, because that will probably try to display a lot of groups.
Hope this clarifies the recommendation.
Mirjam
Eh? I'm afraid I don't understand your description any more than the MSDN one.
Is this saying that I can only use 2000 individual users or groups in a site collection? Or that I can only specifically secure 2000 sites/lists/items (i.e. non-inherited permissions)? Or that I if I assign permissions for a particular site/list/item then only up to 2000 groups can have rights configured against it?!
Confused...
Andy, I added some details so I hope it is a little bit clearer now. Mirjam - I'm not really sure that you are correct.
The specific case which got us into problems was a workflow which broke security at the document level and assigned it to a number of individual users and reset it back again once the workflow completed. Apparently a massive number of security principals where created at site collection level and where not cleaned up afterwards... so the performance of the code degraded (which broke the permissions) quite a lot once the magic limit was broken.
Mirjam> If you break security on a lower level (web / list / listitem) and add individual principals, those principals are also automatically added to the sitecollection scope as "Limited Access", which afaik does count as one of the 2000.
Hi Jopx,
You're right about the performance degrading when you add a lot of security principles, as they are stored in one "list" at the site collection level. Also note the "but" in my last sentence. I should have said that a lot of security princples will make it slow to retrieve them and not just to display them. When setting permissions it might also retrieve the principles, which will make that slow as well.
However, that being slow has nothing to do with your search not working because you have too many security principles on the site collection scope, which is what the software boundary, or "magic number" is about. So even though your environment might perform like crap, when setting permissions the content in your site collection and sub sites will still be indexed by the SharPoint search! Just make sure you don't have more permissions assigned to more than 2000 security principles per scope.
Hi Jeroen,
Breaking the inheritance on a list will give all security principles that have access on that list at least limited access on the web or sub site that the list is in. So indeed the prinpciples that have permissions on that list will count towards the 2000 principles in that sub site.
However breaking inheritance on a sub site will not give the security principles that have permissions on that sub site limited access to the site collection.
For instance, if you've got a site collection where 5 SharePoint groups have permissions assigned and you've got 1000 sub site where on each sub site 3 unique SharePoint groups are assigned permissions your environment can still be indexed by the SharePoint Search engine.
However, performance when setting permissions, or going to People and Groups on the site collection level might be degraded.
Mirjam
jopx,
We had the same issue on breaking permission at list item level in a library. Can we avoid creation of SPPrinciple objects at site collection, site level?
Any news on improvements or not on the ACL issue for SP 2010?
> Any news on improvements or not on the ACL issue for SP 2010?
I'm also interested to know if the claims based security model 2010 gets around some of these low level ACL limits. Any chance of a follow-up article for 2010?
Post a Comment