Error "No se puede generar contexto SSPI" al usar la autenticación de Windows para conectarse a SQL Server

Se aplica a: SQL Server
Número KB original: 811889

Al usar la autenticación de Windows para conectar una instancia de SQL Server de forma remota, recibirá el siguiente mensaje de error:

El nombre principal de destino es incorrecto. No se puede generar contexto SSPI.

Preguntas frecuentes

¿Qué es SSPI?

La interfaz del proveedor de compatibilidad para seguridad (SSPI) es un conjunto de API de Windows que admiten la delegación y autenticación mutua sobre cualquier capa de transporte de datos genérica, como los sockets TCP/IP. Uno o varios módulos de software proporcionan las funcionalidades de autenticación reales. Cada módulo se denomina proveedor de compatibilidad para seguridad (SSP) y se implementa como una biblioteca de vínculos dinámicos (DLL).

¿Qué es Kerberos?

El protocolo Kerberos v5 es un paquete de seguridad estándar del sector y es uno de los tres paquetes de seguridad de los sistemas operativos Windows. Para obtener más información, consulte Proveedores de compatibilidad para seguridad (SSP).

¿Qué significa el error "No se puede generar contexto SSPI"?

Este error significa que SSPI intenta usar la autenticación Kerberos para delegar las credenciales de cliente a través de TCP/IP o canalizaciones con nombre a SQL Server, pero no puede. En la mayoría de los casos, un nombre de entidad de seguridad de servicio (SPN) mal configurado provoca este error.

¿Qué es SPN?

Los nombres de entidad de seguridad de servicio (SPN) son un identificador único de una instancia de servicio. La autenticación Kerberos usa los SPN para asociar una instancia de servicio a una cuenta de inicio de sesión de servicio. Este proceso de asociación permite a una aplicación cliente solicitar al servicio que autentique una cuenta incluso si el cliente no tiene un nombre de cuenta.

Por ejemplo, un SPN típico para un servidor que ejecuta una instancia de SQL Server es el siguiente:

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

El formato de un SPN para una instancia predeterminada y el formato de un SPN para una instancia con nombre son iguales. El número de puerto es lo que vincula al SPN a una instancia determinada. Para obtener más información sobre cómo registrar SPN de servicio SQL Server, consulte Registrar un nombre de entidad de servicio para conexiones Kerberos.

¿Por qué SSPI usa la autenticación NTLM o Kerberos?

La autenticación de Windows es el método preferido para que los usuarios se autentiquen en SQL Server. Los clientes que emplean la autenticación de Windows se autentican mediante NTLM o Kerberos.

Cuando un cliente de SQL Server utiliza la seguridad integrada sobre sockets de TCP/IP con un servidor remoto que está ejecutando SQL Server, la biblioteca de red del cliente de SQL Server utiliza la API SSPI para realizar la delegación de seguridad. El cliente de red de SQL Server efectúa una llamada a la función AcquireCredentialsHandle y "negocia" el parámetro pszPackage. Este proceso notifica al proveedor de seguridad subyacente que negocie la delegación. En este contexto, "negociar" significa probar la autenticación Kerberos o NTLM en equipos basados en Windows. En otras palabras, Windows utiliza la delegación Kerberos si el equipo de destino que ejecuta SQL Server tiene un SPN asociado y correctamente configurado. En caso contrario, Windows usa la delegación NTLM. Si el cliente SQL Server se conecta localmente en la misma máquina donde reside SQL Server, siempre se emplea NTLM.

¿Por qué la conexión no conmuta por error a NTLM después de tener problemas con Kerberos?

El código del controlador SQL Server en el cliente usa la API de red de WinSock para resolver el DNS completo del servidor cuando el controlador utiliza autenticación de Windows para conectarse a SQL Server. Para realizar esta operación, el código del controlador efectúa una llamada a las API WinSock gethostbyname y gethostbyaddr. Si se usa la seguridad integrada, el controlador intentará resolver el DNS completo del servidor, incluso si se pasa una dirección IP o un nombre de host como nombre del servidor.

Cuando el controlador de SQL Server del cliente resuelve el DNS completo del servidor, el DNS correspondiente se utiliza para formar el SPN del servidor. Por lo tanto, los problemas para resolver la dirección IP o el nombre de host a un DNS completo de WinSock pueden hacer que el controlador de SQL Server cree un SPN no válido para el servidor.

Por ejemplo, el controlador de SQL Server del lado cliente se puede usar como DNS completo para resolver SPN no válidos como se indica aquí:

• MSSQLSvc/SQLSERVER1:1433
• MSSQLSvc/123.123.123.123:1433
• MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
• MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Cuando el controlador de SQL Server forma un SPN no válido, la autenticación seguirá funcionando, puesto que la interfaz SSPI intentará encontrar el SPN en el servicio de Active Directory. Si la interfaz SSPI no localiza el SPN, no se realizará la autenticación Kerberos. En este punto, la capa SSPI cambiará al modo de autenticación NTLM y el inicio de sesión utilizará la autenticación NTLM, lo que normalmente tiene éxito. Si el controlador de SQL Server forma un SPN válido que no está asignado al contenedor adecuado, el controlador prueba el SPN, pero no puede usarlo. En este caso, puede producirse el error "No se puede generar contexto SSPI". Si la cuenta de inicio de SQL Server es una cuenta de sistema local, el contenedor adecuado es el nombre del equipo. En el caso de cualquier otra cuenta, el contenedor adecuado es la cuenta de inicio de SQL Server. La autenticación usa el primer SPN que encuentra, así que asegúrese de que ningún SPN esté asignado a contenedores incorrectos. En otras palabras, cada SPN debe asignarse a un solo contenedor.

¿Cómo puedo comprobar el método de autenticación de la conexión?

Para determinar el método de autenticación de una conexión, ejecute la siguiente consulta:

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;  

Para obtener más información, vea Determinar si estoy conectado a SQL Server mediante la autenticación Kerberos.

¿Cómo crear SPN para SQL Server?

Cuando se inicia una instancia del motor de base de datos de SQL Server, SQL Server intenta registrar automáticamente el SPN para el servicio de SQL Server mediante la API DsWriteAccountSpn. Esta llamada se realiza correctamente si la cuenta de servicio de SQL Server tiene derechos de lectura servicePrincipalName y escritura servicePrincipalName en Active Directory. De lo contrario, necesitará que el administrador de Active Directory registre manualmente el SPN correcto mediante Microsoft Kerberos Manager para SQL Server o la herramienta integrada setspn. Para obtener más información sobre cómo administrar SPN para SQL Server, consulte Registrar un nombre de entidad de servicio para conexiones Kerberos.

Corregir un error con Kerberos Configuration Manager (recomendado)

Hay varias razones por las que se produce un error en las conexiones Kerberos, como SPN mal configurados, problemas de resolución de nomenclatura o derechos insuficientes para las cuentas de inicio del servicio de SQL Server. Microsoft Kerberos Configuration Manager (KCM) es una herramienta que puede ayudar a comprobar las causas del error. KCM también proporciona opciones para corregir los problemas identificados en el proceso.

Siga estos pasos para corregir el error con KCM.

1. En el equipo donde tiene los problemas de conectividad, descargue e instale Kerberos Configuration Manager.

2. Inicie KerberosConfigMgr.exe desde la carpeta %SystemDrive%:\Archivos de programa\Microsoft\Kerberos Configuration Manager. A continuación, use una cuenta de dominio que tenga permisos para conectarse al equipo SQL Server al que no puede conectarse.

3. Seleccione Conectar, y deje blanco el nombre del servidor y otros detalles según corresponda a su escenario si va a ejecutar KCM en el equipo con SQL Server. Seleccione Conectar para realizar el análisis. Una vez que KCM termina de recuperar la información necesaria, cambia automáticamente a la pestaña SPN y, de forma predeterminada, muestra información para SQL Server, SQL Server Reporting Services, Analysis Services y los oyentes AG. Para solucionar este error, desactive todo excepto SQL Server.

4. Revise el diagnóstico de la herramienta con la columna Estado y siga los pasos pertinentes para resolver el problema:

   Estado	Más información	Acción
   Good	El elemento seleccionado está configurado correctamente. Puede continuar con el siguiente elemento de la salida.	No es necesario realizar ninguna acción
   Falta el SPN necesario	Este estado se notifica cuando falta el SPN identificado en la columna SPN necesario de la cuenta de inicio de SQL Server en Active Directory.	1. Seleccione Corregir para revisar la información en el cuadro de diálogo Advertencia. 2. Seleccione Sí para añadir el SPN que falta en Active Directory. 3. Si la cuenta de dominio tiene los permisos necesarios para actualizar Active Directory, el SPN necesario se agregará a Active Directory. 4. Si la cuenta de dominio no tiene los permisos necesarios para actualizar Active Directory, use Generar o Generar todo para generar el script que ayudará al administrador de Active Directory a agregar los SPN que faltan. 5. Una vez agregados los SPN, ejecute Kerberos Configuration Manager de nuevo para comprobar que se resuelven los problemas de SPN. 6. Además, puede usar los siguientes comandos: - Use SETSPN -Q spnName para localizar el SPN y sus cuentas actuales. - Use SETSPN -D para quitar el SPN de la cuenta incorrecta.
   El TCP debe estar habilitado para usar la configuración de Kerberos	Esto ocurre cuando el TCP no está habilitado en el equipo cliente.	Para habilitar el protocolo TCP/IP para la instancia de SQL Server, siga estos pasos: 1. En el administrador de configuración de SQL Server, en el panel consola, expanda Configuración de red de SQL Server. 2. En el panel consola, seleccione Protocolos para <instance name>. 3. En el panel detalles, haga clic con el botón derecho del ratón en TCP/IP y seleccione Habilitar. 4. En el panel de consola, seleccione SQL Server Services (Servicios SQL Server). 5. En el panel detalles, haga clic con el botón derecho en SQL Server (<instance name>) y seleccione Reiniciar para detener y reiniciar el servicio SQL Server. Para obtener más información, vea Habilitar o deshabilitar un protocolo de red de servidor.
   Puerto dinámico	Este mensaje se muestra para las instancias con nombre que usan puertos dinámicos (configuración predeterminada). En entornos en los que necesita utilizar Kerberos para conectarse a SQL Server, debe establecer la instancia con nombre en un puerto estático y emplear ese al registrar SPN.	Para configurar la instancia de SQL Server para utilizar un puerto estático, siga estos pasos: 1. En Administrador de configuración de SQL Server, en el panel consola, expanda Configuración de red de SQL Server, expanda Protocolos para <instance name> y luego haga doble clic en TCP/IP. 2. En el cuadro de diálogo Propiedades de TCP/IP, revise la opción Listen All (Escuchar todo) en la pestaña Protocolo. 3. Si la opción Listen All (Escuchar todo) está establecida en Sí, cambie a la pestaña Direcciones IP y desplácese hasta la parte inferior de Windows para encontrar la configuración IPAll. Elimine el valor actual contenido en TCP Dynamic Ports (Puertos dinámicos TCP) y establezca el valor deseado en el campo Puerto TCP. Seleccione Aceptar y reinicie la instancia de SQL Server para que la configuración surta efecto. 4. Si la configuración Listen All (Escuchar todo) está establecida en No, cambie a la pestaña Direcciones IP y compruebe cada una de las direcciones IP que aparecen en IP1, IP2. En el caso de las direcciones IP habilitadas, quite el valor actual contenido en el campo TCP Dynamic Ports (Puertos dinámicos TCP) y establezca el valor deseado en el campo Puerto TCP. Seleccione Aceptar y reinicie la instancia de SQL Server para que la configuración surta efecto. Para obtener más información, vea Configurar un servidor para escuchar en un puerto TCP específico.
   SPN duplicado	Puede encontrarse la situación cuando el mismo SPN se registra en cuentas diferentes en Active Directory.	1. Seleccione el botón Corregir, vea la información en el cuadro de diálogo Advertencia y seleccione Sí si puede añadir el SPN que falta a Active Directory. 2. Si la cuenta de dominio tiene los permisos necesarios para actualizar Active Directory, se eliminará el SPN incorrecto. 3. Si la cuenta de dominio no tiene los permisos necesarios para actualizar Active Directory, use el botón Generar o Generar todo para generar el script necesario que puede pasar al administrador de Active Directory para quitar los SPN duplicados. Una vez que se quiten los SPN, vuelva a ejecutar el KCM para comprobar que se resuelven los problemas del SPN.

   Nota:

   Si la cuenta de dominio que inicia KCM no tiene privilegios para manipular SPN en Active Directory, puede usar el botón Generar o Generar todo correspondiente de la columna SPN script (Script SPN) para generar los comandos necesarios. Colabore con el administrador de Active Directory para corregir los problemas identificados por KCM.

5. Después de corregir todos los problemas identificados en KCM, vuelva a ejecutar la herramienta. Asegúrese de que no se notifica ningún otro problema y reintente la conexión. Si la herramienta sigue notificando problemas, repita el procedimiento anterior.

Corregir el error sin Kerberos Configuration Manager

Si no puede usar KCM, siga estos pasos:

Paso 1: Comprobar la resolución de nombres con el comando ping

La clave del éxito de la autenticación de Kerberos es la funcionalidad de los DNS válidos en la red. Puede comprobar esta funcionalidad en el cliente y en el servidor con la utilidad de símbolo del sistema Ping. En el equipo cliente, ejecute el comando siguiente para obtener la dirección IP del servidor que ejecuta SQL Server (donde el nombre del equipo es SQLServer1):

ping sqlserver1

Para ver si la utilidad de Ping resuelve el DNS completo de SQLServer1, ejecute el comando siguiente:

ping -a <IPAddress>

Por ejemplo:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

Cuando el comando ping -a <IPAddress> se resuelve como el DNS completo correcto del equipo que ejecuta SQL Server, la resolución en el lado cliente también es correcta.

Para diagnósticos detallados, use el cmdlet Test-NetConnection o Test-Connection para probar la conectividad TCP según la versión de PowerShell instalada en el equipo. Para obtener más información sobre el cmdlet de PowerShell, consulte Información general sobre cmdlet.

Compruebe si existen alias para el SQL Server de destino en el Administrador de configuración de SQL Server y en Client Network Utility de SQL Server. Si existe este alias, asegúrese de que está configurado correctamente comprobando los nombres de servidor, el protocolo de red, el número de puerto, etc. Un alias de SQL Server podría hacer que se generara un SPN inesperado. Esto dará lugar a credenciales NTLM si no se encuentra el SPN, o un error de SSPI, si coincide involuntariamente con el SPN de otro servidor.

Paso 2: Comprobar la comunicación entre dominios

Compruebe si el dominio en el que inicia sesión puede comunicarse con el dominio del servidor que ejecuta SQL Server. También debe haber una resolución de nombres adecuada en el dominio.

1. Asegúrese de que puede iniciar sesión en Windows con la misma cuenta de dominio y contraseña que la cuenta de inicio del servicio SQL Server. Por ejemplo, puede producirse el error SSPI en una de las siguientes situaciones:

   • La cuenta de dominio está bloqueada.
   • No ha vuelto a reiniciar el servicio SQL Server después de cambiar la contraseña de la cuenta.

2. Si el dominio al que se conecta es distinto del dominio al que pertenece el servidor que está ejecutando SQL Server, compruebe la relación de confianza entre ambos dominios.

3. Compruebe si el dominio al que pertenece el servidor y la cuenta de dominio que usted utiliza para conectarse están en el mismo bosque. Este paso es necesario para que la SSPI funcione.

Paso 3: Comprobar SQL Server SPN mediante las herramientas SQLCHECK y Setspn

Si puede iniciar sesión localmente en el equipo SQL Server y tener acceso de administrador, use SQLCHECK. SQLCheck proporciona la mayor parte de la información necesaria para solucionar los problemas en un archivo. Para obtener más información sobre cómo usar la herramienta y qué información recopila, revise la página principal de la herramienta. También puede leer la página de los requisitos previos y la lista de comprobación recomendados. Una vez generado el archivo de salida, revise la configuración de SPN para la instancia de SQL Server en la sección información de SQL Server del archivo de salida.

Ejemplo de resultado:

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

Use la salida anterior para determinar los pasos siguientes (consulte los siguientes ejemplos) y use la herramienta Setspn para realizar las acciones correctivas necesarias para solucionar los problemas de SPN.

Paso 4: comprobar el permiso de cuenta para la cuenta de inicio de SQL Server en el servidor vinculado

Si usa Suplantar como opción de autenticación en la página Seguridad del servidor vinculado, se requiere SQL Server para que se acepten las credenciales entrantes a la SQL Server remota. La cuenta de inicio de sesión de SQL Server, donde se define el servidor vinculado debe tener Se confía en la cuenta para su delegación asignado correctamente en Active Directory. Para obtener más información, consulte Habilitar confianza con el equipo y las cuentas de usuario para delegación.

Vea también

• Solucionar problemas de conectividad en SQL Server
• Solucionar problemas de autenticación sistemáticos
• Herramienta de cliente SSPI
• Habilitar el registro de eventos kerberos
• Cómo hacer que Kerberos use TCP en lugar de UDP en Windows