Quick Answer (for advanced users)
Check the security descriptor on the target object or resource—something stripped all SIDs. Look at the tokenGroups attribute on the user account in ADSI Edit, and verify no empty DACL or NULL DACL is in play. Then review SID filtering settings on the trust or the resource's SACL.
What's Happening Here?
You got error 0XC0090002, which reads ERROR_ALL_SIDS_FILTERED. That means every single security identifier (SID) in the user's token was removed by a filter before the access check could run. No SIDs? No access. Happens most often during domain joins across trusts, or when a service tries to read a security descriptor but the SID filtering mechanism goes too aggressive.
I've seen this crop up in two specific real-world scenarios:
- You're joining a computer to a domain across a forest trust, and the trust has SID filtering enabled (it's on by default). The user account's SIDs from the trusted domain got stripped because they didn't pass the filter.
- You're running
Set-Acloricaclson a file share, and the DACL or SACL has an empty entry—or worse, a NULL DACL—which the system interprets as "no SIDs allowed."
The key thing to understand: SID filtering is there to prevent privilege escalation across trusts. But it can be too strict. When it removes all SIDs, you get this error. The fix is to figure out why the filter thinks every SID is invalid.
Step-by-Step Fix
Step 1: Identify Where the Filter Hit
Open Event Viewer. Go to Windows Logs > Security. Look for event ID 4625 (logon failure) or 4672 (special logon). The error code in the details should be 0xC0090002. This tells you which account and resource triggered it. If it's a domain join, you'll see it in the Microsoft-Windows-Security-Netlogon/Operational log.
Expected outcome: A clear event showing the account name and target machine.
Step 2: Check the User's Token Groups
Open ADSI Edit on a domain controller. Connect to the default naming context. Find the user account that triggered the error. Right-click it, choose Properties. Look for the attribute tokenGroups. This lists all SIDs the user gets in their token.
If tokenGroups is empty or shows only well-known SIDs like S-1-5-21... with no domain groups, the filter already removed them. That's your problem.
Expected outcome: A populated list of SIDs. If it's empty, the user has no group memberships—or they got filtered.
Step 3: Examine the Trust Relationship (If Cross-Forest)
If this is across a forest trust, check SID filtering on that trust. Open Active Directory Domains and Trusts. Right-click the domain, go to Properties > Trusts. Select the trust, click Properties, then the SID Filtering tab.
What you're looking for: whether Allow SID filtering is enabled. It's on by default. If you see Require SID filtering, that's even stricter—it blocks any SID that isn't from the trusted domain's forest. That'll cause this error if the account has any cross-forest groups.
To fix it (temporarily): Disable SID filtering by unchecking Require SID filtering. Don't leave it off—that's a security risk. Use this only to test if the error goes away.
Expected outcome: After disabling, the error should stop. If it does, you know the filter was the cause.
Step 4: Inspect the Resource's Security Descriptor
If the error is on a file share or registry key, check the object's ACL. Run this in PowerShell as admin:
Get-Acl -Path "C:\Path\To\Resource" | Format-ListLook at the Access property. If it's empty, that's a NULL DACL—meaning no access at all. A NULL DACL isn't the same as an empty DACL. A NULL DACL means no security (everyone gets in), but Windows sometimes treats it as "all SIDs filtered." Fix it by setting a proper ACL:
$acl = Get-Acl "C:\Path\To\Resource"
$acl.SetAccessRuleProtection($true, $false)
Set-Acl -Path "C:\Path\To\Resource" -AclObject $aclThen add at least one access rule like BUILTIN\Users with Read.
Expected outcome: After applying, the ACL shows at least one entry. Test access again.
Step 5: Reset the SID Filter Cache on the Client
On the machine that got the error (the client or server), restart the Netlogon service. This clears the cached SID filter info. Run this in an admin command prompt:
net stop netlogon && net start netlogonExpected outcome: Service restarts. Then try the failing operation again.
Alternative Fixes (If Step 3 or 4 Don't Work)
Alternative 1: Disable SID Filtering Globally (Not Recommended)
If you're desperate and the trust is in a test lab, you can disable SID filtering entirely for the trust. On the domain controller, open PowerShell as admin and run:
Set-ADTrust -Identity "TrustName" -SIDFilteringQuarantine $falseReplace TrustName with the actual trust name. This turns off all SID filtering. Don't do this in production—you're inviting security issues.
Alternative 2: Use the Local Group Policy to Allow SID Filtering Exceptions
On the resource server, open Local Group Policy Editor (gpedit.msc). Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Find Network access: Allow anonymous SID/Name translation. Set it to Enabled. This lets the system accept SIDs from other domains more freely.
Expected outcome: After a reboot, try the failing operation.
Alternative 3: Rebuild the User's Token
If the user's tokenGroups is empty in ADSI Edit, force a token refresh. Log off the user, then log back on. Or better, restart the machine. If that doesn't work, reset the user's password—that regenerates the token.
Prevention Tip
The real fix is to stop SID filtering from going nuclear. Two rules:
- Keep SID filtering enabled on forest trusts, but don't use Require SID filtering unless you understand the consequences. Test with a single user first.
- Never set a NULL DACL on resources. Always define explicit access rules. An empty DACL is just as bad—it means "deny everyone."
If you have to run cross-forest access often, consider using group managed service accounts (gMSAs) that bypass some SID filtering checks. They're more secure anyway.
Final thought: I've seen this error stump admins for hours because they look at the trust settings and think "it's fine." It's not the trust itself—it's what the filter removes. Always start by checking the user's token groups. That's where the answer lives.