Kerberos MaxTokenSize and Security Groups

Security groups are also security principals, and therefore are uniquely identified by SIDs. A user security principal can be a member of multiple security groups. Consequently, a user’s access token includes SIDs of all groups to which the user is a member. This is a good read and explanation on your query.

The token evaluation process evaluates groups’ recursively. For example, if User A is a member of Group 1 and Group 1 is a member of Group 2, then a token generated for User A contains SIDs representing both Group 1 and Group 2. In native mode and higher domains, universal, global, and domain local groups are all evaluated recursively. Universal security groups do not exist in mixed mode domains.....

Since group membership is evaluated recursively, if a user is transitively a member of a group that is nested at 50 levels, that user is also a member of every other group in that hierarchy. The user is also a member of any groups that those groups are members of.

http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx

For info, the nested group is mentioned and included in the count as well based on the MS KB on the token size calculation. e.g. TokenSize = 1200 + 40d + 8s

This formula uses the following values:
•d: The number of domain local groups a user is a member of plus the number of universal groups outside the user's account domain that the user is a member of plus the number of groups represented in security ID (SID) history.
•s: The number of security global groups that a user is a member of plus the number of universal groups in a user's account domain that the user is a member of.
•1200: The estimated value for ticket overhead. This value can vary, depending on factors such as DNS domain name length, client name, and other factors.

As a whole, the problem as MS advised below on possible condition for such issue. Referring to (b), it again stated the nested group included in calculation. MS has a script for calculation and testing if you are keen to test out.
a) when users migrated from AD to AD domain and the SIDHistory (user’s Security ID or SID) is retained from the prior domain to preserve seamless access to resources for the user.
b) if users are added to many security groups, and made exponentially worse when those groups are nested into other group memberships.

KB issue (calculation) - https://support.microsoft.com/en-us/kb/327825
definition of various groups - https://technet.microsoft.com/en-us/library/cc755692(WS.10).aspx
script - https://gallery.technet.microsoft.com/scriptcenter/Check-for-MaxTokenSize-520e51e5

"For example, if User A is a member of Group 1 and Group 1 is a member of Group 2, then a token generated for User A contains SIDs representing both Group 1 and Group 2."

Keep in mind my question is about the hard limit of 1015 tokens, not MaxTokenSize.

So, in the above example, it said "a token", meaning one token, "generated for User A contains SIDs representing both Group 1 and Group 2".  So, one token to represent all nested groups within that group?  That would work for me.

Noted I understand the token count as SID count. https://support.microsoft.com/en-gb/kb/328889
My understanding is also that nested group had each of unique SID hence it is counted as nit as one but the no of nested group inclusively.

When a user logs on to a Windows 2000 domain, the operating system generates an access token. This access token is used to determine which resources the user may access. The user access token includes the following data:
User SID.
SIDs of all global and universal security groups that the user is a member of.
SIDs of all nested global and universal security groups.

Every process executed on behalf of this user has a copy of this access token.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms676928%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

That's a bummer.  My firm has many clients and we base our access on who may access which client folders and which service folders within each.  These folders have security groups assigned to them.  Thus, when an employee is assigned to a certain task for a certain client, that employee is auto-assigned to the appropriate SG through automation and, thus, gains access.  This is done this way so that we don't have to keep modifying folders multiple times per day to reassign permissions to multiple employees throughout the day.  Worse, the changes to the folders causes backup to think everything needs to be backed up.  Not so when using SGs.  Now, some employees have access to many folders and may soon exceed the SG count.  So, what to do here if I can only use up to 1015 tokens?

understand the challenge that you faced. Actually if the user do hit the hard limit no of groups, I believe the token size limit may kicked in first rather than the hard limit group no. May be worth to already identify those potential user (target the VIP and key mgmt. accounts and privileged users) whom going to face this limits..

There is a hard limit to the number of AD groups a user can be a member of. This limit is 1015 groups. If there are more groups, the following error occurs when a user logs on: The system cannot log you on due to the following error: During a logon attempt, the user’s security context accumulated too many security IDs. Please try again or consult your system administrator

there is PS script to do that
http://woshub.com/kerberos-token-size-and-issues-of-its-growth/#!prettyPhoto
http://www.jhouseconsulting.com/2013/12/20/script-to-create-a-kerberos-token-size-report-1041

There is product ("Kerberos Token Size Calculator") from Golden Finger designed to  calculate the Kerberos token size of multiple Active Directory accounts  http://www.paramountdefenses.com/kerberos-token-size-calculator.html

Other than the assessment to identify such users in the domain, besides review how bets not to overlap the SG that will be good but looks like the automation piece may also need to review..am thinking if the SG will be removed or use of claimed based authentication...

•Dynamic Access Control adds Active Directory Claims to the Ticket. Therefore, calculating the expected ticket sizes is no longer straightforward. The expectation is that tickets that are issued by Windows Server 2012 domain controllers are smaller than the same tickets that are issued from older operating system versions. Claims add to the ticket size. However, after Windows Server 2012 file servers are using claims broadly, you can expect to phase out a significant number of your groups that control file access to trim ticket sizes.

https://support.microsoft.com/en-us/kb/327825

OK, so what is the alternative if we need to manage more than 1015 security groups?

I do not think there is a straight answer as a stop gap but need to address from the review of creating those groups. Role based approach may be considered. Here is one good sharing in striking that balance

http://www.itadmintools.com/2011/09/avoiding-token-bloat-in-your-active.html

..but the nested group has no good solution though..http://www.itadmintools.com/2011/09/avoiding-token-bloat-in-your-active_30.html

Role-based approach isn't going to work for my scenario.  I guess there is no real Microsoft Windows solution for this scenario.  I'll have to re-think how to handle users needing the largest amount of clients at once, which changes dynamically throughout the day.  Thanks!

Accepted as closing comment since there is no Microsoft-based solution to meet the need of massive amount of security groups.

Thanks for sharing