HTTP error 400 request header is too long – MaxTokenSize

How to resolve the HTTP 400 error when request headers are too long? As a common authentication protocol, Kerberos plays a central role in user authentication and securing IT infrastructures. However, authentication issues can arise when users belong to too many security groups. In this article, we discuss the challenges of Kerberos authentication and how they can be addressed by setting MaxTokenSize.

HTTP 400 Error: Problem Description

A user who is a member of multiple security groups may encounter various issues during authentication. A common issue occurs when the size of the headers in authentication requests exceeds a certain limit, leading to the error “HTTP 400 – Bad Request (Request Header Too Long).” This prevents the user from accessing various resources and results in constant error messages when attempting to access certain applications or data. Additionally, the user’s Group Policy settings may not be correctly updated, meaning security policies and access permissions are not properly applied.

Cause

Kerberos is unable to authenticate the user’s identity because it cannot create a ticket that includes all of the user’s group memberships. Windows creates a token for authorization purposes that contains Security Identifiers (SIDs), group SIDs, and all SIDs stored in the user’s sIDHistory attribute. Kerberos stores this token in the Privilege Attribute Certificate (PAC) data structure within the Ticket Granting Ticket (TGT). In Windows Server 2012 and later versions, the token is also stored in the Active Directory Claims data structure within the Kerberos key. When a user has many group memberships and demands, this information occupies significant space in the ticket.

Contact Our Team

Solution Approach

The solution consists of two parts. First, calculate how large the token is and why. From this, you can determine the cause of the size. The actual solution should depend on whether it is a general or individual problem. More on this in the section: “Further Measures and Recommendations.” We recommend a token analysis and based on that, the implementation of specific measures.

Kerberos Token Analysis and Token Calculation

There are several ways to solve this problem. The most obvious solution is to calculate the TokenSize. To calculate the TokenSize, use the following formula:

Token-Size = 1200 + 40d + 8s

For Windows Server 2012 (and later), the components of this formula are defined as follows:

• 1200: Estimated Kerberos overhead. This value may vary depending on the length of the DNS domain name, client name length, etc.
• d: The sum of the following values:
  • The number of the user’s memberships in universal groups outside the account domain.
  • The number of SIDs stored in the sIDHistory attribute of the account (these include group memberships and user SIDs).
• s: The sum of the following values:
  • The number of the user’s memberships in universal groups within the account domain.
  • The number of memberships in domain local groups.
  • The number of memberships in global groups.

Example Calculation

To better understand the calculation, here is a simple example:
Assume a user has the following memberships:

• 5 universal groups outside the account domain (d)
• 3 SIDs in the sIDHistory attribute (d)
• 10 universal groups within the account domain (s)
• 4 domain local groups (s)
• 8 global groups (s)

The values would be:
• d = 5 + 3 = 8
• s = 10 + 4 + 8 = 22
Token-Size = 1200 + 40(8) + 8(22) = 1200 + 320 + 176 = 1696

Critical TokenSize

A TokenSize value is considered critical if it exceeds 12000 bytes. At these levels, authentication problems can occur, particularly HTTP 400 errors due to overly long request headers.

Windows Server 2008 R2 and earlier versions use the same formula. In these versions, the memberships in domain local groups are considered part of the value d rather than the value s.

Detailed Solution Methods

1. Calculating and Optimizing Token Size:
– Calculate the token size to identify users with oversized tokens and optimize their group memberships.
– Remove unnecessary group memberships to reduce the token size.

2. Reviewing Group Memberships:
– Regularly review which groups users belong to and terminate unnecessary memberships.
– Memberships in universal groups should be carefully managed.

3. Using Reporting and Monitoring Tools:
– In large organizations, specialized programs are required to calculate user token sizes and address this issue.
– Our Reporting Service calculates user token size and identifies oversized tokens.
– It is also easy to generate reports on which local, global, and universal groups a user belongs to.

Our Solution: Reporting Service

Our IDM-Portal Reporting Service is specifically designed to effectively identify Kerberos authentication issues. This service calculates the user’s token size, finds oversized tokens, and creates detailed reports on which groups a user belongs to. This allows you to easily track whether a user has more than 120 group memberships. At the same time, you can identify users who exceed the MaxTokenSize value and take necessary actions.

Further Actions and Recommendations

1. Increasing Allowed Kerberos Ticket Size:
– Adjustments in the Windows registry can increase the Kerberos ticket size. However, this should be done carefully, and the impact on system performance should be assessed.

2. Reducing Kerberos Ticket Size:

• If it turns out that the Kerberos token is too large, there are several methods to reduce it:
• Reducing Group Memberships: One of the most effective ways to reduce Kerberos token size is to decrease the number of group memberships. Fewer groups mean a smaller token.
• Using Distributed Security Groups: Instead of adding users directly to many groups, distributed security groups should be used to reduce the number of direct memberships.
• Cleaning up SID History: Removing unnecessary SID histories can also help reduce token size. However, this must be carefully planned and executed to avoid losing necessary permissions.
• Using Kerberos Constrained Delegation (KCD): KCD can help minimize the need for large group memberships by allowing targeted delegation of certain permissions.
• Monitoring and Optimizing Group Policies: Regular reviews and optimizations of group policies can help reduce unnecessary complexity and associated token sizes.

Conclusion: Why Use the IDM-Portal Reporting Service?

Resolving Kerberos authentication issues and optimizing token size are critical for system performance and security. Our Reporting Service offers significant benefits:

Automatic Token Calculation:

The IDM-Portal Reporting Service automatically calculates users’ token sizes and identifies large tokens. This saves time and reduces manual processes.

It generates detailed reports showing users’ group memberships. With these reports, administrators can quickly identify problematic users.

Easy Tracking:

You can easily track how many group memberships users have and whether they exceed the MaxTokenSize value. This allows you to identify and resolve issues proactively.

With the Reporting Service, you can effectively monitor Kerberos tokens and group memberships, minimize authentication issues, and ensure your IT infrastructure is secure and operates smoothly.

Book a Demo

The FirstWare IDM-Portal from FirstAttribute is an integrated solution for Identity and Access Management (IAM) that enables automated management of users and their permissions, whether on-prem or in the cloud.

This portal integrates all aspects of identity and access management, providing centralized access to identity and directory services.