Fix SSPI 0XC000035B STATUS_BAD_BINDINGS

You're staring at 0XC000035B and it's driving you nuts. I've been there. This error usually pops up when a service tries to authenticate and the channel bindings don't match. Let's get you fixed.

The Fix

The most common culprit is a service account whose password has expired or changed. The service caches the old password and sends it with the binding. Here's how to fix it:

Open Services (Win + R, type services.msc).
Find the service throwing the error. Look at its Log On tab.
If it uses a specific account, re-enter the password in both fields and click OK.
Restart the service.

That fixes it about 70% of the time. The reason: Windows caches the service's credentials in the Local Security Authority (LSA) process. When the password changes externally, the cached copy is stale. Updating it in the service properties forces LSA to refresh.

If that doesn't work, check the certificate

Channel bindings rely on the server's TLS certificate. If the cert is self-signed, expired, or doesn't match the server's FQDN, the binding hash won't match what the client expects.

For LDAP over SSL, you'd see this often on domain controllers. The fix here is to replace the cert with one from a trusted CA, and make sure the subject name matches the DC's DNS name. If you're in a test lab, you can temporarily disable channel binding enforcement, but don't do that in production.

To check channel binding settings on a Windows Server:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LdapEnforceChannelBinding

If it returns 2, that's strict enforcement. Setting it to 1 or 0 might allow your client to connect, but again, understand the security implications.

Why This Works

What's actually happening here is a mismatch between the channel binding token (CBT) the client sends and the one the server computes. The CBT is a hash of the TLS certificate's public key and the endpoint's information. Both sides derive it independently. If they don't match, the server rejects with STATUS_BAD_BINDINGS.

When you update the service password, you're not directly affecting the binding. But the error can also be a symptom of authentication failure that the server reports as a binding error. Fixing the credentials resolves the underlying auth issue, and because the server evaluates bindings after authentication (or simultaneously), the error clears.

The certificate fix works because you're aligning the source of the CBT. If the server's cert changes, the client must have the new cert. If the client tries to use an old cached cert, the hash won't match. Updating the cert on both ends ensures the binding token computes correctly.

Less Common Variations

Here are a few other scenarios I've seen:

NTLM authentication over HTTP — If you're using Integrated Windows Authentication on IIS, and the client sends NTLM with channel bindings, but the server expects Kerberos or a different binding, you'll get this. The fix is to align the authentication protocols. Check the IIS site's authentication settings and disable NTLM if Kerberos is available.
SQL Server connections — When SQL Server uses SSPI and the service account password mismatch occurs, you get 0XC000035B. Updating the SQL Server service account password fixes it.
Citrix or Remote Desktop Services — RDP clients have been known to trigger this when the server's certificate is invalid. Ensure the RD Session Host uses a valid cert.
DCOM or WMI — Sometimes a scheduled task or script that uses WMI from a remote machine hits this if the machine's local policy requires channel bindings and the remote machine doesn't support them. You can adjust the policy in Local Security Policy under Network security: Restrict NTLM: Add remote server exceptions.

Each variation has the same root cause: the binding token doesn't match. The fix is about aligning credentials or certificates.

Prevention

To avoid this in the future:

Set service account passwords to never expire, or use Group Managed Service Accounts (gMSA). gMSA passwords rotate automatically and Windows updates them without breaking the service.
Use certificates from a trusted internal CA, and import them into the appropriate stores on both client and server.
Monitor certificate expiration. You can set up alerts in your monitoring tool.
Keep the channel binding enforcement as strict as possible, but know your environment. If you have old clients that don't support bindings, you'll need to relax it temporarily.

The real takeaway: 0XC000035B is almost always a credential or certificate problem, not some deep Windows internal. Chase those two things first and you'll waste a lot less time.