
Servidor Windows 2008 R2.
SQL Server 2008 R2 instalado.
El servicio MSSQL se ejecuta como sistema local.
El FQDN del servidor es SQL01.dominio.com.
SQL01 está unido a un dominio de Active Directory denominado dominio.com.
El siguiente es el resultado 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
Luego lanzo SQL Server Management Studio y me conecto a SQL01 de la siguiente manera:
Luego ejecuto la siguiente consulta:
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid
Y el resultado es NTLM. ¿Por qué el resultado no es Kerberos? Los SPN parecen ser correctos para usar la cuenta del sistema local. El servidor no está en un clúster ni utiliza un CNAME.
Respuesta1
Es porque me estaba conectando a SQL Server localmente, desde el mismo servidor que alojaba SQL Server. Cuando me conecto desde otra máquina de la red, el mecanismo de autenticación utilizado es Kerberos, como se esperaba.
SQL Server siempre utilizará NTLM si se conecta localmente. Kerberos sólo se utiliza si se conecta de forma remota.
Esta publicación de laBlog de protocolos de SQL Server, aunque anticuado, dice lo mismo:
1) Kerberos se utiliza al realizar una conexión remota a través de TCP/IP si se presenta SPN.
2) Kerberos se utiliza al realizar una conexión TCP local en XP si se presenta SPN.
3) NTLM se utiliza al realizar una conexión local en WIN 2K3.
4) NTLM se utiliza sobre una conexión NP.
5) NTLM se utiliza a través de una conexión TCP si no se encuentra SPN.