dbatools 2.8.4 adds accepted-SPN support to `Set-DbaExtendedProtection`. That closes an automation gap for SQL Server Extended Protection, which helps defend Windows-authenticated connections against credential relay. The cmdlet can configure the control, but a safe rollout begins with knowing which names clients actually use and which service accounts own them.
Why it matters in production
The inventory includes SQL service SPNs, aliases, CNAMEs, load balancers, availability-group listeners, failover-cluster names, named instances, ports, and delegated service accounts. Duplicate, missing, or unexpected SPNs can already cause Kerberos fallback. Enforcing Extended Protection before correcting those paths can turn hidden NTLM use into a visible production outage.
A staged approach starts with TLS and certificate health, then enables the less restrictive mode and monitors client behavior. Test local and remote administration, application pools, scheduled jobs, linked systems, reporting tools, old drivers, listeners, and failover. Channel Binding Tokens and accepted SPNs must match the connection paths in the real estate, not only a direct SSMS test against one node.
Automation should capture current settings, proposed accepted SPNs, targets, results, and rollback values. Apply changes through controlled rings and retain connection evidence. Teams need a documented exception path for a legacy client, including owner and retirement date, rather than weakening the entire instance indefinitely.
Practical takeaway
The practical takeaway is that Extended Protection is an identity and application migration, not a single SQL setting. Build the SPN inventory, repair Kerberos paths, test real clients, and move from observation to enforcement deliberately. The switch is straightforward; proving every accepted name and connection path is the actual security work.