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.
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
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.
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
- Domain\Domain Admins
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
- xxxxxxxx-yyyyyyyy-zzzzzzzz denotes the domain component of
- 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
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
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.