Recently I’ve faced a quite interesting problem when some users are unable to authenticate on some domain services due to the Kerberos token oversize. In this article, we’ll try to consider the peculiarities of building the Kerberos token, how a user can define its size and how to extend the buffer to store it.
In our case, the problem has shown itself in this way. Some users haven’t been able to access some deployed services. In particular, there has been an error when trying to connect to the RDS farm (“Access denied” error).
In the logs of Remote Desktop servers, the error Event Id 6 has been written:
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 event log:
Event Id – 40960
The buffer is too small to contain the entry. No information has been written to the buffer.(0xc0000023).
The check of the rights to access these resources hasn’t shown any issues. During the further inspection, the following dependency has unveiled: all users facing the problem were the members of a lot of Active Directory security groups (over 200, including subgroups). Thus, we have come to a conclusion that the problem occurs due to the oversize of the Kerberos ticket used to authenticate users.
The Kerberos token Size
The size of the Kerberos tocken depends on the following things:
- The number of Active Directory security groups (including subgroups), a user is the member of (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 the 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 to set the memory block 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 network resources is retained.
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
Thus, if a user is the member of a lot of groups, all group descriptions do not fit in 12 KB, and when trying to access some resources, the authentication error appears.
How to Get the Current Size of the Kerberos Ticket
Windows doesn’t have the convenient built-in tools that allow to get the Kerberos token size for a certain user.
To know the current ticket size, use a third-party Powershell script CheckMaxTokenSize.ps1 (by Tim Springston — Microsoft). This script allows to get the current size of the token for a chosen user, the number of security groups in which it is included, the number of SIDs stored in user SIDHistory, and whether the account is trusted for delegation.
To use this script, download it following the link above and save as CheckMaxTokenSize.ps1
Disable script check:
Set-ExecutionPolicy RemoteSigned |
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 two variants:
1 — for Windows 7 / Windows Server 2008 R2 or earlier (token size 12 KB)
4 — for Windows 8 / Windows Server 2012 or later (token size 48 KB)
Press 1, and then ENTER. In some time (3-4 minutes) the script will return the following information:
**********************************
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
So we have defined that the user jsmith is the member of 957 domain secirity groups, and the size of his Kerberos ticket is 22648, which is almost 2 times more than the standard Kerberos Token Size in Windows 7 / Windows Server 2008 R.
Thus, to solve the authentication problem, you have to either reduce the user token size, or to extend the buffer size in all server systems, in which the Kerberos authentication problem shows up.
How to Reduce the User Kerberos Token
If possible, try to reduce the size of the user Kerberos token by:
- Reducing the number of groups the user is a member of.Tip. This can be done using a new mechanism of controlling access to file resources that appeared in Windows Server 2012 — Dynamic Access Control
- Clearing of SID History
- Refusing to trust accounts for delegation (considerably reduces the token size)
How to Increase the Size of the Kerberos Token
If you cannot reduce the size of the user Kerberos ticket, you can increase the buffer size for it. To do it, there is a special registry setting — MaxTokenSize.
Microsoft doesn’t recommend to set MaxTokenSize to more than 64 KB. In the general case, it is recommended to extend the limit to 48 KB (the limit for Windows 8/2012). To incrase the buffer:
- Open the Registry Editor and go to 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 have specified 48,000, since the size of user tokens do not exceed this value)
- Restart your system.
This has to be done in all server systems, in which the authentication problems occur.
If the authentication issues appear in the IIS sites, you will also need to extend the size of HTTP header to 64 KB (0000ffff). By default, the maximum header size is 16 KB. To do it, you have to make the following changes to the registry on IIS servers (restart is also needed):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength
DWORD:0000ffff
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes
DWORD:0000ffff
In Windows 8 and Windows Server 2012 a new policy has appeared which allows to set the maximum MaxTokenSize — Set maximum Kerberos SSPI context token buffer size. It is located in Computer Configuration -> Policies -> Administrative Templates -> System -> Kerberos.
Besides, there is another useful policy Warning for large Kerberos tickets that allows to configure displaying notifications of the ticket oversize in the system log.
After the policy is enabled, when the threshold size of the ticket is exceeded, the Event 31 will be written to the log with the following text message:
The size of 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 member of, the claims data the account is setup for, and the resource groups resolved in the resource domain.
1 comment
[…] http://woshub.com/kerberos-token-size-and-issues-of-its-growth/ […]