dbatools 2.8.4 ergänzt Accepted-SPN-Unterstützung in `Set-DbaExtendedProtection`. Damit schließt sich eine Automationslücke für SQL Server Extended Protection, die Windows-authentifizierte Verbindungen gegen Credential Relay absichert. Das Cmdlet kann die Kontrolle setzen, doch der sichere Rollout beginnt mit der Frage, welche Namen Clients tatsächlich verwenden und welchen Servicekonten sie gehören.
Bedeutung für den Betrieb
Der Bestand enthält SQL-Service-SPNs, Aliase, CNAMEs, Load Balancer, Availability-Group-Listener, Failover-Clusternamen, benannte Instanzen, Ports und delegierte Servicekonten. Doppelte, fehlende oder unerwartete SPNs können bereits heute Kerberos-Fallback verursachen. Enforcement vor der Korrektur dieser Pfade macht verborgene NTLM-Nutzung zu einem sichtbaren Produktionsausfall.
Ein gestufter Ansatz beginnt mit TLS- und Zertifikatszustand, aktiviert dann die weniger strenge Betriebsart und beobachtet das Clientverhalten. Getestet werden lokale und entfernte Administration, Application Pools, geplante Jobs, verbundene Systeme, Reportingwerkzeuge, alte Treiber, Listener und Failover. Channel Binding Tokens und Accepted SPNs müssen zu den realen Verbindungswegen passen.
Automation erfasst aktuelle Einstellung, vorgeschlagene SPNs, Ziele, Ergebnisse und Rückfallwerte. Änderungen erfolgen in kontrollierten Ringen und Verbindungsbelege bleiben erhalten. Für einen Legacy-Client braucht es einen dokumentierten Ausnahmeweg mit Eigentümer und Enddatum, statt die gesamte Instanz dauerhaft zu schwächen.
Praktische Konsequenz
Die praktische Konsequenz: Extended Protection ist eine Identitäts- und Anwendungsmigration, keine einzelne SQL-Einstellung. SPN-Inventar aufbauen, Kerberos-Pfade reparieren, echte Clients testen und bewusst von Beobachtung zu Enforcement wechseln. Der Schalter ist einfach; der Nachweis jedes Namens und Verbindungswegs ist die eigentliche Security-Arbeit.