What is 64k ACL limit


Lot many times we discuss on this 64K ACL limit effecting a SharePoint environment and showing abnormal behaviors for alerts and search on the SharePoint site.

The section below briefly talks about what is this 64K ACL limit, how is it calculated and how we can proactively avoid this limitation.

 

 

All objects in Active Directory, and all securable objects on a local computer or on the network, have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors, in turn, contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object’s security descriptor can contain two types of ACLs:

  • A discretionary access control list (DACL) that identifies the users and groups who are allowed or denied access
  • A system access control list (SACL) that controls how access is audited

The access control model that is used by the Windows Server 2003 operating system is administered at the object level by setting different levels of access, or permissions, to objects. If permissions are configured for an object, its security descriptor contains a DACL with security identifiers (SIDs) for the users and groups that are allowed or denied access. If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object.

You can use this access control model to individually secure objects such as files and folders, Active Directory objects, registry keys, and printers, as well as devices, ports, services, processes, and threads. Because of this individual control, you can adjust the security of objects to meet the needs of your organization, delegate authority over objects or attributes, and create custom objects or attributes that require unique security protections to be defined.

 

“A principal is a user or group used to control security. If you add a user to a site, the user is the principal, but if you add a group to the site, the group is the principal. The key to scaling security in Windows SharePoint Services is keeping the number of principals reasonable. By using groups, a smaller number of principals can be used to grant access to a much larger number of users” --- (Reference : http://msdn2.microsoft.com/en-us/library/ms457294.aspx)

As shown in the Plan for software boundaries (http://technet.microsoft.com/en-us/library/cc262787.aspx ) in the notes column for the mentioned “2,000 per Web site guideline” : The size of the access control list is limited to a few thousand security principals (users and groups in the Web site). In fact it is the site collection.

The security boundary that seems to be the concern is the Site Collection. Site collections are the ‘container’ for all users and groups in that site collection. If sub webs are used, all the sub webs would all be in one site collection. If that one site collection goes over 2000 security groups then we know from the published paper that his performance will be impacted. How much it is impacted etc would need to be tested on an environment by environment basis.
[For e.g. if you have 200 users (with unique permission) on subweb A, 300 users (with unique permission) on subweb B and 1300 (with unique permission) users on subweb C. Then the total ACL size for the Site Collection will 200 + 300 + 1300 = 1800 users]


The effective limit is relating to the ACL size, means the Maximum number of ACEs in an ACL, and as published by Microsoft about the ACL Size Constraint :
“The number of bytes of memory allocated for the ACL. The size of an ACL varies with the number and size of its ACEs. The maximum size of an ACL is 64K, or approximately 1,820 ACEs, depending on the size of the ACEs. However, for performance reasons, the maximum size is not practical, it will vary from 1820 to 2000.
(Reference :
http://technet.microsoft.com/en-us/library/cc781716.aspx )

Such ACL Size limit is also published in Authorization MSDN Development Reference in the following quote :
The maximum size for an ACL, including its ACEs, is 64 KB (Reference: http://msdn2.microsoft.com/en-us/library/Aa374931.aspx )
It’s about the 64KB ACL size limit of Windows. It stands on every object supporting ACL (Maximum number of ACEs in an ACL : http://support.microsoft.com/kb/166348 ).


To my understanding, the key limit is the 64KB for the ACL size, which depends on the number and size of ACEs (which is stated approximately 1820 or 2000).

A Best-practice would be to plan for a maximum 32KB for ACL size (approximately 1000 ACEs)

We have http://technet.microsoft.com/en-us/library/cc261700.aspx for Capacity Planning references.

 

Note: this 64K ACL limit is not a limitation of an application, instead this is a property of the Windows Operation System.


Comments (1)

  1. Haifa says:

    How do I check How many users are present in the site collection with uniquire permission in WSS 3.0?

Skip to main content