AD Migration: Maximum number of group memberships

After an Active Directory migration project, users might not be able to logon anymore. This article shows solutions how to prevent this problem ahead of time with the use of PowerShell.

When users belong to too many groups, they are unable to log on and receive the following message: “During a logon attempt, the user’s security context accumulated too many security IDs.”

The aim of this article is to answer the following questions:

• What is the highest number of group memberships a user can have?
• What exactly happens during an AD migration if the SID history of the source group is also transferred?
• How do you find out how many group memberships a user already has?
• How to calculate the number of SIDs of a user object?

Maximum number of group memberships

The security token of a Windows Client can hold up to 1024 SIDs. If a user object is member of more groups than allowed, the logon fails. More precisely, the exact limit is set at approximately 1010 groups because some of the storage space is already taken by the so-called “well known SIDs”. For more information on this topic, please check the Microsoft support site here.

Transfer of SIDHistory during an AD migration

During an Active Directory Domain Migration, groups are usually migrated to a new domain. Once the SIDHistory of the source group is transferred as well, a group will then suddenly occupy 2 of the 1010 “SID-Memory Slots” in the security token. If, for example, a user is member of 500 AD groups in the source domain, those groups will take over 2 x 500 = 1000 of the 1010 slots in the target domain (assuming that all 500 groups were migrated).

Logon error: “….too many security IDs”

Test setup:

I put a test user in 1010 randomly generated groups and then increased the number of group memberships by 1 at a time. When I reached group 1013 the test was over, the logon on a Windows client was no longer possible.

Fortunately, the error message on Windows 10 has improved compared to older Windows versions. Al least it gives a hint what the potential problem could be:

„During a logon attempt, the user’s security context accumulated too many security IDs. “

Windows 10 error message

In comparison, here is the error message on Windows 7:

Windows 7 error message

Count all SIDs of a user object

Of course, in a migration project it should be avoided that users cannot logon with their new accounts on the day of the roll-out. No user account should have too many SID entries in its token due to SIDHistory. To prevent this problem ahead of time, you can use PowerShell to count how many SIDs there are for all user objects.

List SIDs with attribute “tokenGroups”

The attribute „tokenGroups“ contains almost all SIDs that are added to the security token when a user logs on to the pc. Additionally, it includes all “well known groups” and the “primary group”. “tokenGroups” is a so called “Constructed Value Attribute”. That means it has no saved values but is rather filled “on demand” when it is used.

Use PowerShell to read “tokenGroups”

As mentioned above, attribute “tokenGroups” is a “constructed value” and thus it must be read in a different way.

This will not work…

If you connect the user object with “Get-ADUser” and add the property “tokengoups.count”, you will realise that it does not work:

Better like this: “-Properties tokenGroups”

In order to count the attribute “tokenGroups” correctly in connection with a user object, it has to be addressed directly with the parameter „properties“.

Going back to our example above, the user account was member of 1013 groups and “tokenGroups” showed a value of 1015. That was enough to make it impossible to log on.

Pay attention to size of kerberos token

Next to the number of groups it is equally important to check the maximum size of the Kerberos token. Further information is available in this article “Group membership not working and GPO does not apply“.

The whole script

Should you want to copy the script, here is how I generated the 1013 groups:

Summary

The aim of this article was to explain how to tackle group memberships during an AD migration. It shows a solution how to look up all user accounts and analyse their number of future SIDs. With this method you can reveal and prevent “suspicious cases” before they turn into a logon problem for the users.