Cómo solucionar el mensaje de error "No se puede generar contexto SSPI"


Nota Kerberos Configuration Manager es una herramienta de diagnóstico que sirve para solucionar los problemas de conectividad relacionados con Kerberos que se producen en SQL Server. Estos problemas pueden generar errores como "No se puede generar el contexto SSPI". Esta herramienta está disponible ahora y se puede descargar desde esta ubicación:

https://www.microsoft.com/es-es/download/details.aspx

Para obtener más información, consulte los siguientes artículos de Microsoft Knowledge Base:

Nueva herramienta: "Microsoft Kerberos Configuration Manager para SQL Server" resuelve los problemas de Kerberos o de conectividad

La herramienta Kerberos Configuration Manager para SQL Server está disponible

 

En esta sección le da la información general sobre por qué se produce el mensaje de error "No se puede generar el contexto SSPI" y le indica cómo solucionarlo. Puede aparecer este mensaje de error si se cumplen las siguientes condiciones:

  • Está conectándose a Microsoft SQL Server.

  • Está utilizando Seguridad integrado.

  • Está utilizando autenticación Kerberos para efectuar la delegación de seguridad.

Análisis de la terminología de Kerberos y el nombre de entidad de seguridad de servicio El controlador de SQL Server en un equipo cliente utiliza la seguridad integrada para emplear el token de seguridad de Windows de la cuenta de usuario a fin de conectarse con éxito al equipo que ejecuta SQL Server. El cliente delega el token (símbolo) de seguridad de Windows al equipo que está ejecutando SQL Server. El controlador de SQL Server realiza esta delegación cuando el token de seguridad del usuario es delegado de un equipo a otro utilizando una de las configuraciones siguientes:

  • NTLM sobre canalizaciones con nombre (que no utilicen la Interfaz proovedora de compatibilidad con seguridad [SSPI])

  • NTLM sobre sockets TCP/IP con SSPI

  • Autenticación Kerberos sobre sockets TCP/IP con 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. De esta manera, SSPI permite a los equipos que ejecuten un sistema operativo de Windows que deleguen de forma segura un token de seguridad de un equipo a otro, utilizando una capa de transporte que pueda transmitir bytes de datos sin formato.

El error "No se puede generar el contexto SSPI" se genera cuando SSPI utiliza la autenticación Kerberos para delegar sobre TCP/IP, al tiempo que la autenticación Kerberos no puede realizar las operaciones necesarias para delegar con éxito el token de seguridad de usuario al equipo de destino que esté ejecutando SQL Server.

Por qué la interfaz del proveedor de compatibilidad para seguridad (SSPI) usa la autenticación NTLM o Kerberos La autenticación Kerberos utiliza un identificador denominado "Nombre de entidad de seguridad de servicio" (SPN). Considere un SPN como un dominio o identificador único de bosque de alguna instancia en un recurso de servidor. Puede tener asignado un SPN a un servicio web, a un servicio de SQL o a un servicio SMTP. También puede tener varias instancias del servicio web en el mismo equipo físico que disponga de un SPN único.

Un SPN para SQL Server consta de los elementos siguientes:

  • ServiceClass: Identifica la clase general del servicio. Ésta siempre es MSSQLSvc para SQL Server.

  • Host: Se trata del DNS de nombre de dominio completo del equipo que está ejecutando SQL Server.

  • Puerto: Se trata del número de puerto en el que el servicio está escuchando.

Por ejemplo, un SPN típico para un equipo que ejecuta SQL Server es:


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.

Cuando el controlador de SQL Server de un cliente utiliza la seguridad integrada para conectarse a SQL Server, el código de controlador del cliente intentará resolver el DNS completo del equipo que está ejecutando SQL Server mediante el uso de las API de red WinSock. Para realizar esta operación, el código del controlador efectúa una llamada a las API WinSock gethostbyname y gethostbyaddr. Aun cuando se transmita una dirección IP o un nombre de host como nombre del equipo que está ejecutando SQL Server, el controlador de SQL Server intentará resolver el DNS completo del equipo, si el equipo está utilizando la seguridad integrada.

Cuando el controlador de SQL Server del cliente resuelve el DNS completo del equipo que está ejecutando SQL Server, el DNS correspondiente se utiliza para formar el SPN del equipo en cuestión. Por consiguiente, cualquier problema relacionado con la forma en que WinSock resuelva la dirección IP o el nombre del host para el DNS completo puede hacer que el controlador de SQL Server cree un SPN no válido para el equipo que está ejecutando SQL Server.

Así, por ejemplo, los SPN no válidos que el controlador de SQL Server del lado cliente puede formar como DNS completo son:

  • 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 sin éxito el SPN en el servicio de directorios de Active Directory. Si la interfaz SSPI no encuentra el SPN, no se realizará la autenticación de Kerberos. En este punto, la capa SSPI cambiará a un modo de autenticación NTLM y el inicio de sesión utilizará la autenticación NTLM, realizando la operación con éxito en la mayoría de los casos. Si el controlador de SQL Server forma un SPN válido pero que no está asignado al contenedor adecuado, intentará utilizar sin éxito el SPN. Esto genera el mensaje de error "No se puede generar el 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. Dado que la autenticación intentará utilizar el primer SPN que encuentra, asegúrese de que no haya SPN asignados a los contenedores incorrectos. En otros términos, cada SPN debe asignarse a un solo contenedor.

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 utilizando la utilidad de línea 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 que ejecuta SQL Server es SQLServer1):

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

ping -a direcciónIP 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 direcciónIP se resuelve como el DNS completo correcto del equipo que ejecuta SQL Server, la resolución en el lado cliente también es correcta.

Creación del nombre de entidad de seguridad de servicio de SQL Server Esta es una de las partes importantes de la interacción entre la autenticación Kerberos y SQL Server. Con SQL Server, puede ejecutar el servicio SQL Server con una de estas cuentas: LocalSystem, de usuario local o de usuario de dominio. Cuando se inicia una instancia del servicio SQL Server, esta intenta registrar su propio SPN en Active Directory mediante la llamada de API DsWriteAccountSpn. Si la llamada no tiene éxito, la siguiente advertencia se registra en el Visor de sucesos: Para obtener más información sobre la función DsWriteAccountSpn, visite el siguiente sitio web de Microsoft:

http://msdn2.microsoft.com/library/ms676056.aspx

Explicación simplificada Si ejecuta el servicio SQL Server en la cuenta LocalSystem, el SPN se registra de forma automática y Kerberos interactúa correctamente con el equipo que ejecuta SQL Server. Sin embargo, si ejecuta el servicio SQL Server en una cuenta de dominio o en una local, se producirá un error en el intento de crear el SPN en la mayoría de los casos, puesto que estas cuentas no están autorizadas para establecer sus propios SPN. Cuando la creación del SPN no se realiza con éxito, esto significa que no se ha establecido ningún SPN para el equipo que está ejecutando SQL Server. Si prueba a utilizar una cuenta de administrador de dominio como la cuenta de servicio de SQL Server, el SPN se creará correctamente porque están presentes las credenciales de nivel de administrador de dominio de las que debe disponer.

Teniendo en cuenta que tal vez no pueda utilizar una cuenta de administrador de dominio para ejecutar el servicio de SQL Server (para evitar poner en peligro la seguridad), el equipo que está ejecutando SQL Server no podrá crear su propio SPN. Por consiguiente, deberá crear manualmente un SPN para el equipo que esté ejecutando SQL Server, en el caso de que desee utilizar la autenticación Kerberos cuando se conecte a un equipo que ejecute SQL Server. Esto se aplica en el caso de que esté ejecutando SQL Server bajo una cuenta de usuario de dominio o bajo una cuenta de usuario local. El SPN que cree debe estar asignado a la cuenta de servicio del servicio de SQL Server en ese equipo específico. No se puede asignar el SPN al contenedor del equipo, a menos que el equipo que está ejecutando SQL Server empiece por la cuenta del sistema local. Sólo puede haber un único SPN, el cual debe asignarse al contenedor adecuado. Normalmente, es la cuenta de servicio actual de SQL Server, pero esta es la cuenta del equipo contenedora de la cuenta de sistema local.
 

 

En esta sección se muestran los pasos para ayudar a garantizar que el equipo no experimenta problemas SSPI.

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

  1. Debe comprobar que puede iniciar sesión en Windows correctamente utilizando la misma cuenta de dominio y la misma contraseña de 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.

    • Se cambió la contraseña de la cuenta. Sin embargo, no ha vuelto a reiniciar el servicio de SQL Server desde entonces.

  2. Si el dominio al que se conecta es distinto del dominio al que pertenece el equipo 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. Esto es necesario para que la SSPI funcione.

  4. Utilice la opción Se confía en la cuenta para su delegación de Usuarios y equipos de Active Directory cuando inicie SQL Server.


    Nota El derecho "Se confía en la cuenta para su delegación" se requiere solo si quiere delegar credenciales desde el servidor SQL de destino a un servidor SQL remoto, por ejemplo, en una situación de salto doble como consultas distribuidas (consultas de servidor vinculadas) que utilizan la autenticación de Windows.

  5. Emplee la utilidad Service Principal Names for Accounts (SetSPN.exe) del Kit de recursos de Windows 2000. Las cuentas de administrador de dominio de Windows 2000 o Windows Server 2003 pueden usar la utilidad para controlar el SPN asignado a un servicio y a una cuenta. En el caso de SQL Server, debe haber un solo SPN. Se debe asignar el SPN al contenedor adecuado, en la mayor parte de los casos a la cuenta de servicio actual de SQL Server y a la cuenta del equipo cuando SQL Server se inicie con la cuenta del sistema local. Si inicia SQL Server mientras está conectado a la cuenta Localsystem, el SPN se configura automáticamente. Sin embargo, si utiliza una cuenta de dominio para iniciar SQL Server o cambia la cuenta que utiliza para iniciar SQL Server, deberá ejecutar SetSPN.exe para quitar los SPN caducados y, a continuación, deberá agregar un SPN válido. Para obtener información adicional, consulte el tema "Delegación de cuentas de seguridad" en los Libros en pantalla de SQL Server 2000. Para ello, visite el siguiente sitio web de Microsoft:

    http://msdn2.microsoft.com/library/aa905162(SQL.80).aspx Para obtener más información sobre los kits de recursos de Windows 2000, visite el siguiente sitio web de Microsoft:

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true

  6. Compruebe que la resolución del nombre se efectúa correctamente. Entre los posibles métodos de resolución de nombres están los archivos DNS, WINS, Hosts y Lmhosts. Para obtener información adicional sobre cómo solucionar problemas de resolución de nombre, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    169790 Cómo solucionar problemas de TCP/IP básicos
     

  7. Para obtener información adicional sobre cómo solucionar problemas de accesibilidad y de firewall con Active Directory, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

    291382 Preguntas más frecuentes sobre DNS de Windows 2000 y Windows Server 2003
     

    224196 Restringir el tráfico de replicación de Active Directory y el tráfico de RPC de cliente a un puerto específico

Configurar el servicio SQL Server para crear SPN de forma dinámica para las instancias de SQL Server Si desea configurar el servicio SQL Server para crear SPN dinámicamente, debe modificar la configuración del control de acceso de la cuenta en el servicio de directorio Active Directory. Debe conceder los permisos "Read servicePrincipalName" y "Write servicePrincipalName" para la cuenta del servicio de SQL Server.

Advertencia Si utiliza el complemento Edición de interfaces ADSI, la utilidad LDP o cualquier otro cliente de LDAP versión 3, y modifica los atributos de los objetos de Active Directory incorrectamente, puede provocar problemas graves. Debido a estos problemas, puede ser necesario reinstalar Windows 2003 Server, Windows Server 2000, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server o tanto Windows como Exchange. No podemos garantizar que los problemas ocasionados por la modificación incorrecta de los atributos de los objetos de Active Directory puedan resolverse. Modifique estos atributos bajo su responsabilidad.

Nota Para conceder los permisos y los derechos de usuario adecuados a la cuenta de inicio de SQL Server, debe iniciar sesión como administrador de dominio o debe pedir al administrador de dominio que realice dicha tarea.

Para configurar el servicio de SQL Server para crear SPN de forma dinámica, siga estos pasos:

  1. Haga clic en Inicio y en Ejecutar, escriba Adsiedit.msc y haga clic en Aceptar.

  2. En el complemento Edición de ADSI, expanda Dominio [nombreDeDominio], DC= nombreDeDominioRaíz y CN=Users, haga clic con el botón derecho en CN= nombreDeCuenta y luego haga clic en Propiedades.

    Notas

    • nombreDeDominio es el marcador de posición del nombre del dominio.

    • nombreDeDominioRaíz es el marcador de posición del nombre del dominio raíz.

    • nombreDeCuenta es el marcador de posición de la cuenta que especifica para iniciar el servicio SQL Server.

    • Si especifica la cuenta de sistema local para iniciar el servicio SQL Server, nombreDeCuenta es el marcador de posición de la cuenta que utiliza para iniciar sesión en Microsoft Windows.

    • Si especifica una cuenta de usuario de dominio para iniciar el servicio SQL Server, nombreDeCuenta es el marcador de posición de la cuenta de usuario de dominio.

  3. En el cuadro de diálogo Propiedades de CN= nombreDeCuenta, haga clic en la pestaña Seguridad.

  4. En la pestaña Seguridad, haga clic en Opciones avanzadas.

  5. En el cuadro de diálogo Configuración de seguridad avanzada, asegúrese de que ACTUAL se muestra debajo de Entradas de permisos.

    Si ACTUAL no figura, haga clic en Agregar y agregue ACTUAL.

  6. En Entradas de permisos, haga clic en ACTUAL y luego en Edición.

  7. En el cuadro de diálogo Entrada de permiso, haga clic en la pestaña Propiedades.

  8. En la pestaña Propiedades, haga clic en la opción Solo este objeto de la lista Aplicar en y, después, asegúrese de que las casillas de los permisos siguientes estén seleccionadas en Permisos:

    • Read ServicePrincipalName

    • Write ServicePrincipalName

  9. Haga clic tres veces en Aceptar y salga del complemento Edición de ADSI.

Para obtener ayuda con este proceso, póngase en contacto con el servicio de soporte técnico del producto Active Directory y mencione este artículo de Microsoft Knowledge Base.


Importante Se recomienda que no conceda el derecho WriteServicePrincipalName a la cuenta de servicio SQL cuando se cumplan las siguientes condiciones:

  • Hay varios controladores de dominio.

  • SQL Server está agrupado.

En esta situación, es posible que el SPN de SQL Server se elimine debido a una latencia en la replicación de Active Directory. Esto puede causar problemas de conectividad en la instancia de SQL Server.

Imagine que tiene lo siguiente:

  • Una instancia virtual de SQL denominada Sqlcluster con dos nodos: nodo A y nodo B.

  • El controlador de dominio A autentica al nodo A y el controlador de dominio B autentica al nodo B.



Puede ocurrir lo siguiente:

  1. La instancia Sqlcluster está activa en el nodo A y se registra en el SPN de SQL en el controlador de dominio A durante el inicio.

  2. La instancia Sqlcluster conmuta por error al nodo B cuando el nodo A se apaga normalmente.

  3. La instancia Sqlcluster quita su SPN del registro del controlador de dominio A durante el proceso de cierre en el nodo A.

  4. El SPN se quita del controlador de dominio A pero el cambio tarda en replicarse en el controlador de dominio B.

  5. Cuando se inicia el nodo B, la instancia Sqlcluster trata de registrar el SPN de SQL con el controlador de dominio B. Entonces, el SPN que todavía existe el nodo B no registra el SPN.

  6. Después de un tiempo, el controlador de dominio A replica la eliminación del SPN (del paso 3) en el controlador de dominio B como parte del proceso de replicación de Active Directory. El resultado final es que no existe ningún SPN válido para la instancia SQL en el dominio y, por tanto, ve problemas de conexión en la instancia de Sqlcluster.


Nota Este problema se corrigió en SQL Server 2012.

Comprobación del entorno del servidor Compruebe algunas configuraciones básicas del equipo en el que SQL Server está instalado:

  1. La autenticación Kerberos no es compatible con los equipos basados en Windows 2000 que ejecutan la agrupación en clústeres de Windows a menos que haya aplicado el Service Pack 3 (o uno posterior) a Windows 2000. Por consiguiente, los intentos de usar la autenticación SSPI en instancias con clústeres de SQL Server darán error. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    235529 Compatibilidad con autenticación Kerberos en clústeres de servidores basados en Windows 2000
     

  2. Compruebe si el servidor usa Windows 2000 Service Pack 1 (SP1). Para obtener información adicional sobre la compatibilidad de la autenticación Kerberos con los servidores basados en Windows 2000, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    267588 Aparece el mensaje de error "No se puede generar el contexto SSPI" al conectarse a SQL Server 2000
     

  3. En un clúster, si cambia la cuenta que utiliza para iniciar SQL Server, Agente SQL Server o los servicios de búsqueda de texto completo, estableciendo una nueva contraseña, por ejemplo, siga los pasos que se indican en el artículo de Microsoft Knowledge Base siguiente:

    239885 Cómo cambiar las cuentas de servicio en un equipo con clústeres que ejecuta SQL Server
     

  4. Compruebe si la cuenta que utiliza para iniciar SQL Server tiene los permisos adecuados. Si utiliza una cuenta que no es miembro del grupo Administradores locales, consulte el tema "Configurar cuentas de servicios de Windows" en los Libros en pantalla de SQL Server para ver la lista detallada de los permisos que la cuenta debe tener:

    http://msdn2.microsoft.com/library/aa176564(SQL.80).aspx

Comprobación del entorno del cliente Compruebe lo siguiente en el cliente:

  1. Asegúrese de que la interfaz del proveedor de compatibilidad para seguridad de NTLM se ha instalado correctamente y está habilitada en el cliente. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    269541 Si se ha perdido la clave del Registro de Windows NT LM Security Support Provider, cuando conecta con SQL Server recibe el mensaje de error "No se puede generar el contexto SSPI"
     

  2. Determine si está utilizando las credenciales almacenadas en memoria caché. Si inicia sesión en el cliente con credenciales almacenadas en memoria caché, apague el equipo y vuelva a iniciar sesión cuando pueda conectarse a un controlador de dominio para evitar que se utilicen las credenciales almacenadas en la memoria caché. Para obtener más información sobre cómo determinar si está usando credenciales almacenadas en la caché, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    242536 No se avisa al usuario cuando inicia sesión con credenciales de dominio almacenadas en caché
     

  3. Compruebe que las fechas del cliente y del servidor sean válidas. Si las fechas son muy distantes entre sí, sus certificados pueden considerarse no válidos.

  4. SSPI usa un archivo denominado Security.dll. Si cualquier otra aplicación instala un archivo con este nombre, puede que se use el otro archivo en lugar del verdadero archivo SSPI. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    253577 Error: 80004005 - El controlador MS ODBC de SQL Server no puede inicializar el paquete SSPI
     

  5. Si el sistema operativo en el cliente es Microsoft Windows 98, deberá instalar el componente Cliente para redes de Microsoft.

    Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    267550 ERROR: "Error de aserción" al conectarse a un servidor SQL Server a través de TCP/IP
     

Comprobación de la utilidad de red de cliente La Utilidad de red de cliente (CNU) se distribuye junto con Microsoft Data Access Components (MDAC) y se utiliza para configurar la conectividad a los equipos que ejecutan SQL Server. Puede utilizar la utilidad CNU de MDAC Cliconfg.exe para configurar la conectividad:

  1. En la pestaña General, la manera en que se definen los protocolos varía según la versión de MDAC. Con versiones anteriores de MDAC, puede seleccionar un protocolo "predeterminado". En las últimas versiones de MDAC, puede habilitar uno o más protocolos, colocando uno al comienzo de la lista cuando se conecte a SQL Server. Puesto que SSPI sólo se aplica a TCP/IP, para prevenir posibles errores, puede utilizar un protocolo diferente, como Canalizaciones con nombre.

  2. Seleccione la casilla Alias de la CNU para comprobar si se ha definido un alias para el servidor con el que se está intentando conectar. Si se ha definido un alias para el servidor, compruebe las configuraciones de conexión del equipo a SQL Server. Puede comprobar este detalle borrando el servidor del alias, observando si cambia su comportamiento.

  3. Si el servidor del alias no está definido en la CNU, agregue el alias al servidor al que se conecte. Cuando realice esta tarea, también está definiendo explícitamente el protocolo y, opcionalmente, está definiendo la dirección IP y el puerto.

Configurar manualmente un nombre de entidad de seguridad de servicio para SQL Server Para obtener más información sobre cómo configurar manualmente un nombre de entidad de seguridad de servicio para SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

319723 Cómo usar la autenticación Kerberos en SQL Server
  La interfaz del proveedor de compatibilidad para seguridad (SSPI) es la interfaz de seguridad de Microsoft Windows NT que se emplea para la autenticación Kerberos. Admite el esquema de autenticación del proveedor de compatibilidad para seguridad de NTLM. La autenticación tiene lugar en el nivel del sistema operativo cuando se conecta a un dominio de Windows. La autenticación Kerberos solo está disponible en equipos basados en Windows 2000 que tienen habilitada la autenticación Kerberos y que utilizan Active Directory.

SSPI sólo se utiliza en conexiones de TCP/IP que se realizan mediante la autenticación de Windows. La autenticación de Windows también se conoce como Conexiones de confianza o Seguridad integrada. Las Canalizaciones con nombre ni las conexiones multiprotocolo utilizan la SSPI. Por consiguiente, puede evitar este problema configurando sus clientes de manera que se conecten desde un protocolo distinto de TCP/IP.

Cuando un cliente de SQL Server intenta utilizar la seguridad integrada sobre sockets de TCP/IP con un equipo remoto que está ejecutando SQL Server, la biblioteca de red del cliente con SQL Server utiliza la API SSPI para realizar la delegación de seguridad. El cliente de red de SQL Server (Dbnetlib.dll) efectúa una llamada a la función AcquireCredentialsHandle y negocia el parámetro pszPackage. Esto indica al proveedor de seguridad subyacente que efectúe la delegación de negociació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 de Kerberos si el equipo de destino que ejecuta SQL Server tiene asociado un SPN correctamente configurado. En caso contrario, Windows usará la delegación de NTLM.

Nota Compruebe que no esté utilizando una cuenta con el nombre "SYSTEM" para iniciar ninguno de los servicios SQL Server (MSSQLServer, SQLServerAgent o MSSearch). La palabra clave SYSTEM puede generar conflictos con el Centro de distribución de claves (KDC).
 

 

Si no puede obtener la causa del problema utilizando los pasos de la solución de problemas de este artículo, puede recopilar la información siguiente y abrir un caso para el Servicio de soporte al cliente de Microsoft.

Para obtener una lista completa de los números de teléfono del Servicio de soporte al cliente de Microsoft, así como información acerca de los costos de soporte técnico, visite el siguiente sitio web de Microsoft:

http://support.microsoft.com/es-es/contactus/?ws=support

  1. Genere un informe sqldiag desde SQL Server. Para obtener información adicional, consulte el tema "Utilidad sqldiag" en los Libros en pantalla de SQL Server.

  2. Efectúe una captura de pantalla del error en el cliente.

  3. Abra un símbolo del sistema en el nodo que no se puede conectar a SQL Server y luego escriba el comando siguiente:

    net start > started.txt Este comando genera un archivo denominado Started.txt en el directorio donde se ejecuta el comando.

  4. Guarde los valores correspondientes a la clave del Registro en la clave del Registro siguiente en el equipo cliente:

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO

  5. En un entorno con clústeres, obtenga el valor de la clave del Registro siguiente para cada nodo del clúster:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel

  6. En un entorno con clústeres, compruebe si la clave del Registro siguiente existe en cada uno de los nodos de servidor de clúster:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp

  7. Capture los resultados si se conecta a SQL Server utilizando un nombre de la Convención de nomenclatura internacional (UNC) (o el nombre de red de SQL en un clúster) desde el cliente.

  8. Capture los resultados si hace ping en el nombre del equipo (o en el nombre de red de SQL en un clúster) desde el cliente.

  9. Guarde el nombre de las cuentas de usuario que utilice para iniciar cada uno de los servicios de SQL Server (MSSQLServer, SQLServerAgent, MSSearch).

  10. El profesional del soporte técnico debe saber si SQL Server está configurado para la autenticación mixta o la autenticación basada sólo en Windows.

  11. Compruebe si puede conectarse al equipo que está ejecutando SQL Server desde el mismo cliente, utilizando la autenticación de SQL Server.

  12. Intente conectar utilizando el protocolo de Canalizaciones con nombre.

Referencias Para obtener más información sobre cómo funcionan la autenticación Kerberos y la seguridad SSPI, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

266080 Respuestas a las preguntas más frecuentes sobre la autenticación Kerberos
 

231789 Proceso de inicio de sesión local para Windows 2000
 

304161 La autenticación mutua SSPI se indica en el cliente pero no en el servidor
 

232179 Administración de Kerberos en Windows 2000
 

230476 Descripción de errores comunes relacionados con Kerberos en Windows 2000
 

262177 Cómo habilitar el registro de eventos de Kerberos
 

277658 Se produce un error en Setspn si el nombre de dominio difiere del nombre NetBIOS donde se registra el SPN de SQL Server

244474 Cómo forzar a Kerberos a usar TCP en lugar de UDP en Windows Server 2003, Windows XP y Windows 2000
  Para ver las notas del producto sobre la seguridad de Microsoft SQL Server 2000, visite el siguiente sitio web de Microsoft:

http://technet.microsoft.com/cc984178.aspx

¿Necesita más ayuda?

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Unirse a Microsoft Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×