SEC_E_BAD_BINDINGS (0x80090346): Channel Binding Mismatch Fix

I know seeing 0x80090346 in your logs or on screen is maddening — especially when everything was working yesterday. Let's kill it fast.

The Quick Fix: Disable Extended Protection for Authentication

This error means the client's channel bindings don't match what the server expects. The fastest resolution is to disable Extended Protection for Authentication on the server side. Here's how.

1. Open Group Policy Management Console (gpmc.msc) on your domain controller.
2. Navigate to Computer Configuration > Administrative Templates > System > Credentials Delegation.
3. Find Allow delegating default credentials with NTLM-only server authentication and set it to Enabled.
4. In the options, click Show and add spn/exchangeserver.domain.com (replace with your actual SPN).
5. Back in Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security, set Require use of specific security layer for remote (RDP) connections to Enabled and choose SSL (TLS 1.0).
6. Run gpupdate /force on both server and client.

If you're not using domain GPO, hit the registry directly:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel" /v "EnableOcspStaplingForChannelBinding" /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "DisableLoopbackCheck" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Credssp" /v "Disabled" /t REG_DWORD /d 0 /f

Reboot after applying registry changes. This kills channel binding validation entirely — it's a blunt tool but it works.

Why This Happens

Channel bindings are a security feature. They tie the TLS session to the authentication handshake so an attacker can't relay credentials. When the client sends a binding token that doesn't match the server's computed token — bam, 0x80090346. Common triggers:

• RDP to a server using a different hostname than the certificate's CN or SAN.
• Outlook connecting to Exchange with a mismatched SPN (e.g., using mail.domain.com instead of autodiscover.domain.com).
• IIS applications using Windows Authentication behind a load balancer that terminates TLS.

The real fix depends on whether you want to keep Extended Protection or ditch it. If you want to keep it (and you should, for security), you need to align the binding tokens.

Keeping Extended Protection On: Align the Bindings

Skip disabling if you can make the tokens match. For Exchange or IIS, do this:

IIS

1. Open IIS Manager, select your site.
2. Double-click Authentication, select Windows Authentication, click Advanced Settings.
3. Set Extended Protection to Accept or Required. If you set Required, all clients must support it. Start with Accept.
4. Under Enable Kernel-mode authentication — uncheck it if you see the error. This forces user-mode auth which respects Extended Protection.

Exchange

Run this in Exchange Management Shell:

Set-OutlookAnywhere -Identity "ServerName\Rpc (Default Web Site)" -ExtendedProtectionTokenChecking Allow -ExtendedProtectionSPNList @{Add="msstd:mail.domain.com"}

Also check your SSL certificate. If it's issued to server.domain.com but clients connect to mail.domain.com, you need a SAN certificate covering both.

Less Common Variations

• LDAP channel binding — This error shows up in ActiveDirectory event logs as 0x80090346 when an app does LDAP binds without proper channel binding. Fix: Set registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters key LdapEnforceChannelBinding to 1 (or 2 to force it). If you set it to 2, legacy apps break — test first.
• Wi-Fi authentication (802.1X) — Some RADIUS servers require channel bindings. If your client's supplicant doesn't send them, this error pops. Update your wireless client driver or disable PEAP channel binding on the NPS server.
• SQL Server — SQL always uses SSPI for Windows auth. If you see 0x80090346 in SQL logs, check the SPN for the SQL service. Run setspn -Q MSSQLSvc/servername.domain.com and fix duplicates.

Prevention Going Forward

• Use consistent hostnames — Clients should connect using the same name that's in the server certificate. No aliases, no IPs, no CNAMEs unless they match the cert.
• Patch regularly — Microsoft patched a channel binding vulnerability in August 2021 (KB5005033). Outdated systems are more likely to see this error because the client or server handles bindings differently.
• Monitor event logs — Watch for Event ID 4 from Schannel or 2889 from ActiveDirectory. They'll point you to the misbehaving client.
• Test with Accept first — If you enable Extended Protection, always use Accept mode before Required. That way legacy clients still work while you fix the rest.

That's it. The error is annoying but it's just a mismatch between what the client sent and what the server expected. Align them or disable the check — your call. Either way, you're back up in minutes.