This is mostly a complete copy from microsoft.com
When users access a resource using Windows authentication and authorization (for example logging on to a workstation or accessing a file share), an “access token” is built to represent that user.
The number of SIDs (representing group membership, etc) in that token largely determines how much kernel memory space (Paged Pool) is required to store each copy of the token.
These allocations follow a “stair-step” pattern, as follows:
At approximately 84 SIDs, allocation jumps from 4KB to 8KB.
At approximately 177 SIDs, allocation jumps from 8KB to 12KB.
At approximately 270 SIDs, allocation jumps from 12KB to 16KB.
At approximately 363 SIDs, allocation jumps from 16KB to 20KB and so on.
As many users connect concurrently to shared resource servers such as Exchange servers, domain controllers, file servers, etc, the risk of exhausting Paged Pool resources increases. In particular the risk increases as user/connection counts increase and as each copy of each user’s token increases in allocation size.
For example, on a server with 70MB of Paged Pool available for safely storing new tokens, assuming 7 tokens per user (many applications use multiple concurrent authenticated sessions per user), the server can handle approximately:
2560 users having 4KB tokens, or
426 users having 24KB tokens
When users access a resource using Windows authentication, and Windows authorization is using Kerberos, the client machine passes a Kerberos ticket to the resource server in-line with the application layer traffic.
In the case of HTTP, Kerberos tickets are typically included in the header portion of certain HTTP requests from the client to the server.
As users become members of more and more security groups, their Kerberos tickets increase in size. Eventually the tickets may become large enough to exceed size limit restrictions on HTTP header structures.
IIS 5 (Windows 2000 Server) has a default header size limit of 16KB (a.k.a. “MaxClientRequestBuffer”).
The exact Kerberos ticket size that will lead to exceeding this threshold will vary considerably based on the following factors:
• In HTTP user’s Kerberos tickets are encoded as Base64, which typically increases their size relative to default encoding for other ticket scenarios. Note that the growth ratio may vary from one ticket to the next. In lab testing an average growth ratio of roughly 8/5 was observed. In other words, a Kerberos ticket which is estimated by this tool to be approximately 10KB (under normal circumstances, before accounting for http specific encoding) would be likely to exceed the IIS header size limit of 16KB.
• The user’s Kerberos ticket must share the HTTP header space with other header elements. In some cases these other elements may be very large and further reduce the space available for the encoded ticket.
• Kerberos delegation roughly doubles ticket size. As this tool must take a conservative approach it must assume that delegation may be in use at least somewhere in the enterprise and therefore assumes delegation when estimating ticket sizes.
Based on the above factors, the tool estimates a ticket size using delegation and considers an estimated ticket size of 10 KB to be likely to exceed the IIS 16KB limit. Considering the above variability, this threshold should be considered a useful signpost, while acknowledging that individual users and scenarios may encounter problems above or below this threshold.
Also note that in addition to IIS, other software and devices (such as firewalls, intrusion detection systems, 3rd party web servers, etc) may impose limits on HTTP header sizes.
These options can be used in any combination to achieve the desired results
• Reduce group memberships
• Clean up SID History
• Modify IIS settings to increase the allowed HTTP header size.
These are steps that must be taken carefully to avoid unexpected access control or other repercussions.
Strong group creation, ownership, maintenance and lifecycle policies (enforced through identity management processes) are long term keys to managing group sprawl.