STATUS_TOO_MANY_CONTEXT_IDS (0XC000015A) Login Bug Fixed

You hit the login wall with error 0XC000015A.

It's infuriating — you type your password, you get that brief spinning circle, and then "Status: 0xC000015A, STATUS_TOO_MANY_CONTEXT_IDS." Your first thought is something broke on the server. But it's probably your account. Let's fix it.

The quickest fix that works 90% of the time: remove the computer from the domain, reboot, and rejoin it. This forces a fresh Kerberos ticket and cleans out any cached group membership bloat on that machine.

# Run as Administrator on the affected machine
# Step 1: Leave the domain
Remove-Computer -UnjoinDomainCredential DomainName\Administrator -Force
# Step 2: Reboot
Restart-Computer -Force
# Step 3: After reboot, rejoin
Add-Computer -DomainName DomainName -Credential DomainName\Administrator -Restart

If you can't do that (maybe you're locked out entirely), you'll need another admin to clean up group memberships for your user account in Active Directory. Specifically, remove your user from any groups that are unnecessary — every group adds a SID to your token.

Why this works

What's actually happening here is a hard limit in Windows. The LSA (Local Security Authority) builds a security token for your logon session, and that token has a maximum of 256 SIDs (security identifiers). Microsoft hard-coded this limit into the LsaLogonUser API. Once you exceed 256 SIDs, the logon fails with 0xC000015A.

The reason step 3 (rejoin domain) works is that the local machine caches group SIDs from the domain. Over time, if you're in dozens of distribution groups, security groups, and nested groups — all those SIDs accumulate. The domain controller sends them all. Rejoining wipes the local cache and resets the machine account's trust relationship, which often reduces the SID count delivered.

But the real culprit is usually nested group memberships. If your account is in Group A, and Group A is in Group B, and Group B is in Group C — each nesting level multiplies the SID count. The limit is per token, not per user. So even if you're in only 50 groups, if those groups nest deeply, you can blow past 256.

Less common variations of the same issue

Sometimes it's not your account. Here are a few edge cases I've seen:

Service accounts with too many groups

A SQL Server service account that's been added to every security group for database access. The real fix is to create a single dedicated security group, put the service account in that one group, and grant permissions to that group instead. Don't keep piling individual groups onto the service account.

Domain controller itself hits the limit

When a DC can't log in with its own machine account (e.g., SYSTEM context), that's bad. The fix here is to audit group memberships of the Domain Controllers group. No one should be adding user accounts directly to that group — that adds 20+ SIDs per user.

Third-party identity management tools

Tools like Active Roles or Quest can sometimes inject extra SIDs during logon. Check their logs — they may be adding cross-domain group memberships that push you over the edge.

In all these cases, the diagnostic tool is Whoami:

whoami /groups
# Count the number of lines — anything over 256 is a problem

If you can't log in, run that from an elevated command prompt under a different admin account (or boot into Safe Mode with Networking and use a local admin).

Prevention

Once you're back in, stop this from recurring. The rule: Keep user group memberships under 100. That gives you headroom for nested group expansion. Audit your AD groups quarterly — especially distribution groups that are being used as security groups (a common mistake).

Set a group policy to limit the token size at the domain level. This won't fix an existing overflow, but it will log a warning before you hit the wall:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
# Set "Network access: Restrict clients allowed to make remote calls to SAM" to a reasonable value
# Also review: "Limit local account use of blank passwords to console logon only"

The more surgical fix: use Group Nesting wisely. If you have a "Sales" group that contains "Sales-Europe" and "Sales-Asia," don't add every user to all three. Add users only to the leaf group. The parent groups should be used for permission inheritance only — not for direct membership.

One last thing: if you're running a mixed environment with Windows 10 22H2 and Server 2012 R2 domain controllers, the older DCs might send duplicate SIDs for universal groups. Upgrade those DCs to Server 2016 or later — it's a known issue fixed in KB4038801.

So there it is. The 0xC000015A error isn't a server meltdown — it's a token size problem. Clean up the groups, rejoin the domain, and you'll be back in business.