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

Article translations Article translations
Article ID: 328889 - View products that this article applies to.
This article was previously published under Q328889
Expand all | Collapse all

On This Page

Symptoms

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:
Logon Message: 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.

Cause

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.

Resolution

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.

More information

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.

Properties

Article ID: 328889 - Last Review: March 26, 2013 - Revision: 2.0
Applies to
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Windows Vista Business
  • Windows Vista Enterprise
  • Windows Vista Home Basic
  • Windows Vista Home Premium
  • Windows Vista Starter
  • Windows Vista Ultimate
  • Windows Server 2008 Datacenter without Hyper-V
  • Windows Server 2008 Enterprise without Hyper-V
  • Windows Server 2008 for Itanium-Based Systems
  • Windows Server 2008 Standard without Hyper-V
  • Windows Server 2008 Datacenter
  • Windows Server 2008 Enterprise
  • Windows Server 2008 Standard
  • Windows Server 2008 R2 Datacenter
  • Windows Server 2008 R2 Datacenter without Hyper-V
  • Windows Server 2008 R2 Enterprise
  • Windows Server 2008 R2 Enterprise without Hyper-V
  • Windows Server 2008 R2 Foundation
  • Windows Server 2008 R2 Standard
  • Windows Server 2008 R2 Standard without Hyper-V
  • Windows 7 Enterprise
  • Windows 7 Enterprise N
  • Windows 7 Home Premium N
  • Windows 7 Professional N
  • Windows 7 Starter N
  • Windows 7 Ultimate N
  • Windows Server 2012 Datacenter
  • Windows Server 2012 Essentials
  • Windows Server 2012 Foundation
  • Windows Server 2012 Standard
  • Windows 8 Enterprise
  • Windows 8 Enterprise N
  • Windows 8 N
  • Windows 8 Pro
  • Windows 8 Pro N
Keywords: 
kbinfo KB328889

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com