How to fix 64bit ACL limit exceeded problem on Sharepoint.

In many cases getting “The Parameter is incorrect” error when searching crawl logs for defining why my search is not working or one site is not to be crawled.This is one specific error that addres us to  64 kb size limit of an Access Control List (ACL). Microsoft says : “This behavior occurs if the size of the access control list (ACL) is larger than 64 kilobytes (KB). 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.”

Sharepoint uses ACL on background for securty issues. And this limitation is not actually a sharepoint limit .It is an operating system limit. If the limit is exceeded , calculation of security principals is not working and causes anomalies. One of them is unable to crawl and getting “The Parameter is incorrect” error on crawl logs.

What is the boundries and Limits

For Moss 2007 Security Principal Limit is 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.
This limit only occurs when Windows Integrated Authentication is utilized.”

For Sharepoint 2010 you should consider belowed two limit definition.  

1)”Security Scope: The maximum number of unique security scopes set for a list should not exceed 1,000.
A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to SharePoint Server. The members of an ACL for a scope can include Windows users, user accounts other than Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.”

It is a little confusing.For both version of sharepoint the rule is same don’t exceed 64 Kb limit. For Sharepoint 2010 “exceed 1000 ACE” is just a threshold. Depending of ACE’s size there isnt any strict count limit . It should be between 1820 – 2000 ACEs.

“Except for the 64 KB limit on the ACL, there is no hard-coded limit for the number of users and groups to whom you can grant access to the portal site. You can add as many users and groups to a portal site as you want until the 64 KB limit of the ACL is reached. Because the sizes of individual ACEs vary, the total number of ACEs that can be put in an ACL also varies. Therefore, the exact number of groups and users who you can add to the portal site cannot be determined from the 64 KB limit of the ACL. To avoid this issue, we recommend that you do not add more than 1,000 users and groups to your portal site. ”

Ok . I assume that you understand the ACL and limits . now we return our main issue how to fix that problem. 
Where do we start : Determining which scopes can cause the problem.

Important !  Do not change sharepoint database ! Application of any schema change to the SharePoint database, except as part of a Microsoft-supplied service pack or hot fix, will make the SharePoint environment unsupportable. This type of change should never be applied.

Using this query you can identify the amount of security principals (ACEs) per scope (ACL):

select COUNT(ra.PrincipalId) as [Count],p.ScopeUrl
from RoleAssignment ra with(nolock)
join Perms p with(nolock) on p.SiteId = ra.SiteId and p.ScopeId = ra.ScopeId
group by p.ScopeUrl
order by [Count] desc

As you see in the results that the scope of “planing” contains 370 principals. This can be groups  or directly added users to that scope.
We could not say here if this is exceeding the 64kb ACL Windows Limit.
Look at these scenarios:

               (1) If there are 369 directly added users and one SharePoint group which contains 5.000 users than you would definitely exceed the total limit of that scope! (total principal count would be 5.369!)

               (2) If there are 369 directly added users and one SharePoint group containing an AD group with 400.000 users than you don’t exceed the total limit of that scope! (total principal count would be only 370!)

In general: For each site, or list, or list-item for which you break the permission inheritance from the parent site you will get a new scope and It will use its own ACL.

Using the following query you can identify how many users are in your available SharePoint groups:

select COUNT(m.MemberId) as [Count], g.Title as [Group-Title]
from GroupMembership m with(nolock)
join Groups g with(nolock) on m.GroupId = g.ID and m.SiteId = g.SiteId
group by g.Title
order by [Count] desc

there are two sharepoint group that are in our interest.
1289 Performace Management System.
1050 Quality Team Members .

Using one of these group on any of his sites (= ScopeUrl) can cause the crawl error “The parameter is incorrect” which the customer reported for the site.

Lets consider that we add one of these big groups  (Performance Management System) to an scope for example Operations (280) .The group counts as one principal so there are still 279 principals left or direct.
this mean 279 + 1289 = 1568 principals . it is so close the 1820-2000 limit. Think about a worst scenario to add another group to one of left 279 slot. you will exceed the limit with a big possibility.

So for workaround:
1) Define your big sharepoint groups.
2) Create a AD security group for each one
3) Move users sharepoint group to AD group.
4) Add this ad group to your Sharepoint Group instead of adding user one by one.

And Special thanks to Holger Lutz for these valuable informations .

See you in next articles.