This error occurs when the user's access token exceeds 1015 entries, and at which point the user is blocked from logging on with the above error. The user’s access token contains an entry for each group the user is a member of, either directly or through nested groups. On top of the entries that are added by group membership, a number of additional entries are added by the system.
There are a number of reasons that can cause this issue, the two most common are nested groups and migration or more specifically the use of SID History.
A complex nested group configuration can cause the number of groups assigned to the increase very quickly. Due to the nesting, the user could only be a member of handful of groups but due to the nesting the actual number of SIDs in the user’s access token can exceed 1015 entries.
The other common cause of this issue is a domain migration using SID History, when SID History is used the user’s access token can double in size, so a user who’s access token contains only 600 groups before migration, it can exceed the 1015 limit post migration, preventing the user from logging on.
The Token Size option in NetTools allows you to scan domain and report the number of SIDs in the user’s access token. See Token Size. This report can be tailored to report on specific objects, i.e. trying to find groups that have a high number of nested groups.
The screenshot below shows that Aaron's access token has exceed the 1015 limit and will not be able to log on. While Abby has only 1006 SID in her access token, and it will depend on the number of additional SIDs that are added to her access token by the workstation when she logs on, which will determine if she will see the error or not.
Bree from the screenshot above, is shown as having 405 SIDs in her access token, looking at the memberof details of her account it shows that she is only a member of 4 groups, nearly all the SIDs are coming from nested groups.
If we use the Display SID Inheritance option from the context menu on her account in the list, we can see the high SID count is a result of Group4 and Group5, both of which have 200 nested groups. Obviously this is a test environment and in a production environment the number of groups and their distribution will be different, but from the Token Size List dialog we can see which groups are causing the problem, we can also drill down further by double clicking on an entry in the list, which will display the SID Inheritance for that item, in this case Group5.
Another method to see the nested group membership for a user is to use the Group Inheritance option, The simplest way to access this option is to use the Resolver window. For the selected object in the list, select the Add to Resolver from the content menu, this will display the Resolver window and add the user we are interested in.
Once added to the Resolver window select Use With -> Group Inheritance ->MemberOf from the context menu
This will display the nested groups details in a tree view to allow you to see visually the nested group membership.
So this has shown you how you can identify which groups have caused the problem, but unfortunately there is no magic fix, in the case of nested groups, you will just need to reduce the number of groups in the user access token, this could be as simple as removing some of the groups that are no longer needed or could require a complete redesign of your groups and resource allocation.
In the case of SID history causing the token bloat, the only way to resolve this one is to remove the SID History from the domain, and manage the resulting cleanup, as SID History normally still exists post migration because someone was too scared to remove it.