Fix ERROR_PER_USER_TRUST_QUOTA_EXCEEDED (0x78C) - Delegated Trust Quota

What's Actually Happening Here

The error 0x0000078C — ERROR_PER_USER_TRUST_QUOTA_EXCEEDED — pops up when Windows or an app tries to create a delegated trust (like a Kerberos delegation, PKU2U authentication, or a domain trust setup) and your user account has already used up its allowed quota. Windows limits how many trusts a non-admin user can create to prevent abuse or accidental trust poisoning. The default quota is 1 or 0 on many systems, depending on the OS version and security baseline.

You'll usually see this when trying to join a machine to a domain as a non-admin, set up a forest trust, configure delegation in Active Directory, or when a third-party app (like a VPN client or remote desktop tool) tries to create a local security authority trust behind the scenes. The exact error text is "The current user's delegated trust creation quota has been exceeded."

Cause #1: The Default Delegated Trust Quota Is Too Low

Why It's the Most Common

Microsoft sets the DelegationQuota registry value to 1 by default for standard users, and 0 for built-in admin accounts (which can create unlimited trusts — the quota is ignored). If you're running a domain-joined machine, Group Policy often overrides this to 0 or 1. The OS checks this quota every time a new trust is established via the Local Security Authority (LSASS). Once you hit the limit, you get 0x78C.

The Fix: Raise or Remove the Quota

1. Open Registry Editor (regedit) as Administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
3. If the Parameters key doesn't exist, create it (right-click Kerberos → New → Key, name it Parameters).
4. Inside Parameters, create a new DWORD (32-bit) value called DelegationQuota.
5. Set the value to something higher than your current need. 10 is safe for most scenarios. If you don't care about the limit at all, set it to 0 (which means unlimited for that user — only works if the user isn't a standard user via Group Policy).
6. Reboot the machine or restart the Kdc service (net stop kdc && net start kdc) for the change to take effect.

Example regedit path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\DelegationQuota = dword:0000000a

Why step 6 matters: LSASS caches the quota at boot. Just killing the Kerberos Key Distribution Center service isn't enough — a full reboot is simpler. But if you can't reboot, restarting kdc flushes the quota cache for new trust creations.

Cause #2: Group Policy Overrides the Registry Value

The Real Issue

You set the registry key, but the error persists. What's actually happening here is that a domain Group Policy object (GPO) is enforcing a lower quota. The GPO setting lives under Computer Configuration → Administrative Templates → System → Kerberos → Delegated Trust Quota. If this policy is enabled and set to a low number (like 1 or 0), it overrides your local registry change.

The Fix: Check and Modify the GPO

1. Run gpedit.msc (or open Group Policy Management Console if you're a domain admin).
2. Navigate to Computer Configuration → Administrative Templates → System → Kerberos.
3. Double-click Set maximum number of delegated trusts a user can create.
4. Set it to Enabled and enter a value like 10 or 0 for unlimited. If you want to allow the local registry setting to work, set it to Not Configured.
5. Run gpupdate /force on the affected machine.
6. Reboot.

If you're not a domain admin, you can't change the GPO — but you can check its effective value with gpresult /h gp.html and look for the Kerberos policy section. If it's enforced, talk to your AD admin. Don't waste time fighting the registry if the GPO is the boss.

Cause #3: Third-Party Software That Spams Trusts

What's Happening

Some apps (older VPN clients like Cisco AnyConnect, RDP wrappers, or even certain antivirus suites) create temporary delegated trusts for credential delegation. They don't clean up after themselves, so the quota fills up. The most common offender I've seen is Cisco Secure Client (formerly AnyConnect) — it creates a trust for each VPN session and sometimes leaks one on disconnect. Other candidates: VMware Horizon Client, Citrix Workspace, and some PKI enrollment tools.

The Fix: Audit and Clean Trusts

1. Open a command prompt as Administrator and run: klist -li 0x3e7 — this dumps all delegated trusts for the local system account. Look for entries with Delegated status.
2. If you see many stale trusts (like 5+ from the same app), revoke them with klist purge -li 0x3e7.
3. Uninstall or update the offending app. For Cisco AnyConnect, version 4.9+ fixes the leak. For older versions, the workaround is to increase the quota (Cause #1) because the app won't stop leaking.
4. Consider a scheduled task that runs klist purge -li 0x3e7 daily if you can't update the app. It's a hack, but it works.

A specific real-world trigger: A user connects to a corporate VPN every morning. After 3 days, they can't authenticate to a network share because the trust quota is exceeded — the VPN client created one trust per session and never released them. The event log shows event ID 27 from Kerberos with error 0x78C.

Quick-Reference Summary Table