Pourquoi MS SQL Server utilise-t-il l'authentification NTLM?

Windows Server 2008 R2.

SQL Server 2008 R2 installé.

Le service MSSQL s'exécute en tant que système local.

Le nom de domaine complet du serveur est SQL01.domain.com.

SQL01 est joint à un domaine Active Directory nommé domain.com.

Voici la sortie de 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

Je lance ensuite SQL Server Management studio et me connecte à SQL01 de la manière suivante:

J'exécute ensuite la requête suivante:

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid 

Et le résultat est NTLM. Pourquoi le résultat n'est-il pas Kerberos? Les SPN semblent être corrects pour utiliser le compte système local. Le serveur n'est pas dans un cluster ou utilise un CNAME.

C'est parce que je me connectais au SQL Server localement, à partir du même serveur qui hébergeait SQL Server. Lorsque je me connecte à partir d'une autre machine sur le réseau, le mécanisme d'authentification utilisé est Kerberos, comme prévu.

SQL Server utilisera toujours NTLM lors de la connexion locale. Kerberos n'est utilisé qu'en cas de connexion à distance.

Ce post du blog SQL Server Protocols , bien que daté, dit la même chose:

1) Kerberos est utilisé lors d'une connexion à distance via TCP / IP si SPN est présent.

2) Kerberos est utilisé lors de l'établissement d'une connexion TCP locale sur XP si SPN est présent.

3) NTLM est utilisé lors de l'établissement d'une connexion locale sur WIN 2K3.

4) NTLM est utilisé sur une connexion NP.

5) NTLM est utilisé sur une connexion TCP s'il n'est pas trouvé SPN.