STATUS_ALL_SIDS_FILTERED Fix: 0XC000035E in Windows

You're staring at a login failure or a service crash with 0XC000035E and the message "The SID filtering operation removed all SIDs." I've seen this exact error more times than I care to count, and it's almost always one of two things: a broken domain trust or a group membership that's gone sideways. Let's cut the fluff and get you fixed.

Cause #1: Domain Trust with SID Filtering Enabled (Most Common)

If this happens when someone tries to access a resource across domains, the culprit is almost always the trust relationship. SID filtering is a security feature that strips out SIDs from the trusted domain that don't belong there. When it removes all SIDs, the user ends up with no security context — so they get nothing but denied access.

Here's the scenario I run into at least once a quarter: A company acquires another domain, sets up a two-way trust, and then users from the trusted domain can't access file shares in the resource domain. Event ID 4625 shows 0XC000035E in the logs.

The fix is to check if SID filtering is on for that trust and decide if you actually need it.

1. On the domain controller for the resource domain, open Active Directory Domains and Trusts.
2. Right-click the trust, go to Properties → Trusts tab.
3. Click the trust, then Properties → General tab.
4. Click Validate — make sure both directions pass. If they don't, fix the trust credentials first.
5. Then check the SID Filtering setting. Use the command-line tool if you want it faster:

netdom trust <resource_domain> /domain:<trusted_domain> /quarantine

If it returns Yes, SID filtering is enforcing. If you're certain the trusted domain is safe (it's your own domain, right?), you can disable it:

netdom trust <resource_domain> /domain:<trusted_domain> /quarantine:No

But wait — don't just do that blindly. Disabling SID filtering opens up security risks. Only do it if the trusted domain is fully trusted (ironic, I know) and you have no alternative. What I usually recommend first is working around the issue by adding the specific SIDs you need, but that's not always practical.

The safer fix is to add the user's SID history to a group in the resource domain that has access. That way, SID filtering doesn't strip it because it's a resource domain SID. But that's a hack, and I know you want the real solution.

If you need the access and you've verified the trust is solid, disabling filtering is the pragmatic fix. Just document it and make sure your security team is aware.

Cause #2: Group Membership with Cross-Domain SIDs

Here's the less common but sneakier variant. You have a universal group in the trusted domain that contains users from the resource domain. When the user logs in, the domain controller tries to build the token. SID filtering kicks in and removes the trusted domain SIDs, but if the group's membership is entirely from the trusted domain, you're left with nothing.

I saw this once with a vendor-managed service account. The account was a member of a universal group that had no resource domain SIDs, and the trust had filtering enabled. Everything looked fine in ADUC, but the service kept failing to start.

The fix here is to break the dependency on cross-domain group memberships. Move the user or group into a group that exists in the resource domain.

1. Open Active Directory Users and Computers on the resource domain.
2. Create a new group (or find an existing one) that's domain local or global — just not universal.
3. Add the user or the trusted domain group to this new group.
4. Re-authenticate or restart the service.

That gives the user a SID from the resource domain, so filtering doesn't wipe everything. It's ugly but works.

Also check if the user has SID history from a previous domain migration. SID filtering specifically strips SID history. If you migrated users with ClonePrincipal or ADMT, the old domain SIDs are in SID history. When the trust is set to filter, those get zapped. If that's the case, you have two options:

• Disable filtering (back to Cause #1).
• Clean up SID history — remove the stale SIDs. Not fun, but sometimes necessary.

To see if SID history is the problem, check the sidHistory attribute for the affected user:

Get-ADUser username -Properties sidHistory | Format-List

If it's not empty, that's likely the trigger.

Cause #3: Misconfigured Claims or Conditional Access (Azure AD)

Now, this one's newer but I've seen it enough. If you're hybrid-joined and using Azure AD Conditional Access or claims-based rules, SID filtering can screw you over in a different way. The token gets built, but the claims engine demands SIDs that aren't there, so it falls back to stripping everything.

Typically this shows up when a user tries to access a claims-aware app and gets 0XC000035E in the SAML or OAuth response.

The fix is to check your Conditional Access policies and make sure you're not requiring SIDs that don't exist. Specifically, look for policies that use "group" conditions with on-premises groups that aren't synced properly.

1. Sign in to the Microsoft Entra admin center (formerly Azure AD).
2. Go to Protection → Conditional Access.
3. Find the policy that's blocking the user. Look at the conditions — if it's referencing a group, check if that group is synced from AD.
4. If the group isn't synced, either fix the sync or change the policy to use a synced group.

Also check if you have claims rules in your AD FS (if you still use it). Those can force SID removal if they're written poorly.

I've seen people spend days on this thinking it's a trust issue when it's really just a misapplied policy. Don't be that person.

Quick Reference Summary

Remember: 90% of the time it's the trust. Check that first. And don't skip the validation step — a broken trust will give you weird errors that look like something else.

If you're still stuck after this, check the security event log on the DC for the exact SID that was filtered. The event details will show you which SID got stripped, and that'll point you to the group or user causing the issue. Good luck.