Lo primero, es tener claro que el error Cannot Generate SSPI context, parece estar relacionado (a priori) con:
- Autenticación Integrada, utilizando Kerberos. Esta claro. Con atenticación SQL Server, va como la seda.
- Conexiones a una instancia SQL Server utilizando el protocolo TCP/IP. Esta claro. Con el protocolo Named Pipes, el error Cannot Generate SSPI context, ni lo hueles.
- Una instancia de SQL Server que se inicia con una cuenta de Dominio. Esto con el tiempo, se empieza a sospechar, pero vamos, muy claro no está.
Por otro lado, desde el punto de vista de la teoría, deberíamos saber que Security Support Provider Interface (SSPI) es una API que facilita la Delegación y Autenticación Mutua sobre una capa de transporte de datos (ej: TCP/IP). Además, el Driver de SQL Server, al utilizar Autenticación Integrada, utiliza la delegación, pudiendo utilizar diferentes mecanismos:
- NTLM sobre Named Pipes sin SSPI.
- NTLM sobre TCP/IP con SSPI.
- Kerberos sobre TCP/IP con SSPI.
Sin profundizar demasiado, llegados a este punto, con lo que nos debemos quedar, es con que el error Cannot Generate SSPI context se produce al utilizar Kerberos sobre TCP/IP con SSPI como mecanismo de delegación y/o autenticación.
Con esto, ya se puede empezar a intuir una posible solución fácil (Workaround o ñapa): utilizar Named Pipes como protocolo (en vez de TCP/IP), para así esquivar la utilización de Kerberos.
Sin embargo, surge una nueva duda: Al utilizar el protoco TCP/IP para conectar con SQL Server con Autenticación Integrada ¿Cuándo se utiliza NTLM o cuando se utiliza Kerberos? Lo primero, tendremos que saber qué es un Service Principal Name (SPN), bueno, que nos suene.
Un Service Principal Name (SPN) es un identificador único en un bosque o dominio de Directorio Activo, una forma de identificar o direccionar un Servicio o Recurso de Red en el Directorio Activo (vaya con el Directorio Activo de los cojones… y yo que pensaba que sólo valía para hacer Logon ;-). También debemos de saber, que todos los Service Principal Name (SPN) se registran en Directorio Activo (bueno, yo he llegado a esta conclusión, espero no estar confundido).
Un Service Principal Name (SPN) está formado por:
- Una clase de servicio (ServiceClass). Ej: MSSQLSvc, HTTP, HOST, etc.
- Un Host. Ej: vsql01.guillesql.local.
- Un Puerto: Ej: 1433.
Así, un ejemplo de un Service Principal Name (SPN) para una instancia de SQL Server escuchando en el puerto 1433 en un servidor cuyo FQDN es vsql01.guillesql.local, sería el siguiente: MSSQLSvc/vsql01.guillesql.local:1433
Además, un Service Principal Name (SPN) se asocia a un equipo o a un usuario (mejor dicho, a una cuenta de equipo o a una cuenta de usuario de Directorio Activo). A esto volveremos más tarde, de momento que nos suene.
Posibles causas:
- Problemas o errores de resolución de nombres DNS, siendo recomendable disponer de una correcta resolución directa y resolución inversa.
- Existencia de Directorio Activo de Service Principal Name (SPN) inválidos o asociados a Contenedores erróneos. Cabe destacar, el caso particular de las instancias de SQL Server que se inician con una cuenta de Directorio Activo que no sea Administrador de Dominio, las cuales, pueden no conseguir registrar correctamente su Service Principal Name (SPN) en Directorio Activo. Este es mi caso.
Solucion:
setspn -A MSSQLSvc/VSQL01:1433
Via: GuilleSQL
