Kerberos Token And Max Token Size ? Group Membership limits
As part of the Authentication Service Exchange, Windows builds a token to represent the user for purposes of authorization. This token (also called an authorization context) includes the security identifiers (SID) of the user, and the SIDs of all of the groups that the user belongs to. It also includes any SIDs that are stored in the user account's sIDHistory attribute. Kerberos stores this token in the Privilege Attribute Certificate (PAC) data structure in the Kerberos Ticket-Getting Ticket (TGT). Starting with Windows Server 2012, Kerberos also stores the token in the Active Directory Claims information (Dynamic Access Control) data structure in the Kerberos ticket. If the user is a member of a large number of groups, and if there are many claims for the user or the device that is being used, these fields can occupy lots of spaces in the ticket.
Kerberos Token and Max Token Size – Group membership limits
The token has a fixed maximum size (MaxTokenSize). Transport protocols such as remote procedure call (RPC) and HTTP rely on the MaxTokenSize value when they allocate buffers for authentication operations. MaxTokenSize has the following default value, depending on the version of Windows that builds the token:
In Windows Server 2012 (and later versions), Windows can log an event (Event ID 31) if the token size passes a certain threshold. To enable this behavior, you have to configure the Group Policy setting Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets.
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 clearly indicates that the maximum length of the Kerberos ticket used to authenticate user has been exceeded.
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.
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.
The Set maximum Kerberos SSPI context token buffer size policy setting is added in Windows Server 2012 and in Windows 8. The policy setting is supported in Windows XP, in Windows Server 2003, in Windows Vista, in Windows Server 2008, in Windows 7, and in Windows Server 2008 R2. To use this Group Policy setting, you must edit the GPO in a version of Windows Server 2012 or in Windows 8 that has the RSAT tools installed.
About token size. In my environment I have a user which has about 1000 groups, and he is not able to log in, but when I counted token size it is way lower than 64kB (64kB is a size set for all machines). I understand that number of groups is preventing user to log in, but what for is kerberos token size, if despite increaing it's limit we are still limited to have like 1000 AD groups?
I believe it is this way: The size (in kb) it takes to store a list of your 1000+ AD group memberships varies according to the size of your group names. Before WS2012, you risked hitting the 12k size limit of the Access Token before reaching the 1024 number-of-elements-in-an-array-limit of the array-property holding the list of groups. This could be the case if you had very long group names.So to fix that, MaxTokenSize was increased from 12k to 48k. That made sure you had enough space (in kb) in your token to store the list (array) of group names, without hitting the token size limit. However, the array representing that list, is still hard coded to have a maximum size of 1024 elements or something, of which 1015 of them are available to your own groups (I believe 9-or-something slots in the array are defaults you cannot change).
It is indeed possible to change the maximum token size via the registry. However, it makes no sense to do this when the token size is 48 kb (which is the current default setting), because this allows more than 1,015 groups to be stored (assuming that not only non-domain, universal groups are being used)
Limiting the search to only Groups is a method to determine if there are any groups which have a high number of nested groups, which could impact the size of a user's access token if users are added to the group.
The right click context menu provides a number of options to investigate the token size further, the Display SID Inheritance option allows you to drill down into the access token to see which items are potentially causing the token bloat. The Token Size displayed in the Inheritance dialog does include the 1200 byte overhead and is based on the formula 40d + 8s.
Background: Windows uses a static buffer to hold the user's access token, the size of this buffer varies in size depending on the versions of Windows, see: While you can increase the size of the access token supported by the OS, there is no method to increase the maximum size supported by IIS prior to version 6. A user who is a member of 100+ groups they may experience intermittent access to resources hosted in IIS, over 300 they will have IIS\Sharepoint issues, over 1015 and the user will not be able to logon. The use of SID History for migration or consolidations only makes the access token size issue worse. This is quite a good white paper on the issue -access-token-limitations/104962
summary_noimg = 800;summary_img = 650;img_thumb_height = 48;img_thumb_width = 48; //=1) imgtag = '';summ = summary_img;var summary = imgtag + '' + removeHtmlTag(div.innerHTML,summ) + '';div.innerHTML = summary;}//]]>Token Bloat occurs when you are a member of too many groups in Active Directory. At somewhere around 125 groups, your Kerberos token size reaches 64kb in size. That's the limit for a lot of things that use Kerberos authentication. For example, if you've got VMware ESX/ESXi 4.x, and you've configured it to use Active Directory authentication, you may find that you can't log onto the vSphere client. You may not be able to connect to Kerberos-enabled IIS web sites. You may not be able to join a computer to a Windows 2003 domain.That's an extreme result of token bloat. Whether or not you've reached this limit, the more groups you have, the more data you're transferring to every Kerberos-enabled server or service that you connect to all day long. Being a member of too many groups is just bad for performance if not the direct cause for failures in accessing services on the network.You may think, "who is in 125 groups?!", well I'm in 320, and I saw a user recently who was in over 500. In a large environment, things can get out of hand quickly if the wrong people are setting the standards.Resource-Based GroupsComplex User-Admin - High Token BloatIn my opinion, there are two fundamental types of groups: groups that are associated with a resource, and groups that are associated with a role. Resource groups are created specifically for a resource, that is, a file share, a folder, an application, a server, or a printer to name a few. This is the type of group that many administrators tend to create a lot of, and they eventually lead to token bloat (if your environment is large enough). Think about it, every time you create a file share or a secure folder, you probably create a group for that folder, perhaps more than one (one for read/write access, and another for read-only access). You may create a group for administrators of a given server, to give the application owners admin access to their server. These seem like a good idea, until you have hundreds of shared folders and thousands of servers. Before you know it, you've been added to hundreds of groups to grant you access to all the stuff you need access to, and they guy next to you that does the same job, they've added him to all those groups too.From the perspective of your IT organization, you probably have user admin personnel who's job is to create users and add them to groups. If you're a smaller company, these same people probably grant those groups access to shares and folders. If you're a larger company, you may have a separate team who sets the permissions on the folders. Perhaps the server guys do that part. In that case, your user admin team may be made up of lesser-skilled people while your server crew is more highly skilled. Yet, with resource-based groups, you're leaving it up to your lesser-skilled people to map users to the myriad groups you've set up. The user to role mapping work is left in the hands of your lesser-skilled crew. Role-Based GroupsComplex Resource-Admin - Less Token BloatBy contrast, with role-based groups, you create a much smaller number of groups, per organizational role. Let's say you create a group called HR Managers. You then grant this group the appropriate rights to every share, folder and application that they need access to. Then, when user admin sets up a new HR manager, they add the new user to the HR Managers group, and their done. The low-skilled user admin job becomes easy. What's difficult in this scenario is that this one group must be granted access to many resources. This requires a lot of work and skill, and presumably your skilled people who understand permissions and server are responsible for this work.There is of course, a drawback to this design. If multiple roles need access to the same resource, you need to add all of the role-based groups to the access control list (ACL) of that resource. This can lead to some lengthy and complicated ACLs. This in itself is not good for performance.So, a less extreme version of the single role model is advisable. The reality is that users have more than one role. The user may be an HR Manager (giving them privileged access to folders and applications containing sensitive payroll information), but they are also an HR Team member giving them access to additional, less sensitive HR information, and they are also a member of US Employees, giving them access to various folders and applications related to US data and services, and so on. Each role-based group created for the purpose of granting access to a number of resources closely related to that role.In this less extreme model, the user has a number of roles, each mapped to a number of resources. In this scenario, the number of groups that the user belongs to is kept to a reasonable few, while the number of groups added to the ACL of each resource is also kept to a reasonable few. You may end up creating roles that grant access to only one resource, but your should loath to do it.Each role-based group should ideally grant access to data and applications that are largely specific to that role (e.g. HR data and apps for HR users, US data and apps for US users). In this way, you end up with a good balance of the fewest number of groups and the fewest entries in the ACLs. Many I wish they did this where I work.Page 2 >