Recently I’ve faced quite an interesting problem when some users are unable to authenticate on some domain services due to exceeding the maximum size of the Kerberos ticket. In this article, we’ll show you how to determine the size of a Kerberos ticket for a specific user and increase the buffer to store the token using the MaxTokenSize parameter.
In our case, the problem has shown itself in this way. Some users were unable to access some of the domain services.
- In particular, there has been an error when trying to connect to the RDS farm (“Access denied” error). You may see the following error in the RDS host logs: Event ID:
6
Source:Microsoft-Windows-Security-Kerberos
The Kerberos SSPI package generated an output token of size 21043 bytes, which was too large to fit in the token buffer of size 12000 bytes, provided by process id 4. The output SSPI token being too large is probably the result of the user user@domain being a member of a large number of groups. It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.
- When trying to connect to SQL Server, the following error appeared in the event log:
Event Id:40960
SQL State: HY000, SQL Error Code:0 Cannot generate SSPI context.
- Errors appeared on IIS websites:
Bad Request – Request header too long HTTP Error 400. The size of the request headers is too long.
- Check the following events in Event Viewer:
Event ID:40960
Source:LSA (LsaSrv)
The Security System detected an authentication error for the server XXXXXX. The failure code from authentication protocol Kerberos was “{Buffer Too Small} The buffer is too small to contain the entry. No information has been written to the buffer.(0xc0000023).
- Group Policies are not applied to the user.
While troubleshooting the problem, we noticed that all problem users belonged to a large number of Active Directory security groups (more than 200 including nested groups). Together with SSPI token too large errors, this indicates that the maximum length of the Kerberos ticket used to authenticate the user has been exceeded.
Kerberos Token Size
The size of the Kerberos token depends on the following things:
- The number of Active Directory security groups (including nested groups), a user is a member of (Mail-enabled universal distribution groups are not included in the token);
- Use of SIDHistory;Note. The ticket oversize issue quite often occurs when users migrate between Active Directory domains and the old domain resources are accessed using SIDHistory.
- Type of authentication used (a usual password or a multifactor, like smartcards);
- Whether the account is trusted for delegation.
Kerberos uses a buffer to store the authentication data and transfers its size to the applications using Kerberos. The system parameter MaxTokenSize defines the size of the buffer. The buffer size matters, since some protocols, like RPC or HTTP, use it when allocating a block of memory for authentication. If the size of the user authentication data is larger than the value in MaxTokenSize, the authentication fails. This can explain the authentication errors when accessing IIS, while the file access to the shared network resources is preserved.
By default, the size of the Kerberos buffer (MaxTokenSize) is:
- 12 KB in Windows 7 and Windows Server 2008R2
- Extended to 48 KB in Windows 8 and Windows Server 2012 and later (up to Windows Server 2022 and Windows 11)
Thus, if the user is a member of a large number of groups that do not fit into the MaxTokenSize token buffer, then authentication fails when accessing some resources.
Max Group Membership Limits for Active Directory
There is a hard limit to the number of AD groups a user can be a member of. The limit is 1015 groups (including nested groups). If the number of groups is exceeded, an error appears when the user logs on to Windows. If you add a user to more than 1015 groups, then he will not be able to log into Windows with the error:
During a logon attempt, the user’s security context accumulated too many security IDs.
In this case, an entry will appear in the System event log:
Source: LSA (LsaSrv)
EventID: 6035
During a logon attempt, the user’s security context accumulated too many security IDs. This is a very unusual situation. Remove the user from some global or local groups to reduce the number of security IDs to incorporate into the security context.
You can find out how many groups a user is a member of by using the Get-ADUser cmdlet from the AD PowerShell module.
$user=Get-ADUser jsmith
$token=(Get-ADUser $user -Properties tokengroups).tokengroups
$token.count
Getting Kerberos Token Size with PowerShell Script
Windows doesn’t have a handy built-in tool that allows you to get the Kerberos token size for a specific user. To get the current Kerberos ticket size, you can use the Powershell script CheckMaxTokenSize.ps1 (the script was originally written by Tim Springston and uploaded to the script gallery on TechNet). But now the script is not available there, so I copied it to my GitHub repository (https://github.com/maxbakhub/winposh/blob/main/CheckMaxTokenSize.ps1).
The script allows you to get the current size of the specified user’s token, the number of security groups in which it is included, the number of SIDs stored in the user’s SIDHistory, and whether the account is trusted for delegation.
Download the script file and save it as CheckMaxTokenSize.ps1. Allow unsigned scripts to run in the PowerShell execution policy for the current session:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Go to the directory containing the script:
Cd c:\install\ps
And get the size of the Kerberos ticket for the user jsmith:
.\CheckMaxTokenSize.ps1 -Principals 'jsmith' -OSEmulation $true -Details $true
The script prompts to specify the environment for which the size of the user token has to be calculated. There are three options:
- [1] Gauge Kerberos token size using the Windows 7/Windows Server 2008 R2 and earlier default token size of 12K;
- [4] Gauge Kerberos token size using the Windows 8/Windows Server 2012 default token size of 48K. Note: The &48K setting is optionally configurable for many earlier Windows versions;
- [6] Gauge Kerberos token size using Windows 10 and later.
If you still have legacy Windows Server 2008 R2 and Windows 7 on your network, you need to select option 1 and press Enter. After a while (3-4 minutes), the script will return the following info:
Token Details for user jsmith ********************************** User’s domain is CORP. Total estimated token size is 22648. For access to DCs and delegatable resources the total estimated token delegation size is 45269. Effective MaxTokenSize value is: 12000 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. *Token Details for jsmith* There are 957 groups in the token. There are SIDs in the users SIDHistory. There are 248 SIDs in the users groups SIDHistory attributes. There are 248 total SIDHistories for user and groups user is a member of. 1088 are domain global scope security groups. 37 are domain local security groups. 86 are universal security groups inside of the users domain. 0 are universal security groups outside of the users domain. Group Details included in output file at C:\Windows\temp\TokenSizeDetails.txt SIDHistory details included in output file at C:\Windows\temp\TokenSizeDetails.txt
In this case, jsmith is a member of the 957 domain security groups and has a Kerberos ticket size of 22648, which is almost 2 times larger than the default maximum Kerberos token size in Windows 7 and Windows Server 2008 R.
Thus, to solve the authentication problem, you have to either reduce the user token size or increase the buffer size on all hosts, in which the Kerberos authentication problem shows up.
If possible, try to reduce the size of the user Kerberos token by:
- Reducing the number of groups, the user is a member of;
- Clearing the SID History attribute;
- Disabling the use of Kerberos-constrained delegation in account attributes (significantly reduces the token size).
How to Increase the MaxTokenSize of the Kerberos Ticket?
You can increase the maximum buffer size for the Kerberos token by using the MaxTokenSize registry value.
Microsoft doesn’t recommend setting MaxTokenSize to more than 64 KB. It is recommended to first increase the limit to 48Kb (limit for Windows 8 and Windows Server 2012) and check the operation of the services. To increase the buffer size:
- Open the Registry Editor and go to the reg key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters;
- Create a new DWORD (32-bit) Value parameter with the name MaxTokenSize;
- Specify the necessary value for the maximum buffer size (we specified the decimal value 48000 since the size of the user token does not exceed this value);
- Reboot your computer.
Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters|select maxtokensize
This change should be performed on all hosts that have authentication problems.
You can also set the MaxTokenSize using the maximum Kerberos SSPI context token buffer size Group Policy option. It is located under the following GPO section: Computer Configuration -> Policies -> Administrative Templates -> System -> Kerberos.
By using the Warning for large Kerberos tickets policy, you can write oversized ticket alerts to the Event logs.
After updating Group Policy settings, if Windows detects that the Kerberos ticket threshold size has been exceeded, Event 31 will be logged:
A ticket to the service ldap/"DC Name"/"DomainName" is issued for account "AccountName"@"DomainName". The size of the encrypted part of this ticket is 22648 bytes, which is close or greater than the configured ticket size threshold (12000 bytes). This ticket or any additional tickets issued from this ticket might result in authentication failures if the client or server application allocates SSPI token buffers bounded by a value that is close to the threshold value. The size of the ticket is largely determined by the size of authorization data it carries. The size of authorization data is determined by the groups the account is a member of, the claims data the account is setup for, and the resource groups resolved in the resource domain.
HTTP 400 Bad Request Using Kerberos (Request Header Too Long)
Another Kerberos token oversize issue occurs on Internet Information Services (IIS) Web sites with Kerberos authentication. When using Kerberos authentication in IIS, the user’s security group membership information is stored in the WWW-Authenticate
header. If the user is a member of a large number of security groups, the size of such a header may be exceeded and the user won’t be authenticated.
To solve this problem, you need to increase the values of the following registry parameters in the reg key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
:
- MaxFieldLength – the maximum size of each header (the default header size in IIS is 16 KB, the maximum value is 65536)
- MaxRequestBytes – the maximum size of query string and headers (maximum value 16777216)
It is not recommended to immediately set the maximum available values for these registry parameters. Large header sizes greatly reduce the performance and security of the IIS web server.
It is recommended to start with a value of 32 KB (32000) for each of these parameters. After making the changes, you need to restart the IIS server.
If the problem persists, try gradually increasing the limit size to 48000 bytes.
3/4*64 KB
).
3 comments
[…] https://woshub.com/kerberos-token-size-and-issues-of-its-growth/ […]
i can not download the ps script CheckMaxTokenSize.ps1 from the link.
Who can send it to me ? thanks
I updated the articles and copied the CheckMaxTokenSize.ps1 script to my GitHub repository. Use the link in the article