Users who are members of more than 1,015 groups may fail logon authentication

When a user tries to log on to a computer by using a local computer account or a domain user account, the logon request may fail with the following error message:

This problem occurs when a user (with an administrative user account or a non-administrative user account) who is a member of more than 1,015 security groups tries to log on.

When a user logs on to a computer, the Local Security Authority (LSA, a part of the Local Security Authority Subsystem) generates an access token for the user to represent the security context of the user. The access token contains the user’s unique security identifier (SID) and the SIDs of every group that the user is a member of, including transitive groups.

Note The only exception to this behavior is that not all domain local security groups that the user is a member of will show up in the user’s token. The only domain local security groups that will show up (in the user’s token) are those groups that the user is a member of that also reside in the domain that contains the computer account that the user is logging on to. For an example that illustrates this process, see the "More Information" section.

Because of a system limitation, the field that contains the SIDs of the user’s group memberships in the access token can contain a maximum of 1,024 SIDs. If a user is a member of more than 1,024 security groups, the LSA cannot create an access token for the user during the logon attempt. Therefore, the user will not be able to log on. During access token generation, depending on the type of logon being performed, the LSA also inserts up to 9 well-known SIDs in addition to the SIDs for the user’s group memberships (evaluated transitively).

Because of the addition of well-known SIDS by the LSA, if a user is a member of more than 1,015 (that is, 1,024 minus 9) security groups, the total will be more than the 1,024 SID limit. Therefore, the LSA will not be able to create an access token for the user during the logon attempt. (This 1,015 number includes local group memberships of the computer that the user is trying to log on to.) Because the user cannot be authenticated, they cannot log on.

To resolve this problem, use one of the following methods, depending on your situation.

Case 1: The user who encounters the logon error is not an administrator, but administrators can successfully log on to the computer or to the domain

This resolution must be performed by an administrator who has permissions to modify the group memberships that the impacted user is a member of. The administrator must modify the user’s group memberships to make sure that the user is no longer a member of more than 1,015 security groups (taking into account the transitive group memberships and the local group memberships). After the administrator removes the user from a sufficient number of security groups, the user will then be able to successfully log on to the domain.

Note Although the maximum number of security groups that a user can be a member of is 1,024, as a best-practice, restrict the number to 1,015. This number makes sure that token generation will always succeed because it provides space for up to 9 well-known SIDs that are inserted by the LSA.

Case 2: The user who fails logon is an administrator

When the user whose logon fails because of too many group memberships is a member of the Administrators group, an administrator who has the credentials for the Administrator account (that is, an account that has a well-known relative identifier [RID] of 500) must restart a domain controller by selecting the Safe Mode startup option (or by selecting the Safe Mode with Networking startup option) and must then log on to the domain controller by using the Administrator account.

Microsoft has modified the token generation algorithm in the LSA so that the LSA can create an access token for the Administrator account so that the administrator can log on regardless of how many transitive groups or intransitive groups that the Administrator account is a member of. When one of these safe mode startup options is used, the access-token that is created for the Administrator account includes the SIDs of all Built-in and all Domain Global groups that the Administrator account is a member of. These groups typically include the following:

• Everyone (S-1-1-0)
• BUILTIN\Users (S-1-5-32-545)
• BUILTIN\Administrators (S-1-5-32-544)
• NT AUTHORITY\INTERACTIVE (S-1-5-4)
• NT AUTHORITY\Authenticated Users (S-1-5-11)
• LOCAL (S-1-2-0)
• Domain\Domain Users (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-512)

The access-token that is created for the Administrator account may optionally include the following SIDs:

• BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554) if Everyone is a member of this group
• NT AUTHORITY\This Organization (S-1-5-15) if the domain controller is running Windows Server 2003

Notes

• xxxxxxxx-yyyyyyyy-zzzzzzzz denotes the domain component of the SID.
• The NT AUTHORITY\NETWORK SID can be inserted instead of the NT AUTHORITY\INTERACTIVE SID, depending on the logon type.
• If the Safe Mode startup option is used, the Active Directory Users and Computers snap-in user interface is not available. In Windows Server 2003, the administrator may alternatively log on by selecting the Safe Mode with Networking startup option; in this mode, the Active Directory Users and Computers snap-in user interface is available.

After an administrator has logged on by selecting one of the safe mode startup options and by using the credentials of the Administrator account, the administrator must then identify and modify the membership of the security groups that caused the denial of logon service.

After this change is made, users should be able to log on successfully after a time period that is equal to the domain’s replication latency has elapsed.

The following example illustrates which domain local security groups will show up in the user’s token when the user logs on to a computer in a domain.

In this example, assume that Joe belongs to Domain A and is a member of a domain local group Domain A\Chicago Users. Joe is also a member of a domain local group Domain B\Chicago Users. When Joe logs on to a computer that belongs to Domain A (for example, Domain A\Workstation1), a token is generated for Joe on the computer, and the token contains, in addition to all the universal and global group memberships, the SID for Domain A\Chicago Users. It will not contain the SID for Domain B\Chicago Users because the computer where Joe logged on (Domain A\Workstation1) belongs to Domain A.

Similarly, when Joe logs on to a computer that belongs to Domain B (for example, Domain B\Workstation1), a token is generated for Joe on the computer, and the token contains, in addition to all the universal and global group memberships, the SID for Domain B\Chicago Users; it will not contain the SID for Domain A\Chicago Users because the computer where Joe logged on (Domain B\Workstation1) belongs to Domain B.

However, when Joe logs on to a computer that belongs to Domain C (for example, Domain C\Workstation1), a token is generated for Joe on the logon computer that contains all universal and global group memberships for Joe's user account. Neither the SID for Domain A\Chicago Users nor the SID for Domain B\Chicago Users appears in the token because the domain local groups that Joe is a member of are in a different domain than the computer where Joe logged on (Domain C\Workstation1). Conversely, if Joe were a member of some domain local group that belongs to Domain C (for example, Domain C\Chicago Users), the token that is generated for Joe on the computer would contain, in addition to all the universal and global group memberships, the SID for Domain C\Chicago Users.