
Servidor Windows 2008 R2.
SQL Server 2008 R2 instalado.
O serviço MSSQL é executado como sistema local.
O FQDN do servidor é SQL01.domain.com.
SQL01 está associado a um domínio do Active Directory denominado domain.com.
A seguir está a saída 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
Em seguida, inicio o SQL Server Management Studio e me conecto ao SQL01 da seguinte maneira:
Em seguida, executo a seguinte consulta:
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid
E o resultado é NTLM. Por que o resultado não é Kerberos? Os SPNs parecem estar corretos para usar a conta do Sistema Local. O servidor não está em um cluster ou usando um CNAME.
Responder1
É porque eu estava me conectando ao SQL Server localmente, no mesmo servidor que hospedava o SQL Server. Quando me conecto de outra máquina na rede, o mecanismo de autenticação utilizado é o Kerberos, conforme o esperado.
O SQL Server sempre usará NTLM se estiver conectado localmente. Kerberos só é usado se estiver conectado remotamente.
Esta postagem doBlog de protocolos do SQL Server, embora desatualizado, diz a mesma coisa:
1) Kerberos é usado ao fazer conexão remota via TCP/IP se o SPN estiver presente.
2) Kerberos é usado ao fazer conexão tcp local no XP se o SPN estiver presente.
3) NTLM é usado ao fazer conexão local no WIN 2K3.
4) NTLM é usado em conexão NP.
5) NTLM é usado na conexão TCP se o SPN não for encontrado.