Who knew, right?
Token bloat, also known as the MaxTokenSize problem, is a Windows security condition which happens when domain administrators put too many security groups or SIDHistory items into a users token. The problem happens when the token needs to be sent across the network. There’s only so much practical room in the token (specifically the PAC or privileged attribute certificate) and so some SIDs might get left out.
The result can lead to unexpected access denied errors for users when trying to access resources (files, folders, web apps, whatever) if the SID for the group which allows them access didn’t make it into the pack.
Picture a suitcase filled to overflowing. You managed to close it but some stuff had to get left out.
Over the years the Microsoft authentication team added some fixes to help reduce the likelihood of this happening or make it more easily detectable when it does. The most notable thing was to make the compression used in the PAC better. Basically allowing you to pack more into the suitcase.
More information on this condition and other methods to combat it can be found here and here.
To help detect these problems easily I wrote a PowerShell script. You can click this link to get it from the TechNet Script Center.
The problem is more likely to occur when users migrated from Active Directory domain to Active Directory domain and the SIDHistory (user’s Security ID or SID) is retained from the prior domain to preserve seamless access to resources for the user.
It is also more likely to happen if users are added to many security groups, and made exponentially worse when those groups are nested into other group memberships.
There are some ways to detect that issue is happening if you have Windows Server 2012 domain controllers (see link mentioned above). If you do not have 2012 DCs then you can use this script to check the token size of the logged on user. This script can also be handy for ruling out sizing issues, gauging how large the current sizes are, and even understanding where the size is coming from: SIDHistory, or groups and if groups then what groups scopes.
This script will query for the items which make up the token and then calculate the token size based on that dynamic result using the formula in KB327825. It will also give you a total of how many SIDs are in the SIDHistory for the user, how many of each group scope the user has, and whether the account is trusted for delegation or not (if it is the token size may be much larger).
The script must be ran in the user context and can only be ran interactively. In other words, you can send it to a user who is calling you about intermittent authorization issues to have them run it and have them send the result message back to you.
Problem detected. The token was too large for consistent authorization. Alter the maximum size per KB http://support.microsoft.com/kb/327825 and consider reducing direct and transitive group memberships.
Checking the token of user 'tspring' in domain NORTHAMERICA.CONTOSO.COM for token sizing issues per Knowledge Base article http://support.microsoft.com/kb/327825.
The computer is Windows 8 and is a client.
There are 167 groups in the token.
16 are domain global scope security groups.
5 are domain local security groups.
42 are universal security groups inside of the users domain.
95 are universal security groups outside of the users domain.
There are 0 SIDs in the users SIDHistory.
The current userAccountControl value is 512.
Token size is 5664 and the user is not trusted for delegation.
Problem not detected.
Hopefully this script helps rule in or rule out token sizing problems in your enterprise environment.