Warum verwendet MS SQL Server die NTLM-Authentifizierung?

Windows Server 2008 R2.

SQL Server 2008 R2 installiert.

Der MSSQL-Dienst wird als lokales System ausgeführt.

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

Ich starte dann SQL Server Management Studio und verbinde mich so 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 oder verwendet einen CNAME.

Das liegt daran, dass ich mich lokal mit dem SQL Server verbunden habe, und zwar von demselben Server, auf dem auch SQL Server gehostet wurde. Wenn ich eine Verbindung von einem anderen Computer im Netzwerk herstelle, wird erwartungsgemäß Kerberos als Authentifizierungsmechanismus verwendet.

SQL Server verwendet bei lokaler Verbindung immer NTLM. Kerberos wird nur verwendet, wenn eine Remoteverbindung besteht.

Dieser Beitrag aus dem SQL Server Protocols Blog ist zwar datiert, sagt aber dasselbe:

1) Kerberos wird beim Herstellen einer Remoteverbindung über TCP / IP verwendet, wenn SPN vorhanden ist.

2) Kerberos wird beim Herstellen einer lokalen TCP-Verbindung unter XP verwendet, wenn 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 eine TCP-Verbindung verwendet, wenn kein SPN gefunden wird.