En este artículo paso a paso se describe cómo solucionar
los problemas que generan con mayor frecuencia el mensaje de error "No se puede
generar contexto SSPI". Puede recibir este mensaje de error en las situaciones
siguientes:
- Está conectando a SQL Server.
- Está utilizando Seguridad integrado.
- Está utilizando Kerberos para efectuar la delegación de
seguridad.
Análisis de la terminología de Kerberos y el nombre de principio 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 con éxito 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
- Kerberos sobre sockets TCP/IP con SSPI
La interfaz proveedora de compatibilidad con 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 contexto SSPI" se
genera cuando SSPI utiliza Kerberos para delegar sobre TCP/IP, al tiempo que
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 con seguridad de Windows elige NTLM o Kerberos
Kerberos utiliza un identificador denominado "Nombre de principio
de servicio" (SPN). Considere SPN como un dominio o identificador único de
bosque de alguna instancia en un recurso de servidor de red. 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, generando un mensaje de 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. 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 comandos 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 línea de comandos Ping
resuelve el DNS completo de SQLServer1, ejecutado 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
Respuesta desde 123.123.123.123: bytes=32 time<10ms TTL=128
Respuesta desde 123.123.123.123: bytes=32 time<10ms TTL=128
Respuesta desde 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:
mínimo = 0 ms, máximo = 0 ms, promedio = 0 ms
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
Respuesta desde 123.123.123.123: bytes=32 time<10ms TTL=128
Respuesta desde 123.123.123.123: bytes=32 time<10ms TTL=128
Respuesta desde 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:
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 principio del servicio de SQL Server
Ésta es una de las partes esenciales de la interacción entre
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 acerca de la función
DsWriteAccountSpn, visite el siguiente sitio Web de Microsoft:
Explicación simplificada
Si ejecuta el servicio de 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 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
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
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 el 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. Sin embargo, también es la
cuenta del equipo con el sistema local.
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 nombre adecuada en el dominio.
- Si su dominio de inicio de sesión es el mismo al que
pertenece el equipo que ejecuta SQL Server, use la autenticación de Windows
para conectarse a SQL Server. Si se produce un error en la autenticación, hay
un problema con la cuenta de Windows o con la cuenta de dominio. Póngase en
contacto con su administrador de seguridad o administrador de red para
comprobar si la cuenta de Windows o la cuenta de dominio cuentan con los
permisos adecuados.
- 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.
- 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.
- 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.
- 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 2003 pueden usar la utilidad para
controlar el SPN asignado a un servicio y a una cuenta. En el caso de SQL
Server, sólo puede haber un único 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:Para obtener más información acerca de los kits de recursos de
Windows 2000, visite el siguiente sitio Web de Microsoft:
- 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 los archivos 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
(http://support.microsoft.com/kb/169790/
)
Cómo solucionar problemas de TCP/IP básicos
- 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
(http://support.microsoft.com/kb/291382/
)
Preguntas más frecuentes acerca de DNS de Windows 2000
224196
(http://support.microsoft.com/kb/224196/
)
Restringir el tráfico de replicación de Active Directory y el tráfico de RPC de cliente a un puerto específico
Cómo configurar el servicio de SQL Server para crear SPN de forma dinámica 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 Microsoft Windows 2003
Server, Microsoft 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:
- Haga clic en Inicio y en
Ejecutar, escriba Adsiedit.msc y haga
clic en Aceptar.
- 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.
- En el cuadro de diálogo Propiedades de CN=
nombreDeCuenta, haga clic en la ficha
Seguridad.
- En la ficha Seguridad, haga clic en
Opciones avanzadas.
- 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. - En Entradas de permisos, haga clic en
ACTUAL y, a continuación, haga clic en
Modificar.
- En el cuadro de diálogo Entrada de
permiso, haga clic en la ficha Propiedades.
- 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
- 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.
Comprobación del entorno del servidor
Compruebe algunas configuraciones básicas del equipo en el que
SQL Server está instalado:
- 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 serán fallidos.
Para obtener más información al
respecto, haga clic en el número de artículo siguiente para verlo en Microsoft
Knowledge Base:
235529
(http://support.microsoft.com/kb/235529/
)
Compatibilidad con Kerberos en clústeres de servidores basados en Windows 2000
- Compruebe que el servidor está ejecutando Windows 2000
Service Pack 1 (SP1).
Para
obtener información adicional acerca de la compatibilidad de 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
(http://support.microsoft.com/kb/267588/
)
Aparece el mensaje de error "No se puede generar contexto SSPI" al conectarse a SQL Server 2000
- 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
(http://support.microsoft.com/kb/239885/
)
Cómo cambiar las cuentas de servicio en un servidor virtual de SQL
- 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 obtener una lista
detallada de los permisos que la cuenta debe tener:
Comprobación del entorno del cliente
Compruebe lo siguiente en el cliente:
- Asegúrese de que la interfaz proveedora de compatibilidad
de seguridad de NTLM se ha instalado correctamente y está habilitada en el
cliente.
Para obtener más
información al respecto, haga clic en el número de artículo siguiente para
verlo en Microsoft Knowledge Base:
269541
(http://support.microsoft.com/kb/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
- 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
(http://support.microsoft.com/kb/242536/
)
No se avisa al usuario cuando inicia sesión con credenciales de dominio almacenadas en caché
- 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.
- 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 al respecto, haga clic en el número de artículo siguiente para
verlo en Microsoft Knowledge Base:
253577
(http://support.microsoft.com/kb/253577/
)
Error: 80004005 - El controlador MS ODBC de SQL Server no puede inicializar el paquete SSPI
- 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
al respecto, haga clic en el número de artículo siguiente para verlo en
Microsoft Knowledge Base:
267550
(http://support.microsoft.com/kb/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:
- 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.
- Active la casilla de verificación 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.
- 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.
Información necesaria para abrir un caso para el Soporte técnico de Microsoft (PSS)
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 los Servicios de soporte técnico de Microsoft
(PSS):
Para obtener una lista completa de los números de teléfono de
los Servicios de soporte técnico de Microsoft, así como información acerca de
los costos de soporte técnico, visite el siguiente sitio Web de Microsoft:
- 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.
- Efectúe una captura de pantalla del error en el
cliente.
- En el nodo que no puede conectarse a SQL Server, escriba el
comando siguiente desde el símbolo del sistema:
net start > started.txt
Este comando genera un archivo denominado Started.txt en el
directorio donde ejecute el comando. - Guarde los valores correspondientes a la clave del
Registro en la clave del Registro siguiente en su equipo cliente:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
- 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
- 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
- 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.
- 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.
- Guarde el nombre de las cuentas de usuario que utilice
para iniciar cada uno de los servicios de SQL Server (MSSQLServer,
SQLServerAgent, MSSearch).
- 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.
- Compruebe si puede conectarse al equipo que está ejecutando
SQL Server desde el mismo cliente, utilizando la autenticación de SQL
Server.
- Intente conectar utilizando el protocolo de Canalizaciones
con nombre.
Cómo configurar manualmente un nombre de principio de servicio para SQL Server
Para obtener más información acerca de cómo
configurar manualmente un nombre de principio de servicio para SQL Server, haga
clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
319723
(http://support.microsoft.com/kb/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 de
Kerberos sólo está disponible en equipos basados en Windows 2000 que tienen
habilitado 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).
Para obtener más información acerca de cómo
funcionan Kerberos y la seguridad SSPI, haga clic en los números de artículo
siguientes para verlos en Microsoft Knowledge Base:
266080
(http://support.microsoft.com/kb/266080/
)
Respuestas a las preguntas más frecuentes sobre Kerberos
231789
(http://support.microsoft.com/kb/231789/
)
Proceso de inicio de sesión local para Windows 2000
304161
(http://support.microsoft.com/kb/304161/
)
La autenticación mutua SSPI se indica en el cliente pero no en el servidor
232179
(http://support.microsoft.com/kb/232179/
)
Administración de Kerberos en Windows 2000
230476
(http://support.microsoft.com/kb/230476/
)
Descripción de errores comunes relacionados con Kerberos en Windows 2000
262177
(http://support.microsoft.com/kb/262177/
)
Cómo habilitar el registro de sucesos de Kerberos
277658
(http://support.microsoft.com/kb/277658/
)
Se produce un error en Setspn si el nombre de dominio difiere del nombre NetBIOS donde se registre el SPN de SQL Server
244474
(http://support.microsoft.com/kb/244474/
)
Cómo forzar a Kerberos a usar TCP en lugar de UDP en Windows Server 2003, en Windows XP y en Windows 2000
326985
(http://support.microsoft.com/kb/326985/
)
Cómo solucionar problemas relacionados con Kerberos en IIS
Para ver las notas del producto acerca de la
seguridad de Microsoft SQL Server 2000, visite el siguiente sitio Web de
Microsoft:
Volver al principio
