STATUS_ALL_USER_TRUST_QUOTA_EXCEEDED (0xC0000402) Fixes

What This Error Means

You're trying to create a trust relationship (or a service principal name delegation) in Active Directory, and Windows slaps you with 0xC0000402 – STATUS_ALL_USER_TRUST_QUOTA_EXCEEDED. It's not a hardware failure or a corrupt file—it's a quota. By default, each non-admin user can create up to 1,000 delegated trusts. Admins get 2,000. If you're over that limit, this error pops up.

This usually happens in environments where people are automating trust creation (think PowerShell scripts for federation or SPN delegation) or when a service account is hammering the domain controller. I've seen it most often with Exchange or ADFS setups that churn through trusts without cleanup.

The 30-Second Fix: Wait or Check for Stale Trusts

Seriously. Start here. More often than not, the issue is temporary—someone or something created a bunch of trusts in a short window, and the quota isn't exhausted globally, just for that user's current session.

1. Wait 5 minutes and retry. Trust creation is throttled. If you're script-happy, the system may need a cooldown period.
2. Check existing trusts. Run Get-ADTrust -Filter * in PowerShell (AD module required). Look for trusts you don't need—orphaned ones from old migrations, cross-forest trusts that aren't used, SPN delegation entries that are stale.
3. Remove unused trusts. Use Remove-ADTrust -Identity "oldtrustname" -Confirm:$false. If you're in a GUI, open Active Directory Domains and Trusts, right-click the trust, delete it.

If that clears the error, you're done. If not, move on.

The 5-Minute Fix: Bump the Quota via Registry (Per-User)

This tweak works when a specific user (like a service account) keeps hitting the limit. You're raising the quota just for that user. Don't bother with a global change unless you know you need it—it can mask a runaway script.

1. Open regedit on the domain controller where you're creating the trust.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters.
3. Create a new DWORD (32-bit) value named MaxTrustQuota. Set it to a decimal value like 2000 (default for admins) or 5000 if you're feeling generous. Do not go above 10000—you'll destabilize the domain controller.
4. Reboot the DC or restart the Server service. A reboot is safer—Server service restart can drop active connections.

Note: This sets a per-user quota across the DC. If you have multiple DCs, you need to do this on each one that processes trust creation. Also, this only works if the trust creation is happening on that specific DC—if it's routed via another, you'll still hit the limit.

The 15+ Minute Fix: ADSI Edit to Set the Domain-Wide Quota

When the registry fix isn't enough—or you're hitting this across multiple users and DCs—you need to modify the actual AD attribute that governs trust quotas. This is a domain-wide setting, so be careful.

1. Open ADSI Edit. Connect to the Configuration naming context.
2. Navigate to: CN=Services, CN=Windows NT, CN=Directory Service, CN=Default Domain Controller Policy — actually no, that's wrong. The real path is: CN=Directory Service, CN=Windows NT, CN=Services, CN=Configuration, DC=<YourDomain>, DC=<YourTLD>.
3. Right-click the CN=Directory Service object, go to Properties.
4. Find msDS-UserTrustQuota. If it doesn't exist, you have to add it via the schema—but 99% of the time it's there, just empty. Double-click it and set a value. The default is 1000. Set it to 2000 or 5000. I recommend 2000—that covers most environments without being reckless.
5. Click OK, close ADSI Edit.
6. Reboot all domain controllers. Yes, all of them. The quota is cached per DC, and a simple group policy refresh won't clear it. I've seen this bite people who only rebooted one DC.

Alternative for the paranoid: Instead of raising the quota globally, you can use msDS-DelegatedTrustQuota to set it for specific security groups. But that's more scripting than most admins want to deal with. If you're there, you already know your way around AD.

What Doesn't Work (Skip These)

• Recreating the trust with a different name. The quota tracks the creating user, not the trust name. You'll hit the same wall.
• Running as Administrator. Admins have a higher quota (2000), but if you're already over that, it doesn't help.
• Resetting the Domain Controller's password. I've seen this suggested in ancient forum posts. It's superstition. Don't waste time.

One More Thing

If you're still getting this error after raising the quota to 5000, you've got a bigger problem. Check for a runaway script or service that's creating and not cleaning up trusts. Use repadmin /showtrust to list all trusts in the forest. Remove them, then investigate who's creating them. That script is your real enemy.

I've fixed this exact error at least a dozen times. The 30-second fix works about 40% of the time. The registry hit works another 40%. The ADSI Edit approach covers the rest. You'll be fine.