Kerberos Token Bloat MaxTokenSize: Fix Group Sprawl Safely

What Is Kerberos Token Bloat?

Kerberos token bloat MaxTokenSize troubleshooting starts with a distinction: the number of people in a group is different from the number of group SIDs carried for one person. Group sprawl can become an authentication availability problem, but a large group finding alone cannot diagnose it. A useful investigation connects the affected identity, the service that fails, the authorization context and the limits along that service's authentication path.

An emergency cleanup introduces a second problem. Removing memberships until an application works again changes access without establishing which permissions or restrictions were removed. Some removals reduce unnecessary privileges; others interrupt required work. A removal can also weaken a control if the membership supplied a restriction. The security outcome depends on the actual role of the group, not on whether the membership list became shorter.

This guide treats circular nesting and modified built-in groups as review signals alongside that investigation. It does not present an observed outage or a measured security incident. The objective is a repair that restores the affected workflow while preserving approved access and approved denials.

How It Works: PAC, MaxTokenSize and Separate Limits

The Kerberos TGT carries authorization data in its Privilege Attribute Certificate (PAC): user, group and sIDHistory SIDs. Claims and SID compression also affect space requirements. The resulting bytes matter; a direct member count is a different measurement. Microsoft KB327825 explains this mechanism.

KB837361 documents the MaxTokenSize registry setting:

The known-issues section of KB327825 separately identifies an LSA access-token limit of 1,010 group SIDs, affecting Kerberos or NTLM. Raising MaxTokenSize does not remove this separate limit. KB327825, known issues.

KB938118 gives 65,535 bytes as the maximum allowed value, but recommends against values above 48,000 because HTTP Base64 encoding expands authentication data. Treat the allowed maximum and a suitable operational setting as separate decisions. Increasing a registry value cannot remove every downstream constraint.

Circular nesting is a graph problem

Suppose Group A contains Group B and Group B contains Group A. A custom traversal that revisits nodes without tracking them can loop or count repeated visits. This is an algorithmic consequence, not a claim about observed KDC or PowerShell behavior. Returning to the same group does not create a new unique SID on every visit.

Keep direct group edges when investigating a cycle. A strongly connected component (SCC) identifies a set of groups that can reach each other; the topology helps a reviewer choose the relationship to remove. A cycle finding does not establish that a user's PAC exceeds MaxTokenSize. The cycle and excessive effective memberships may coexist, but they need separate evidence.

Dangerous group nesting in Active Directory explains how hidden inheritance creates a path to Tier 0 and why remediation must identify the group edge granting that privilege. Apply that path review when simplifying memberships, so an availability repair also preserves the intended privilege boundary.

Symptoms by Service and the Emergency Change Scenario

Microsoft documents HTTP 400 with an oversized request header, failed resource access and user Group Policy update problems. Its client/IIS/SQL example makes the participating machines relevant to diagnosis. KB327825 symptoms and resolution.

Use the following table as an investigation plan. These are questions to test, not additional error signatures or evidence that Kerberos fails randomly.

If the same user succeeds on one service and fails on another, preserve both cases. Compare their actual paths before changing groups. The successful case is useful diagnostic evidence, but it does not identify which limit applies to the failing case. Avoid replacing that comparison with a generic claim of intermittent token bloat.

How removing a group can remove a restriction

Consider a conditional example on a Windows 10/11 workstation covered by Microsoft's Deny access to this computer from the network documentation. A dedicated security group carries SeDenyNetworkLogonRight. The setting is located under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Microsoft documents that this Deny takes precedence over the corresponding network-access Allow and that assignment changes apply at the next logon.

Now suppose an operator removes the user from that group solely to reduce memberships. If this was the user's only path to Deny and an Allow remains, the next authorization context loses that restriction. This is a conditional inference from the documented policy behavior, not an incident report. It does not prove that every share or file is now accessible: other ACLs and denials must still be checked. Verify applicability before extending this workstation example to other systems.

Microsoft's security groups documentation explains that groups can carry user rights as well as resource permissions. Before removing an edge or member, record both roles. A group name alone is insufficient to decide whether removal reduces privilege, breaks required access or removes a restriction.

Privileged access drift in Active Directory explains how temporary exceptions without owners, expiry and revalidation can recreate rights through groups and ACLs. Use the same baseline discipline for urgent repairs, especially when a failed workflow prompts a compensating access grant.

Detection: Capture Memberships, Paths and Warning Context

Step 1: Build a record for each affected service

Record the user, client and server versions, service/SPN, effective MaxTokenSize of each participant, group/SID population, sIDHistory, claims or delegation context, exact failure and any relevant warning. Preserve the evidence before editing. Distinguish an observed failure from an estimate, a directory posture finding and a successful retest.

Event ID 31 can warn about a configured large-ticket threshold on Windows Server 2012 and later. Enable it through Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets. It is not proof that MaxTokenSize was exceeded; correlate it with the failing service. KB327825, resolution.

Record the actual warning threshold and whether that policy is enabled. The source passage does not supply a universal numeric threshold. Absence of the warning is not a clearance result for the account.

Step 2: Inventory groups for the principal

The following is Example 2 from Get-ADPrincipalGroupMembership, quoted as a documented command. These commands were not executed against an AD environment for this article; replace the sample identity with a resolved account in your scope.

Get-ADPrincipalGroupMembership -Identity Administrator

The cmdlet requires a global catalog. Microsoft documents ResourceContextServer for searching local groups in another domain. Check the resource context rather than assuming the account's own domain tells the whole service story. The returned group objects support an inventory; they are not a measurement of ticket bytes.

Step 3: Preserve direct edges before flattening results

This direct-membership query uses the documented parameters of Get-ADGroupMember:

Get-ADGroupMember -Identity "Enterprise Admins"

For comparison, Microsoft's Example 4 includes members reached through child groups:

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive

Microsoft describes the recursive output as terminal members of the hierarchy. Preserve direct relationships separately to explain a path or cycle. A flattened output cannot by itself explain which relationship supplies a right. The documentation also identifies a limitation for members in another forest without Active Directory Web Service.

For a targeted transitive SID view, Microsoft documents the computed tokenGroups (Token-Groups attribute), retrieved with a BASE-scope LDAP query on the principal and a global catalog available. It is expensive for domain controllers. Start with affected accounts rather than broad repeated queries. Its SID population is useful evidence, but it still is not a PAC byte counter.

Remediation: Simplify Groups Without Losing Approved Controls

Step 1: Establish the baseline and rollback

Save direct memberships, group edges and the affected accounts' transitive population. Record group owners, resource uses, user rights, approved restrictions, buffer settings and impacted applications. Document the intended change and a rollback before removing memberships. The preceding read-only commands support this inventory; they do not authorize a deletion.

Review built-in groups against a maintained organizational baseline. Microsoft documents legitimate functions for groups such as Event Log Readers even when their default membership is empty. A new member can be intentional. Without a maintained baseline, review the owner's justification rather than treating the addition itself as malicious.

Step 2: Remove unnecessary dependencies and break erroneous cycles

Identify the precise edge creating a cycle or obsolete dependency. Confirm its uses with the owner, remove only the approved relationship and preserve required permissions and denials. Flattening means simplifying the group architecture; it does not mean assigning every user directly on every resource ACL.

Separate business roles from resource groups and give both owners and review dates. Check whether the new design actually reduces unnecessary effective memberships. Reorganizing group names or nesting without reducing the relevant SID population does not establish that the authentication context became smaller.

Step 3: Use MaxTokenSize as a scoped stopgap

If the investigation demonstrates a buffer limit, consider a controlled configuration change alongside structural cleanup. KB938118 documents the policy under Computer Configuration\Policies\Administrative Templates\System\Kerberos, named Set maximum Kerberos SSPI context token buffer size. It specifies enabling the policy and entering 48000. For its registry-preference procedure, choose REG_DWORD and decimal input.

Compare that value with the effective configuration first. Setting 48,000 on a machine already using 48,000 does not increase capacity. Follow the documented restart requirements after application, preserve a rollback and review HTTP constraints. Do not treat 65,535 as the default recommendation or assume a change on the domain controller alone resolves a multi-participant path.

Step 4: Test required access and required denials

Reconnect pilot accounts and retest each affected service. Verify the approved business actions, the restrictions that must remain and any compensating grants introduced during the outage. Compare memberships and direct edges before and after. Reobserve the actual failure and warning context.

A removed size finding or cycle finding is useful posture evidence, but it is not a complete service acceptance test. Close the repair when the affected workflow and the access model both match the documented target. Preserve exceptions with owners and review dates so later changes can be checked against the same baseline.

How EtcSec Detects This

EtcSec's etc-collector provides six relevant directory posture checks. Their exact predicates are shown below. The four size checks count direct members, not token size. None of the six checks counts a user's transitive group SIDs, measures PAC bytes, reads MaxTokenSize or proves an authentication failure.

The suffix CRITICAL corresponds to actual severity High, and HIGH corresponds to actual severity Medium. These direct-member thresholds are collector policies, not Microsoft authentication limits. The size predicates have no explicit security-versus-distribution group filter.

Their populations overlap: GROUP_EXCESSIVE_MEMBERS covers both the 101–500 and >500 populations; OVERSIZED_GROUP_HIGH is a subset of OVERSIZED_GROUP. Do not sum their counts as distinct groups or describe four independently proven token-bloat risks. Displaying only the five largest groups in excessive-member details does not limit the total finding count.

The circular check counts involved groups, not cycles or failed users. Its graph retains only known collected groups and normalizes distinguished names. A cycle passing through an uncollected domain can be missed. The result locates relationships to review, not the cause of a Kerberos failure.

What the built-in baseline actually means

BUILTIN_MODIFIED uses exact English sAMAccountName lookups. Its nonempty lists accept Administrator, Domain Admins and Enterprise Admins for Administrators; Domain Users, Authenticated Users and INTERACTIVE for Users; and Guest and Domain Guests for Guests.

Its nine empty lists cover Remote Desktop Users, Network Configuration Operators, Performance Monitor Users, Performance Log Users, Distributed COM Users, IIS_IUSRS, Cryptographic Operators, Event Log Readers and Certificate Service DCOM Access. An extracted CN in one of these groups can trigger even when the addition supports legitimate work.

The comparison accepts a case-insensitive equality or substring match against an expected name. It skips member DNs without an extracted CN and does not verify the group's SID or container. Localized names, renaming, homonymous groups and CNs containing an expected name limit interpretation. It does not detect missing expected members, inspect ACL changes or compare an organization's change history.

Use this finding to request an owner, justification and local baseline comparison. The correct response is a reviewed membership decision, not an automatic purge. Combine all six findings with the service evidence collected above to decide what to change and how to validate it.