Fix ADFS error 0X000009B0: token binding mismatch

1. Certificate binding mismatch (the most common cause)

What's happening: When you get 0X000009B0, what's actually happening is that the ADFS service can't bind the token decryption certificate to the correct key in the local machine's certificate store. This shows up most often after a certificate renewal or a server reboot on Windows Server 2022. The ADFS service expects a specific thumbprint, but the store has either a stale copy or the private key isn't accessible.

The fix:

Open an elevated PowerShell session as NT AUTHORITY\SYSTEM. Don't just run as administrator—use psexec -i -s powershell.exe from Sysinternals. The ADFS service runs as SYSTEM, so you need that context to see the private keys.
Check the current token-decryption certificate binding:
```
Get-ADFSCertificate -CertificateType Token-Decrypting
```
Look at the Thumbprint field.
Verify that certificate exists in Cert:\LocalMachine\My and has a private key. Run:
```
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Thumbprint -eq "THUMBPRINT" } | Format-List Subject, HasPrivateKey
```
If HasPrivateKey is False, the certificate is broken. Re-import it from a backup or renew.

If the certificate is fine but binding is wrong, re-register the certificate:

Update-ADFSCertificate -CertificateType Token-Decrypting -Thumbprint "THUMBPRINT" -Force

Restart the ADFS service:
```
Restart-Service adfssrv
```

This fixes about 70% of 0X000009B0 cases. The reason step 4 works is that Update-ADFSCertificate rewrites the configuration database entry to match the actual certificate store, clearing any stale binding references.

2. Stale Kerberos tickets for the ADFS service account

What's happening: ADFS runs under a domain service account (e.g., svc-adfs). If that account's Kerberos ticket in the local cache is expired or corrupted, the ADFS service can't authenticate its own token-signing process. You'll see 0X000009B0 in the event log with source ADFS and ID 364 or 315. This is common after a domain controller failover or a password reset on the service account.

The fix:

On the ADFS server, open an elevated Command Prompt.
Purge all cached Kerberos tickets for the service account. Run:
```
klist -lh 0
```
This clears the local ticket cache. Don't use klist purge alone—that only clears user tickets. The -lh 0 flag targets the LSA cache, which holds service account tickets.
Force the ADFS service to get a fresh ticket by restarting it:
```
Restart-Service adfssrv
```
Verify the new ticket:
```
klist -li 0x3e7
```
Look for the ADFS service account's ticket. It should show krbtgt and adfs SPNs.

If you see the error return within minutes, the service account's password hash is out of sync between domain controllers. Force replication:

repadmin /syncall /AdeP

Then restart ADFS again.

Why this works: The ADFS service uses Kerberos to verify the integrity of its own tokens. If the ticket cache has a stale entry, the crypto layer fails the binding check—and throws 0X000009B0 instead of a more descriptive error. Clearing the cache forces a fresh authentication against the KDC.

3. Corrupted ADFS configuration database (rare but nasty)

What's happening: If neither of the above fixes it, the error is probably coming from a corrupted entry in the ADFS configuration database (stored in Windows Internal Database or SQL Server). This happens after an incomplete schema upgrade or a failed hotfix installation. You'll see repeated 0X000009B0 errors every few minutes in the event log, and the ADFS service may crash with a 0xc0000005 Access Violation.

The fix:

First, back up the configuration:
```
Export-ADFSDeploymentSQLScript -DestinationPath C:\ADFS_Backup.sql
```
Or use Export-ADFSDeploymentScript if using WID.
Run the ADFS Health Check tool from Microsoft:
```
Test-ADFSFarmBehaviorLevel -GroupServiceAccount
```
This checks for schema mismatches.
If the tool reports missing or duplicate entries, you'll need to repair the database. The safest way is to remove and re-add the ADFS role:
```
Uninstall-WindowsFeature ADFS-Federation
```
Reboot. Then reinstall and reimport the backup:
```
Install-WindowsFeature ADFS-Federation
Restore-ADFSFarmBehaviorLevel -GroupServiceAccountCredential (Get-Credential)
```
Then restore the SQL script if you used SQL.

Important: Don't attempt to manually edit the WID database files (C:\Windows\WID\Data\adfs). You'll make it worse. The database engine locks those files, and any direct change will corrupt the transaction log.

This is the nuclear option. Only try it if the first two causes are ruled out and the health check shows clear corruption.

Quick-reference summary table

Symptom	Likely cause	Fix priority	Time estimate
0X000009B0 after certificate renewal	Certificate binding mismatch	1	15 minutes
0X000009B0 after DC failover or account password change	Stale Kerberos ticket	2	10 minutes
0X000009B0 persists after reboot and certificate check	Corrupted ADFS configuration database	3	1-2 hours

Start with cause 1. If you skip the SYSTEM context step, you'll waste time. I've seen people run Get-ADFSCertificate as a domain admin and see no error, then restart the service—and the error comes right back. The private key check only works under SYSTEM.