Dlaczego MS SQL Server korzysta z uwierzytelniania NTLM?

Windows Server 2008 R2.

Zainstalowany SQL Server 2008 R2.

Usługa MSSQL działa jako system lokalny.

Nazwa FQDN serwera to SQL01.domain.com.

SQL01 jest przyłączony do domeny Active Directory o nazwie domain.com.

Oto wynik działania 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

Następnie uruchamiam studio SQL Server Management Studio i w ten sposób łączę się z SQL01:

Następnie uruchamiam następujące zapytanie:

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

Rezultatem jest NTLM. Dlaczego wynik nie jest Kerberos? Nazwy SPN wydają się poprawne do korzystania z lokalnego konta systemowego. Serwer nie znajduje się w klastrze ani nie używa CNAME.

To dlatego, że łączyłem się lokalnie z SQL Server, z tego samego serwera, na którym był zainstalowany SQL Server. Gdy łączę się z innego komputera w sieci, stosowanym mechanizmem uwierzytelniania jest Kerberos, zgodnie z oczekiwaniami.

SQL Server zawsze używa NTLM, jeśli łączy się lokalnie. Kerberos jest używany tylko w przypadku zdalnego połączenia.

Ten post z bloga protokołów SQL Server , choć datowany, mówi to samo:

1) Kerberos jest używany podczas nawiązywania połączenia zdalnego przez TCP / IP, jeśli występuje SPN.

2) Kerberos jest używany podczas nawiązywania lokalnego połączenia TCP na XP, jeśli występuje SPN.

3) NTLM jest używany podczas nawiązywania lokalnego połączenia z WIN 2K3.

4) NTLM jest używany przez połączenie NP.

5) NTLM jest używany przez połączenie TCP, jeśli nie znaleziono SPN.