Microsoft have stated for numerous years that anyone with Kerberos authentication issues often due to users being in multiple groups and commonly known as Token Bloat should increase the MaxTokenSize to 65535 bytes.
Whilst reading Understand and Troubleshoot Dynamic Access Control in Windows Server 2012 guide, I read that
“Previous versions of Windows had a default maximize token size of 12k. However, this value remained too low for many environments and required reconfiguring each computer in the enterprise. Windows Server 2012 and Windows 8 increase the default maximum token size to 48k. This new value is the maximum viable size for SSPI tokens in Windows and may require additional settings changes for applications to support. For example, HTTP settings are required for SSPI tokens over 12K.”
But this article How to use Group Policy to add the MaxTokenSize registry entry to multiple computers also stated the 48K maximum and with a similar reasoning.
“The maximum allowed value of MaxTokenSize is 65535 bytes. However, because of HTTP’s base64 encoding of authentication context tokens, we do not recommend that you set the maxTokenSize registry entry to a value larger than 48000 bytes. Starting with Windows Server 2012, the default value of the MaxTokenSize registry entry is 48000 bytes”.
This lead me to do a little further research as Microsoft stated in the article Active Directory Maximum Limits – Scalability that the “maximum recommended size for a Kerberos ticket is 65,535 bytes”
Getting nowhere fast, I had an email exchange with the Active Directory Documentation team, it was confirmed that this value should now be set to 48K
The Active Directory Maximum Limits – Scalability website should be updated soon (approx. 09/05/2013) to confirm this.
The question now to ask though is – I have set the MaxTokenSIze to 65535 bytes, should I now change it to 48000 bytes?
So I asked the question:-
“What happens to people who have set the key to 65535? Should they test and change it to 48000 now? Will Windows Server 2012 break? Will things fail as a result of having it set to the maximum?”
Kerberos itself doesn’t really understand the concept of a token size because what it transports is opaque to the protocol.
Applications, however, are different and can implement their own constraints such as buffer size. Applications ask SSPI (Kerberos) for the size of the authorization buffer of the authenticating user. If the size reported back is greater than the buffer allocated by the application, authentication fails. The size reported back is the actual size not the maximum size. Therefore, with MaxToken set to 65k and authorization data amounting to 12k; Windows will only report back 12k. MaxTokenSize simply limits the maximum value the SSPI can return to an application. Prior to Windows 8/2012 , most environments would set MaxTokenSize to the maximum because it was nearly impossible to determine a user’s true token size. Therefore, if you set it to the max, and still had an authentication problem it was not because of MaxTokenSize ( at which point engineers would instruct customers to return the setting to the prior value).
With MaxTokenSize defaulting to the max Authentication buffer size for IIS; there shouldn’t be a authentication problem resulting from token size. Http caps out at 48k. Making it higher won’t fix the authentication issue. So it there is no gain people nothing by increasing it.
While the setting in the documentation should mostly be harmless; we should suggest 48k as the ideal setting for MaxTokenSize and point to the Group Policy setting in Windows Server 2012/Windows 8 as the means which to modify it.
and now we know.