MaxTokenSize Problem: The Reasons Behind the Error

The size limit for Kerberos tokens can lead to entries being cut off and users not receiving all intended permissions. Learn more about this error.


This problem (also referred to as “token bloat”) occurs when the client’s Kerberos ticket (generated during Kerberos authentication during Windows logon) is too big. More specifically, the problem occurs when the maximum size of the PAC (Privilege Account Certificate, an extension of the “Authorization Data” field in Kerberos) is exceeded.

Here, Windows stores information on security identifiers (see also: SID) and users’ group memberships. Each group requires either 8 bytes or 40 bytes of storage in the PAC.

Attention: Note that nested groups will be flattened. If user X is a member of group A, and this group is a member of group B, information about both groups A and B will be stored in the PAC.


Exceeding the size limit will lead to not all groups being represented and therefore not included in the PAC. The effects are noticeable in several places:

  • File access does not work, despite users having relevant privileges
  • Single sign-on to web applications does not work properly
  • Group policies for users are not being applied

Structure and Calculation

The maximum token size depends on the operating system that is being used:

  • Windows 2000: 8.000 bytes
  • Windows Server 2003 and later: 12.000 bytes
  • Windows Server 2012 and later: 48.000 bytes

The token size for an individual user depends on his/her number of group memberships (and the group types) and can roughly be calculated as follows: Size = 1500 + (40 * a) + (8 * b)

  • The estimated overhead is 1500 bytes and depends on factors such as the DNS name of the domain.
  • a – stands for the number of entries in the SID history (for users and groups) as well as the number of flatted memberships in universal groups outside the user’s domain.
  • b – stands for the number of flattened memberships in universal groups within the user’s domain, as well as flattened memberships in global and domain-local groups.

Attention: For Windows Server 2008 R2 or earlier, domain-local groups are calculated with 40 instead of 8 bytes.
Please also note the following:

  • If the option “Trusted for Delegation” is activated for the user, you must calculate twice the demand for all data, except for the overhead.
  • In Windows Server 2012 and later it is possible to reduce the required size by using the feature “KDC Resource SID Compression“, which compresses the SIDs in the PAC and thus allows several entries to be stored.

Further Issues

It is indeed possible to change the maximum token size via the registry. However, it makes no sense to do this when the token size is 48 kb (which is the current default setting), because this allows more than 1,015 groups to be stored (assuming that not only non-domain, universal groups are being used)

The reason for this is that a security principal (i.e. a computer, a group or a user) can be a member of 1,015 groups max. This is Windows Server’s internal limit, which is independent of the Kerberos token size. It is not practical to increase the token size to more than 1,015 groups due to the limit of the maximum group size.


Best Practices for Access Management In Microsoft® Environments

An in-depth manual on how to set up access structures correctly, including technical details. Also includes information on reporting and tips for implementation.

About the Author: Helmut Semmelmayer

Helmut Semmelmayer currently heads channel sales at the software company tenfold software. He looks back on 10 years of involvement in the identity and access management market. Having worked on countless customer projects, he has extensive knowledge of the challenges that organizations face when it comes to protecting data from unauthorized access. His goal is to educate businesses and build awareness for current and future access-based attack patterns.