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

Seleccione idioma Seleccione idioma
Id. de artículo: 811889 - Ver los productos a los que se aplica este artículo
Si usted es cliente de una pequeña empresa, puede encontrar información adicional de solución de problemas y recursos de aprendizaje en el sitio de soporte técnico para pequeñas empresas.
Expandir todo | Contraer todo

Descripción del problema

Contraer esta imagenAmpliar esta imagen
assets folding start collapsed
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.
Descripción 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 con el fin de conectarse correctamente al equipo que está ejecutando 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 de Windows utiliza autenticación Kerberos o NTLM
La autenticación Kerberos utiliza un identificador denominado "nombre de entidad de seguridad de servicio" (SPN). Considere 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 no es diferente. 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 provoca un 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 siguiente comando para obtener la dirección IP del servidor que ejecuta SQL Server (donde el nombre del equipo que ejecuta SQL Server es SQLServer1):
pingsqlserver1
Para saber si la utilidad de Ping resuelve el DNS completo de SQLServer1, ejecute el comando siguiente:
ping -a direcciónIP
Por ejemplo:
C:\>ping SQLSERVER1

Haciendo ping a SQLSERVER1 [123.123.123.123] con 32 bytes de datos:
	
Respuesta desde 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
	
Estadísticas ping para 123.123.123.123: Paquetes: Enviados = 4, Recibidos = 4, Perdidos = 0 (0% pérdida), Tiempo de los viajes de ida y vuelta en milisegundos: Minimum = 0ms, Maximum =  0ms, Average =  0ms
C:\>ping -a 123.123.123.123
	
Haciendo ping a SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] con 32 bytes de datos:
	
Respuesta desde 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: Paquetes: Enviados = 4, Recibidos = 4, Perdidos = 0 (0% pérdida), Tiempo de los viajes de ida y vuelta en milisegundos: mínimo = 0 ms, máximo = 0 ms, promedio = 0 ms

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
Se trata de una de las partes importantes de la interacción entre la autenticación Kerberos y SQL Server. Con SQL Server, puede ejecutar el servicio de SQL Server bajo uno de los siguientes elementos: una cuenta Localsystem, una cuenta de usuario local o una cuenta de usuario de dominio. Cuando se inicia una instancia del servicio de SQL Server, ésta intenta registrar su propio SPN en Active Directory mediante una llamada API DsWriteAccountSpn. Si la llamada no tiene éxito, la siguiente advertencia se registra en el Visor de sucesos:

Origen: MSSQLServer EventID: 19011 Descripción: Información de SuperSocket: (SpnRegister): Error 8344.

Para obtener más información sobre la función DsWriteAccountSpn, visite el siguiente sitio web de Microsoft:
http://msdn2.microsoft.com/es-es/library/ms676056.aspx
Explicación simplificada
Si ejecuta el servicio de SQL Server bajo la cuenta LocalSystem, el SPN se registra automáticamente y la autenticación Kerberos interactúa con éxito con el equipo que ejecuta SQL Server. Sin embargo, si ejecuta el servicio de SQL Server en una cuenta de dominio o en una cuenta local, se producirá un error en el intento de crear el SPN en la mayoría de los casos, puesto que la cuenta de dominio y la cuenta local 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, se trata de la cuenta de servicio actual de SQL Server, pero se trata de la cuenta del equipo contenedora de la cuenta del sistema local.
Contraer esta imagenAmpliar esta imagen
assets folding end collapsed

Resolución del problema

Contraer esta imagenAmpliar esta imagen
assets folding start collapsed
En esta sección se muestran los pasos para ayudar a garantizar que el equipo no experimenta problemas SSPI.

Comprobar el 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 nombre 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 en 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 está delegando credenciales desde el servidor SQL de destino a un servidor SQL remoto, como en una situación de salto doble como consultas distribuidas (consultas de servidor vinculadas) que utilizan autenticación 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/es-es/library/aa905162(SQL.80).aspx
    Para obtener más información acerca de 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 nombre están los archivos DNS, WINS y Hosts y Lmhosts. Para obtener información adicional acerca de 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 acerca de 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 acerca de 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 de SQL Server para crear SPN dinámicamente para las instancias de SQL Server
Para configurar el servicio de 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 "Leer nombrePrincipalDeServicio" y "Escribir nombrePrincipalDeServicio" para la cuenta del servicio de SQL Server.

Advertencia: si utiliza el complemento Edición de 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], expanda DC= nombreDeDominioRaíz, expanda CN=Users, haga clic con el botón secundario del mouse en CN=nombreDeCuenta y, a continuación, haga clic en Propiedades.

    Notas
    • nombreDeDominio es un marcador de posición para el nombre del dominio.
    • nombreDeDominioRaíz es un marcador de posición para el nombre del dominio raíz.
    • nombreDeCuenta es un marcador de posición para la cuenta que especifique para iniciar el servicio de SQL Server.
    • Si especifica la cuenta de sistema local para iniciar el servicio de SQL Server, nombreDeCuenta es un marcador de posición para la cuenta que utiliza para iniciar sesión en Microsoft Windows.
    • Si especifica una cuenta de usuario de dominio para iniciar el servicio de SQL Server, nombreDeCuenta es un marcador de posición para la cuenta de usuario de dominio.
  3. En el cuadro de diálogo Propiedades de CN= nombreDeCuenta, haga clic en la ficha Seguridad.
  4. En la ficha 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 aparece, haga clic en Agregar y, a continuación, agregue ACTUAL.
  6. En Entradas de permisos, haga clic en ACTUAL y, a continuación, haga clic en Modificar.
  7. En el cuadro de diálogo Entrada de permiso, haga clic en la ficha Propiedades.
  8. En la ficha Propiedades, haga clic en Este objeto sólo en la lista Aplicar eny, a continuación, asegúrese de que las casillas para los permisos siguientes están activadas debajo de Permisos:
    • Leer nombrePrincipalDeServicio
    • Escribir nombrePrincipalDeServicio
  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 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 de 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 Organización por clústeres de Windows, a menos que haya aplicado el Service Pack 3 (o uno posterior) a Windows 2000. Por consiguiente, los intentos de 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 que el servidor está ejecutando Windows 2000 Service Pack 1 (SP1). Para obtener información adicional acerca de 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 la cuenta que utiliza para iniciar SQL Server, Agente SQL Server, o los servicios de búsqueda de texto completo cambian, como es el caso de una nueva contraseña, siguen 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 de Administradores locales, consulte el tema "Configurar cuentas de servicios de Windows" en los Libros en pantalla de SQL Server, para obtener un listado detallado de los permisos que la cuenta debe tener:
    http://msdn2.microsoft.com/es-es/library/aa176564(SQL.80).aspx
Comprobación del entorno de 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 La ausencia de la clave del Registro de Windows NT LM Security Support Provider provoca un mensaje de error al conectarse a SQL Server: "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 información adicional acerca de cómo determinar si está usando credenciales almacenadas en la memoria 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 en el cliente y en el servidor son válidas. Si las fechas son muy distantes entre sí, sus certificados pueden considerarse no válidos.
  4. SSPI utiliza un archivo denominado Security.dll. Si cualquier otra aplicación instala un archivo con este nombre, se puede usar el otro nombre en lugar del archivo SSPI real. 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 Herramienta de red de cliente (CNU) se distribuye junto con los Componentes de Microsoft Data Access (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 ficha 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. Active 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 acerca de 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 autenticación Kerberos en SQL Server
La interfaz del Proveedor de compatibilidad con seguridad (SSPI) es la interfaz con el sistema de seguridad de Microsoft Windows NT que se emplea para la autenticación con Kerberos, y admite el esquema de autenticación del Proveedor de compatibilidad con 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 cualquiera de los servicios de SQL Server (MSSQLServer, SQLServerAgent, MSSearch). La palabra clave SYSTEM puede generar conflictos con el Centro de distribución de claves (KDC).
Contraer esta imagenAmpliar esta imagen
assets folding end collapsed

Recopilar información para abrir un caso del Servicio de soporte al cliente de Microsoft (CSS)

Contraer esta imagenAmpliar esta imagen
assets folding start collapsed
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/contactus/?ln=es#tab0
  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 pueda conectar a SQL Server y, a continuación, escriba el comando siguientes
    net start > started.txt
    Este comando genera un archivo con el nombre Started.txt en el directorio en el que ejecute 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 acerca de 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, en Windows XP y en Windows 2000
Para ver las notas del producto acerca de la seguridad de Microsoft SQL Server 2000, visite el siguiente sitio web de Microsoft:
http://technet.microsoft.com/es-es/cc984178.aspx
Contraer esta imagenAmpliar esta imagen
assets folding end collapsed

Propiedades

Id. de artículo: 811889 - Última revisión: martes, 16 de julio de 2013 - Versión: 21.0
La información de este artículo se refiere a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Enterprise Evaluation
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Datacenter
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Express
  • Microsoft SQL Server 2008 R2 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Integration Services
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Standard Edition for Small Business
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2008 Reporting Services
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 Standard Edition for Small Business
  • Microsoft SQL Server 2008 Web
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • SQL Server 2012 Enterprise Core
Palabras clave: 
kbsqlsetup kbhowtomaster kbhowto kbsmbportal KB811889

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com