Extended Protection for SQL Server: Why One Setting Depends on Five Others

What Extended Protection Actually Does

Extended Protection for Authentication (EPA) is a Windows authentication hardening feature, not a SQL Server-specific one; SQL Server just exposes a setting that turns it on for its own connections. It bundles two separate protections against NTLM relay and credential-forwarding attacks:

Channel Binding Tokens (CBT): ties the authentication handshake to the specific TLS channel it happened on. An attacker who intercepts and relays the authentication attempt over a different connection gets rejected, because the channel binding token won't match.
Service Binding: ties the authentication to the specific service (its SPN) the client meant to talk to, so a captured authentication attempt can't be replayed against a different service under a different account.

Channel Binding is the part that actually needs a TLS channel to bind to. That single dependency is why this "one setting" pulls in almost everything else on this page.

The Setting Itself

Extended Protection is configured per instance in SQL Server Configuration Manager, under SQL Server Network Configuration → Protocols for <instance> → Advanced tab, alongside Force Encryption and Certificate. It has three states:

Value	Behavior
Off	No channel/service binding checked. Default on most existing instances.
Allowed	Accepts both EPA-aware and non-EPA-aware connections. EPA-capable clients get the protection; older clients still connect normally.
Required	Rejects any connection that doesn't negotiate Extended Protection. This is where an incomplete rollout turns into an outage.

The Bundle: What Has to Be True First

Setting the value to Required is the last step, not the first. Everything below has to be in place, or that last step just breaks things instead of securing them.

Force Encryption + a real certificate	Channel Binding Tokens are derived from the TLS channel, so Extended Protection is only meaningful with encryption actually on. The certificate has to be properly deployed and trusted by every client, not SQL Server's own auto-generated self-signed certificate, which most client machines won't trust uniformly.
Clean SPN registration	Service Binding ties authentication to the SPN of the service being reached. Missing, duplicate, or misassigned SPNs already break Kerberos on their own; layering Extended Protection on top of a shaky SPN setup just adds a second, harder-to-diagnose failure mode on top of the first.
Client / driver support	The connecting driver has to negotiate EPA itself. Older ODBC, OLE DB, or SqlClient versions don't. Under `Required`, any client on an unsupported driver simply stops connecting, with no useful error pointing back at Extended Protection as the cause.
Network path between client and server	Anything that terminates and re-originates TLS in between, a load balancer, a proxy, some multi-hop routing, means the client and the server are actually on two different TLS channels. Channel binding then legitimately fails even for a fully legitimate connection, and `Required` rejects it. Worth checking explicitly against AG listener topology.

🔧 The SPN prerequisite has its own tooling: Extended Protection's Service Binding half depends on SPNs already being correct, so start there. sqmSQLTool's Get-sqmSPNReport audits registered vs. expected SPNs across every instance on a server, including AlwaysOn listener SPNs, and hands back ready-to-run setspn -S commands for anything missing. Background on why SPNs matter for Windows Authentication in the first place: Kerberos and SPN: Windows Authentication Deep Dive.

⚠ The Required trap: setting Extended Protection to Required instance-wide before confirming every client and driver actually supports it doesn't harden the instance, it takes it offline for whatever wasn't ready. Move to Required only after a period on Allowed where you've actually confirmed which connections negotiated EPA and which didn't.

Checking What's Actually Connecting

Before touching the setting, find out what's currently connecting to the instance and how. A quick inventory from sys.dm_exec_connections and sys.dm_exec_sessions shows the client network address, program name, and login for every active session, enough to build a real list of applications and driver versions to check off against EPA support, instead of guessing.

SELECT
    s.login_name,
    s.program_name,
    s.host_name,
    c.client_net_address,
    c.encrypt_option,
    c.auth_scheme
FROM sys.dm_exec_sessions AS s
JOIN sys.dm_exec_connections AS c
    ON s.session_id = c.session_id
WHERE s.is_user_process = 1
ORDER BY s.program_name;

encrypt_option tells you which sessions aren't even encrypted yet, those are guaranteed failures the moment Extended Protection moves past Off. auth_scheme shows whether a session actually negotiated Kerberos, worth cross-checking against your SPN report if it says NTLM where you expected Kerberos.

Rollout Order

☐ Turn on Force Encryption with a properly deployed, trusted certificate, not the auto-generated one
☐ Run an SPN audit (Get-sqmSPNReport) and fix anything missing or duplicated
☐ Inventory current connections (sys.dm_exec_connections) for client program names, driver versions, and encryption status
☐ Map the network path for every listener, including AG listeners, for anything that terminates TLS in between
☐ Set Extended Protection to Allowed, not Required, as the first live step
☐ Confirm which connections actually negotiated EPA before assuming the rest will too
☐ Only then move to Required, and only on instances where every client checked out

The Bottom Line

Extended Protection is a real, worthwhile hardening step against NTLM relay attacks, and Microsoft's recommendation to enable it is reasonable. But it's a rollout, not a checkbox: it only works once encryption, certificates, SPNs, client drivers, and the network path all agree with each other. Treat Required as the destination after that verification, not the first thing you set.

← Back to Blog