Mit SQL Server 2008 werden die SPN's (Service Principal Name) durch den Dienst im  Kontext des Dienstekontos beim Starten von SQL Server Service selbständig gesetzt. Das Gleiche gilt für das Löschen der SPN Einträge. Dies erfolgt beim Stoppen der SQL Server Dienstes. Zur Überprüfung ob dies erfolgreich durchgeführt wird kann man das SQL Errorlog nach folgenden Einträgen durchsuchen:

 <The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SQLINSTANZ1.mix.dom:62201 ] for the SQL Server service.>

und

<The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SQLINSTANZ1.mix.dom:BASQLMOM ] for the SQL Server service.> 

Eine weitere Möglichkeit zur Überprüfung der auf das SQL Server Dienstekonto registrierten "Service Principal Name" bietet das Tool setspn : setspn -L <Kontoname oder Maschinenkonto bei local System>.

Es werden zwei Einträge durch den SQL Service erstellt: <MSSQLSVC/Rechnername.Domänensuffix:Instanzname> und <MSSQLSVC/Rechnername.Domänensuffix:TCP Port>. Hat man Applikationen, die einen Zugriff über Netbiosnamenskonvention durchführt, so muss man die beiden Einträge ohne Domänensuffix händisch mit setspn -D <MSSQLSVC/Rechnername:Instanzname Kontoname> und setspn -D <MSSQLSVC/Rechnername:TCP Port Kontoname> registrieren. Verfügt das SQL Dienstekonto nicht über die Berechtigung SPN's zu erstellen, müssen die vollqulifizierten Einträge ebenfalls händisch angelegt werden. Möchte man, dass dies künftig automatisch per SQL Server Dienstekonto möglich wird (und man ist nicht Domänen Administrator oder Local System) so kann man mit dem ADSI Edit Werkzeug auf das Objekt (Dienstekonto) "selbst" das Recht Service Principal Name schreiben eintragen. Es ist auch unbedingt darauf zu achten, dass nicht versehentlich mehrere SPN Registrierungen für das Dienstekonto in Bezug auf die gleiche SQL Instanz existieren. Mit dem Befehl setspn -X kann man doppelte Einträge identifizieren und dann mit setspn -A löschen.

Emfehlung zu  SPN Registrierung und SQL Server zum Nachlesen unter: http://technet.microsoft.com/en-us/library/ms191153.aspx, http://msdn.microsoft.com/en-us/library/ms191153(v=SQL.100).aspx

Zur Überprüfung der Verbindungseigenschaften auf NTLM oder Kerberos hilft nachfolgender Befehl, den man im SQL Management Studio ausführen kann. Er zeigt die Verbindung der aktuellen Session an:

SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Achtung: Hierbei ist darauf zu achten, dass die Verbindung nicht auf der gleichen Maschine mit dem SQL Service hergestellt wird, z.B. über das Manamgent Studio. Der Aufruf muss remote ausgeführt werden, da lokale Verbindungen immer mit NTLM authentifiziert werden.

Um alle Verbindungen zu sehen eignet sich folgende Abfrage - hierdurch ist auch gut zu sehen, dass lokale Verbinungen im Kontext NTLM verifiziert werden:

SELECT
    s.session_id,
    c.connect_time,
    s.login_time,
    s.login_name,
    c.protocol_type,
    c.auth_scheme,
    s.HOST_NAME,
    s.program_name
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_connections c
ON s.session_id = c.session_id

Informationen zu Kerberos und SSAS (SQL Server Analysis Services) unter: http://support.microsoft.com/kb/917409/en-us 

Informationen zu Delegierung: http://support.microsoft.com/kb/907272/en-us


Ein Dokument mit der Beschreibung und den Voraussetzungen ist in meinem anderen BLOG Beitrag zu finden: http://blogs.technet.com/technet_blog_images/b/sql_server_sizing_ha_and_performance_hints/archive/2011/10/20/microsoft-sql-server-kerberos-constrained-delegation.aspx