Q: What improvements has Microsoft made in Windows 8 and Windows Server 2012 to reduce the number of Kerberos authentication errors due to token bloat and too-large Kerberos tickets?

A: Starting with Windows 2000, Kerberos is the default Windows authentication protocol. Microsoft extended the base Kerberos protocol to enable a Kerberos authentication ticket to include authorization data. A Windows Kerberos ticket and ticket-granting ticket (TGT) both contain a special field called the Privilege Attribute Certificate (PAC), which enables Kerberos to transport authorization data, such as user group memberships, in the Kerberos authentication tickets. There are some architectural limitations in Windows related to the PAC, which can make user authentication fail under certain conditions. These limitations are commonly referred to as the token bloat problem.

The first limitation relates to the size of the PAC field, which is finite. As a consequence, the number of groups that can be added to it is also limited. The limit for user group memberships is about 1,015. This number is because the PAC can hold only 1,024 SIDs, and we also must subtract from this number a varying number of well-known groups that the Windows Local Security Authority (LSA) automatically adds to each access token. The access token is the most important Windows authorization artifact that the Windows LSA constructs from a user's domain authorization data in the Kerberos PAC and the local user authorization data in a machine's local security database. See the Microsoft article "Users who are members of more than 1,015 groups may fail logon authentication" for more information about this limitation.

But the practical group membership limit is in some cases even lower: You can get Kerberos authentication problems with about 130 group memberships. Besides the hard-coded 1,024 PAC group membership limit, there's also another limit that makes Kerberos authentication fail across certain communication protocols when the PAC becomes too big.

This second limitation is rooted in some architectural and design limits that are part of Kerberos and communication protocols such as HTTP. The Windows Kerberos implementation uses a buffer to store the authorization information that's transported in the PAC, and it also reports the size of this buffer to protocols that use the Kerberos protocol for authentication. The HTTP protocol, for example, uses this buffer size when it allocates memory for authentication. Therefore, if the size of the authorization data for an authenticating user is larger than the MaxTokenSize, then the authentication across an HTTP connection will fail.

The size of the authorization buffer is determined by the MaxTokenSize registry key that's located in HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters. The default buffer size in Windows 7 and Windows Server 2008 R2 is 12k. In Windows 8 and Windows Server 2012, the default MaxTokenSize value has been increased to 48k.

You can obviously adjust the MaxTokenSize to accommodate more groups, but knowing what value to set it to isn't an easy exercise. Microsoft provides the tokensz.exe tool to help you with this process; you can get this tool and more info from the Microsoft Download Center: Tokensz. Also, the MaxTokenSize value has an upper limit. The maximum allowed value of MaxTokenSize is 65,535 bytes. However, because of the way the HTTP protocol encodes authentication context tokens, Microsoft recommends that you don't set the MaxTokenSize registry entry to a value larger than 48,000 bytes.

To make it easier for administrators to configure the MaxTokenSize parameter and to reduce the number of authentication errors caused by token bloat, Windows 8 and Windows Server 2012 include some important changes.

Windows 8 and Windows Server 2012 come with two new Group Policy Object (GPO) settings that are related to MaxTokenSize. The first GPO setting makes it easier to set and enforce the MaxTokenSize registry value using GPOs. It's called Set maximum Kerberos SSPI context token buffer size and is located in the Computer ConfigurationAdministrative TemplatesSystemKerberos GPO container; Figure 1 shows the GPO options. See the Microsoft article "How to use Group Policy to add the MaxTokenSize registry entry to multiple computers" for a summary of how to enforce MaxTokenSize values on different Windows versions.

Figure 1: Setting options for the new Set maximum Kerberos SSPI context token buffer size GPO (Click image for larger view)

The second setting is called Warning events for large Kerberos tickets and is located in the Computer ConfigurationAdministrative TemplatesSystemKDC GPO container; Figure 2 shows the options for this GPO. When you enable this GPO setting, you must enter a Kerberos ticket threshold size. This setting lets you configure at what threshold size Kerberos tickets will trigger a ticket-size warning event (with Event ID 31, a new Event ID for Windows Server 2012 and Windows 8) in the Windows System event log.

Figure 2: Setting options for the new Warning events for large Kerberos tickets GPO (Click image for larger view)

You can use this setting to determine the exact value you should set for the MaxTokenSize key in your Active Directory (AD) environment. Before, you were forced to use the relatively complex tokensz.exe tool to determine an optimal MaxTokenSize value. If you disable or don't configure this setting, the threshold value for sending warning events defaults to 12,000 bytes, which is the default MaxTokenSize value on Windows 7, Windows Server 2008 R2, and earlier Windows versions.

Finally, in Windows Server 2012, the Kerberos Key Distribution Center (KDC) service that runs on every domain controller (DC) also optimizes the storage of group SIDs in the PAC in order to further reduce the PAC size and reduce the number of Kerberos authentication errors. This feature is called KDC Resource Group Compression. To compress resource group SIDs, the KDC stores the SID of the resource domain to which the resource group belongs only once. Then, it inserts only the Relative Identifier (RID) portion of each resource group SID into the authorization data.

Because some third-party Kerberos implementations don't understand KDC Resource Group Compression and this could cause interoperability problems, you can disable the feature on the level of your Windows Server 2012 DCs. To do so, you must set the DisableResourceGroupsFields registry key in the HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemKdcParameters container to value 1. More information about all these Kerberos-related changes can also be found in the Microsoft TechNet article "What's New in Kerberos Authentication."