Windows Server 2008 R2.
SQL Server 2008 R2 installiert.
Der MSSQL-Dienst wird als lokales System ausgeführt.
Der Server-FQDN ist SQL01.domain.com.
SQL01 ist einer Active Directory-Domäne mit dem Namen domain.com beigetreten.
Das Folgende ist die Ausgabe von setspn:
C:\> setspn -L sql01
...
MSSQLSvc/SQL01.domain.com:1433
MSSQLSvc/SQL01.domain.com
WSMAN/SQL01.domain.com
WSMAN/SQL01
TERMSRV/SQL01.domain.com
TERMSRV/SQL01
RestrictedKrbHost/SQL01
RestrictedKrbHost/SQL01.domain.com
HOST/SQL01.domain.com
HOST/SQL01
Dann starte ich SQL Server Management Studio und verbinde mich folgendermaßen mit SQL01:
Ich führe dann die folgende Abfrage aus:
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid
Und das Ergebnis ist NTLM. Warum ist das Ergebnis nicht Kerberos? Die SPNs scheinen für die Verwendung des lokalen Systemkontos korrekt zu sein. Der Server befindet sich nicht in einem Cluster und verwendet keinen CNAME.
Antwort1
Das liegt daran, dass ich mich lokal mit dem SQL Server verbunden habe, und zwar von demselben Server aus, auf dem auch SQL Server gehostet wurde. Wenn ich mich von einem anderen Computer im Netzwerk aus verbinde, wird wie erwartet Kerberos als Authentifizierungsmechanismus verwendet.
SQL Server verwendet bei lokalen Verbindungen immer NTLM. Kerberos wird nur bei Remoteverbindungen verwendet.
Dieser Beitrag aus demSQL Server-Protokolle-Blog, obwohl veraltet, sagt das Gleiche:
1) Kerberos wird beim Herstellen einer Remote-Verbindung über TCP/IP verwendet, sofern SPN vorhanden ist.
2) Kerberos wird beim Herstellen einer lokalen TCP-Verbindung unter XP verwendet, sofern SPN vorhanden ist.
3) NTLM wird beim Herstellen einer lokalen Verbindung unter WIN 2K3 verwendet.
4) NTLM wird über eine NP-Verbindung verwendet.
5) NTLM wird über die TCP-Verbindung verwendet, wenn kein SPN gefunden wird.