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, and you receive 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.
The issue occurs when the logon user is an explicit or transitive member of about 1010 or more security groups.
Event Type: Warning
Event Source: LsaSrv
Event Category: None
Event ID: 6035
Date: Date
Time: time
User: N/A
Computer: hostname
Description:
During a logon attempt, the user’s security context accumulated too many security IDs. This is a very unusual situation. Remove the user from some global or local groups to reduce the number of security IDs to incorporate into the security context.
User’s SID is SID
If this is the Administrator account, logging on in safe mode will enable Administrator to log on by automatically restricting group memberships.
Cause
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 that represents the user’s security context. The access token consists of unique security identifiers (SID) for every group that the user is a member of. These SIDs include transitive groups and SID values from SIDHistory of the user and the group accounts.
The array that contains the SIDs of the user’s group memberships in the access token can contain no more than 1024 SIDs. The LSA cannot drop any SID from the token. So, if there are more SIDs, the LSA fails to create the access token and the user will be unable to log on.
When the list of SIDs is built, the LSA also inserts several generic, well-known SIDs in addition to the SIDs for the user’s group memberships (evaluated transitively). Thus if a user is a member of more than about 1,010 custom security groups, the total number of SIDs can exceed the 1,024 SID limit.
Important
- Tokens for both administrator and non-administrator accounts are subject to the limit.
- The exact number of custom SIDs varies with the logon type (For example, interactive, service, network) and operating system version of the domain controller and computer that creates the token.
- Using Kerberos or NTLM as the authentication protocol has no bearing on access token limit.
- “Token” in the Kerberos Context refers to the buffer for the tickets received by a Windows Kerberos host. Depending on the size of the ticket, the type of SIDs and whether SID compression is enabled, the buffer can hold fewer or many more SIDs than that would fit into the access token.
The list of custom SIDs will include the following:
- The primary SIDs of the user/computer and the security groups the account is member of.
- The SIDs in the SIDHistory attribute of the groups in scope of the logon.
Because the SIDHistory attribute can contain multiple values, the limit of 1024 SIDs can be reached very quickly if accounts are migrated multiple times. The number of SIDs in the Access Token will be less than the total number of groups that the user is a member of in the following situation:
- The user is from a trusted domain where SIDHistory and SIDs are filtered out.
- The user is from a trusted domain across a trust where SIDs are quarantined. Then, only SIDs from the same domain as the user’s are included.
- Only the Domain Local Group SIDs from the domain of the resource are included.
- Only the Server Local Group SIDs from the resource server are included.
Because of these differences, it’s possible that the user can log on to a computer in one domain, but not to a computer in another domain. The user might also be able to log on to one server in a domain, but not to another server in the same domain.
Resolution
To fix this problem, use one of the following methods, as appropriate for your situation.
Method 1
This resolution applies to the situation in which the user who encounters the logon error is not an administrator, and administrators can successfully log on to the computer or to the domain.
This resolution must be performed by an administrator who has permissions to change the group memberships that the affected user is a member of. The administrator must change the user’s group memberships to make sure that the user is no longer a member of more than about 1010 security groups (considering the transitive group memberships and the local group memberships).
Options to reduce the number of SIDs in the user token include the following:
- Remove the user from a sufficient number of security groups.
- Convert unused security groups to distribution groups. Distribution groups don’t count against the access token limit. Distribution groups can be converted back to security groups when a converted group is required.
- Determine whether security principals are relying on SID History for resource access. If not, remove the SIDHistory attribute from these accounts. You can retrieve the attribute value through an authoritative restore.
Note Although the maximum number of security groups that a user can be a member of is 1024, as a best-practice, restrict the number to less than 1010. This number makes sure that token generation will always succeed because it provides space for generic SIDs that are inserted by the LSA.
Method 2
The resolution applies to the situation in which administrator account cannot log on to the computer.
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 theSafe Mode with Networking startup option). In safe mode, he must then log on to the domain controller by using this Administrator account credentials.
Microsoft has changed the token generation algorithm 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)
- 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
Note If the Safe Mode startup option is used, the Active Directory Users and Computers snap-in user interface (UI) 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 UI 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.
Thanks and Regards
KIRAN SAWANT
Leave a comment