Error "No se puede generar el contexto de SSPI" al usar autenticación de Windows para conectarse SQL Server
Se aplica a: SQL Server
Número de KB original: 811889
Nota
Antes de empezar a solucionar problemas, se recomienda comprobar los requisitos previos y revisar la lista de comprobación.
Al usar autenticación de Windows para conectar una instancia de SQL Server de forma remota, recibirá el siguiente mensaje de error:
El nombre de la entidad de seguridad de destino es incorrecto. No se puede generar el contexto SSPI.
Preguntas frecuentes
¿Qué es SSPI?
La interfaz del proveedor de soporte técnico de seguridad (SSPI) es un conjunto de API de Windows que permite la delegación y autenticación mutua sobre cualquier capa de transporte de datos genérico, 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 soporte técnico de 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, vea Proveedores de soporte técnico de seguridad (SSP).
¿Qué significa el error "No se puede generar el contexto SSPI"?
Este error significa que SSPI intenta pero no puede usar la autenticación Kerberos para delegar las credenciales de cliente a través de TCP/IP o canalizaciones con nombre a SQL Server. 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 es el mismo que un SPN para una instancia con nombre. El número de puerto es lo que vincula el SPN a una instancia determinada. Para obtener más información sobre cómo registrar SQL Server SPN de servicio, consulte Registro de un nombre de entidad de seguridad de servicio para conexiones Kerberos.
¿Por qué SSPI usa la autenticación NTLM o Kerberos?
autenticación de Windows es el método preferido para que los usuarios se autentiquen para SQL Server. Los clientes que usan autenticación de Windows se autentican mediante NTLM o Kerberos.
Cuando un cliente de SQL Server usa la seguridad integrada a través de sockets TCP/IP en un servidor remoto que ejecuta SQL Server, la biblioteca de red cliente SQL Server usa la API de SSPI para realizar la delegación de seguridad. El cliente de red SQL Server realiza una llamada a la función AcquireCredentialsHandle y pasa "negotiate" para el pszPackage parámetro . 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 usa la delegación kerberos si el equipo de destino que ejecuta SQL Server tiene un SPN asociado y configurado correctamente. De lo 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 usa 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 usa autenticación de Windows para conectarse a SQL Server. Para realizar esta operación, el código del controlador llama a las gethostbyname API de WinSock 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, se usa el DNS correspondiente para formar el SPN del servidor. Por lo tanto, los problemas al resolver la dirección IP o el nombre de host en 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 a continuación:
MSSQLSvc/SQLSERVER1:1433MSSQLSvc/123.123.123.123:1433MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433
Cuando el controlador de SQL Server forma un SPN no válido, la autenticación sigue funcionando porque la interfaz SSPI intenta buscar el SPN en el servicio Active Directory. Si la interfaz SSPI no encuentra el SPN, no se realiza la autenticación Kerberos. En ese momento, la capa SSPI cambia al modo de autenticación NTLM y el inicio de sesión usa la autenticación NTLM y normalmente se realiza correctamente. 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 un error "No se puede generar el contexto SSPI". Si la cuenta de inicio de SQL Server es una cuenta del sistema local, el contenedor adecuado es el nombre del equipo. Para cualquier otra cuenta, el contenedor adecuado es la cuenta de inicio 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 solo debe asignarse a un 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 consulta siguiente:
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 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 setspn integrada. Para obtener más información sobre cómo administrar SPN para SQL Server, consulte Registro de un nombre de entidad de seguridad de servicio para conexiones Kerberos.
Corrección del error con Configuration Manager Kerberos (recomendado)
Nota
Este procedimiento solo se aplica a situaciones en las que recibe estos mensajes de error todo el tiempo, no de forma intermitente.
Hay varias razones por las que se produce un error en las conexiones Kerberos, como spns mal configurados, problemas de resolución de nombres o derechos insuficientes para SQL Server cuentas de inicio del servicio. 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 mediante KCM.
En el equipo donde tiene los problemas de conectividad, descargue e instale kerberos Configuration Manager.
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.
Seleccione Conectar, dejando en blanco el nombre del servidor y otros detalles según corresponda al escenario si ejecuta KCM en el equipo 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 los agentes de escucha de SQL Server, SQL Server Reporting Services, Analysis Services y AG. Para solucionar este error, desactive todo excepto SQL Server.
Revise el diagnóstico de la herramienta mediante 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 requerido para la cuenta de inicio SQL Server en Active Directory. 1. Seleccione Corregir para revisar la información en el cuadro de diálogo Advertencia .
2. Seleccione Sí para agregar el SPN que falta a 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.TCP debe estar habilitado para usar la configuración de Kerberos. Esto ocurre cuando 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 Administrador de configuración de SQL Server, en el panel de consola, expanda SQL Server Configuración de red.
2. En el panel de consola , seleccione Protocolos para <instance name>.
3. En el panel de detalles , haga clic con el botón derecho en TCP/IP y, a continuación, seleccione Habilitar.
4. En el panel de consola, seleccione SQL Server Services.
5. En el panel de detalles, haga clic con el botón derecho en SQL Server (<instance name>) y, a continuación, seleccione Reiniciar para detener y reiniciar el servicio de 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 usar Kerberos para conectarse a SQL Server, debe establecer la instancia con nombre en un puerto estático y usar ese puerto al registrar SPN. Para configurar la instancia de SQL Server para que use un puerto estático, siga estos pasos:
1. En Administrador de configuración de SQL Server, en el panel de consola, expanda SQL Server Configuración de red, expanda Protocolos para <instance name>y, a continuación, haga doble clic en TCP/IP.
2. En el cuadro de diálogo Propiedades de TCP/IP , revise la opción Escuchar todo en la pestaña Protocolo .
3. Si la opción 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 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 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 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 encontrar 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 agregar 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 entregar al administrador de Active Directory para quitar los SPN duplicados. Una vez que se quitan 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 de script SPN para generar los comandos necesarios y trabajar con el administrador de Active Directory para corregir los problemas identificados por KCM.
Después de corregir todos los problemas identificados en el KCM, vuelva a ejecutar la herramienta. Asegúrese de que no se notifica ningún otro problema y vuelva a intentar la conexión. Si la herramienta sigue notificando problemas, repita el procedimiento anterior.
Corrección del error sin Configuration Manager Kerberos
Si no puede usar KCM, siga estos pasos:
Paso 1: Comprobar la resolución de nombres con el comando ping
El factor clave que hace que la autenticación Kerberos sea correcta es la funcionalidad de DNS válida en la red. Puede comprobar esta funcionalidad en el cliente y el servidor mediante la utilidad del símbolo del Ping sistema. En el equipo cliente, ejecute el siguiente comando 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 Ping resuelve el DNS completo de SQLServer1, ejecute el siguiente comando:
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 en el DNS completo correcto del equipo que ejecuta SQL Server, la resolución del lado cliente también se realiza correctamente.
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 cmdlets.
Nota
Los métodos de resolución de nombres pueden incluir dns, WINS, archivos hosts y archivos Lmhosts. Para obtener más información sobre los problemas de resolución de nombres y la solución de problemas, revise los vínculos siguientes:
Compruebe si existen alias para el SQL Server de destino en Administrador de configuración de SQL Server y en la utilidad SQL Server Client Network. 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.
Paso 2: Comprobar la comunicación entre dominios
Compruebe que 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 correcta en el dominio.
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, el error SSPI puede producirse en una de las situaciones siguientes:
- La cuenta de dominio está bloqueada.
- No ha reiniciado el servicio de SQL Server después de cambiar la contraseña de la cuenta.
Si el dominio de inicio de sesión difiere del dominio del servidor que ejecuta SQL Server, compruebe la relación de confianza entre los dominios.
Compruebe si el dominio al que pertenece el servidor y la cuenta de dominio que usa para conectarse están en el mismo bosque. Este paso es necesario para que 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 desde el repositorio de GitHub de Redes de Microsoft SQL. SQLCheck proporciona la mayor parte de la información necesaria para la solución de 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 comprobar la página de requisitos previos y 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 ejemplos siguientes) y use la herramienta Setspn para realizar las acciones correctivas necesarias para corregir los problemas de SPN.
| Escenario | Acción sugerida |
|---|---|
| SPN no existe | Agregue los SPN necesarios para la cuenta de servicio de SQL Server. |
| SPN duplicados | Elimine el SPN registrado para el servicio SQL en la cuenta incorrecta. |
| SPN en una cuenta incorrecta | Elimine el SPN registrado para el servicio SQL en la cuenta incorrecta y, a continuación, registre el SPN en la cuenta de servicio correcta. |
Nota
Puede revisar la sección información de SQL Server del archivo de salida de la herramienta SQLCheck para buscar la cuenta de servicio de la instancia de SQL Server.
Setspn es una herramienta integrada en versiones más recientes de Windows que le ayuda a leer, agregar, modificar o eliminar SPN en Active Directory. Puede usar esta herramienta para comprobar que SQL Server SPN están configurados según Registrar un nombre de entidad de seguridad de servicio para conexiones Kerberos. Para obtener más información, vea La herramienta Setspn y ejemplos sobre cómo usarla.
Para obtener más información sobre los escenarios en los que SQL Server registra automáticamente los SPN y en los que se requiere el registro de SPN manual, consulte Registro de un nombre principal de servicio para conexiones Kerberos.
Paso 4: Comprobar el permiso de cuenta para SQL Server cuenta de inicio 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 pasar las credenciales entrantes a SQL Server remotas. El SQL Server cuenta de inicio donde se define el servidor vinculado debe tener la cuenta de confianza para el derecho de delegación asignado en Active Directory. Para obtener más información, consulte Habilitación de cuentas de equipo y de usuario para que sean de confianza para la delegación.
Nota
Este paso solo es necesario cuando se solucionan problemas relacionados con las consultas del servidor vinculado.