que puede nombre manager generate generar error correcto contexto context cannot sql-server tfs kerberos sspi spn

sql-server - puede - sspi que es



El nombre principal de destino es incorrecto. No se puede generar el contexto SSPI (30)

Estoy luchando por obtener una conexión de SQL Server de la máquina A a la máquina B que ejecuta SQL Server.

He buscado mucho en Google y todas las cosas que he encontrado no han funcionado. Tampoco lo guían paso a paso a través del proceso de resolución de esto.

No estamos usando Kerberos, pero NTLM está configurado.

Las máquinas involucradas son (xx se utiliza para ocultar parte del nombre de la máquina por motivos de seguridad):

  • xxPRODSVR001 : controlador de dominio de Windows Server 2012
  • xxDEVSVR003 - Windows Server 2012 (Esta máquina está generando el error)
  • xxDEVSVR002 : Windows Server 2012 (esta máquina ejecuta SQL Server 2012)

Los siguientes SPN están registrados en el DC (xxPRODSVR001). He oscurecido el dominio con yyy por motivos de seguridad:

Nombres registrados de ServicePrincipal para CN = xxDEVSVR002, CN = Computadoras, DC = aaa, DC = local:

MSSQLSvc/xxDEVSVR002.yyy.local:49298 MSSQLSvc/xxDEVSVR002.yyy.local:TFS RestrictedKrbHost/xxDEVSVR002 RestrictedKrbHost/xxDEVSVR002.yyy.local Hyper-V Replica Service/xxDEVSVR002 Hyper-V Replica Service/xxDEVSVR002.yyy.local Microsoft Virtual System Migration Service/xxDEVSVR002 Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local Microsoft Virtual Console Service/xxDEVSVR002 Microsoft Virtual Console Service/xxDEVSVR002.yyy.local SMTPSVC/xxDEVSVR002 SMTPSVC/xxDEVSVR002.yyy.local WSMAN/xxDEVSVR002 WSMAN/xxDEVSVR002.yyy.local Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local TERMSRV/xxDEVSVR002 TERMSRV/xxDEVSVR002.yyy.local HOST/xxDEVSVR002 HOST/xxDEVSVR002.yyy.local

Nombres registrados de ServicePrincipal para CN = xxDEVSVR003, CN = Computadoras, DC = aaa, DC = local:

MSSQLSvc/xxDEVSVR003.yyy.local:1433 MSSQLSvc/xxDEVSVR003.yyy.local Hyper-V Replica Service/xxDEVSVR003 Hyper-V Replica Service/xxDEVSVR003.yyy.local Microsoft Virtual System Migration Service/xxDEVSVR003 Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local Microsoft Virtual Console Service/xxDEVSVR003 Microsoft Virtual Console Service/xxDEVSVR003.yyy.local WSMAN/xxDEVSVR003 WSMAN/xxDEVSVR003.yyy.local TERMSRV/xxDEVSVR003 TERMSRV/xxDEVSVR003.yyy.local RestrictedKrbHost/xxDEVSVR003 HOST/xxDEVSVR003 RestrictedKrbHost/xxDEVSVR003.yyy.local HOST/xxDEVSVR003.yyy.local

Ahora, si solo el mensaje de error de SQL Server fuera más descriptivo y me dijera a qué nombre principal estaba tratando de conectarse, podría diagnosticar esto.

Entonces, ¿alguien puede explicarme cómo resolver esto o puede ver algo en lo que he proporcionado que está mal?

Estaré encantado de generar más información de depuración, solo dime qué necesitas.

Agregaré esto aquí, ya que me sorprendió y puede ayudar a alguien más. Advertencia: no soy una persona de Windows, pero tuve que mirar un escenario que incluía un servidor SQL.

Descargué la versión de desarrollador del producto completo de SQL Server y lo instalé en Windows 10. Todo bien para conexiones locales, nada para el cliente remoto.

Probé muchos de los anteriores, pero finalmente me di cuenta de que la autenticación de Windows quería autenticar remoteclient / myuser y no había forma en un mundo independiente de Windows para crear un mecanismo para autenticarse contra (según lo entiendo kerberos). El mensaje de error es "No se puede generar el contexto SSPI".

El uso de la autenticación de SQL tampoco parecía funcionar.

Finalmente volví a SQL Server Express, que tiene un modo combinado y luego pude usar la autenticación SQL de los clientes remotos.

Asegúrese de que "Canalizaciones con nombre" estén habilitadas desde el "Administrador de configuración de SQL Server". Esto funcionó para mí.

  1. Abra el "Administrador de configuración de SQL Server".
  2. Expanda "Configuración de red de SQL Server", de la lista de la izquierda.
  3. Seleccione "Protocolos para [su nombre de instancia]".
  4. Haga clic derecho en "Canalizaciones con nombre", de la lista de la derecha.
  5. Seleccione "Habilitar"
  6. Reinicie su servicio de instancia.

Como aterricé aquí cuando buscaba una solución a mi propio problema, compartiré mi solución aquí, en caso de que otros lleguen aquí también.

Me estaba conectando bien a SQL Server hasta que mi máquina se trasladó a otra oficina en otro dominio . Luego, después del cambio, recibí este error con respecto al nombre principal de destino. Lo que se solucionó fue conectarse usando un nombre completo como: server.domain.com . Y en realidad, una vez que me conecté al primer servidor de esa manera, pude conectarme a otros servidores usando solo el nombre del servidor (sin la calificación completa), pero su kilometraje puede variar.

El error de contexto SSPI definitivamente indica que se está intentando autenticar usando kerberos.

Compruebe los registros de eventos de seguridad, si está utilizando kerberos, debería ver los intentos de inicio de sesión con el paquete de autenticación: Kerberos.

La autenticación NTLM puede estar fallando y, por lo tanto, se está realizando un intento de autenticación kerberos. ¿También puede ver un error de intento de inicio de sesión NTLM en su registro de eventos de seguridad?

Puede activar el registro de eventos de Kerberos en dev para intentar depurar por qué falla Kerberos, aunque es muy detallado.

El Administrador de configuración Kerberos de Microsoft para SQL Server puede ayudarlo a diagnosticar y solucionar este problema rápidamente.

Aquí hay una buena historia para leer: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

En mi caso, el problema era configurar DNS en el wifi. Eliminé la configuración, la dejé vacía y trabajé.

En mi caso, reiniciar SQL Server 2014 (en mi servidor de desarrollo) solucionó el problema.

Estaba iniciando sesión en Windows 10 con un PIN en lugar de una contraseña. Salí y volví a iniciar sesión con mi contraseña y pude ingresar a SQL Server a través de Management Studio.

Estaba probando IPv6 en un grupo de PC en una red aislada y me encontré con este problema cuando volví a IPv4. Había estado jugando en el directorio activo, DNS y DHCP, así que no tengo idea de lo que presioné para romper la configuración de Kerberos.

Volví a probar la conexión fuera de mi software con este útil consejo para conectar la conectividad remota que encontré.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

Luego, después de una breve búsqueda, encontré esto en el sitio web de Microsoft https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message .

ejecute la herramienta en el servidor SQL para ver si hay algún problema si el estado indica error y luego presione el botón de reparación que aparece.

Esto resolvió el problema para mí.

Estoy ejecutando un sistema de prueba de Mickey Mouse basado en SQL.COM.

setspn -T sql -F -Q */Servername (en este caso SQL01) en la máquina a la que no pude conectarme y en una máquina que sí pude. Luego simplemente eliminé las entradas adicionales en la máquina con problemas y todo funcionó, por ejemplo setspn -D MSSQLSvc/SQL01.SQL.COM:1433 SQL01

He probado todas las soluciones aquí y ninguna de ellas ha funcionado todavía. Una solución alternativa que funciona es hacer clic en Conectar , ingresar el nombre del servidor, seleccionar Opciones, pestaña Propiedades de conexión. Establezca el "Protocolo de red" en "Canalizaciones con nombre". Esto permite a los usuarios conectarse de forma remota utilizando sus credenciales de red. Publicaré una actualización cuando obtenga una solución.

Inicie sesión tanto en su SQL Box como en su cliente y escriba:

ipconfig /flushdns nbtstat -R

Si eso no funciona, renueve su DHCP en su máquina cliente ... Esto funciona para 2 PC en nuestra oficina.

Intenté conectarme a una VM que ejecuta SQL Server 2015 desde mi computadora portátil en una aplicación de consola Visual Studio 2015. Ejecuté mi aplicación la noche anterior y está bien. Por la mañana trato de depurar la aplicación y aparece este error. Intenté ipconfig/flush y release + renew y un montón de otra basura, pero al final ...

Reinicie su VM y reinicie el cliente. Eso me lo arregló. Debería haberlo sabido, reiniciar funciona cada vez.

Me encontré con esto hoy y quería compartir mi solución, ya que esta simplemente se pasa por alto y es fácil de solucionar.

Administramos nuestro propio rDNS y recientemente rehicimos nuestro esquema de nombres de servidores. Como parte de eso, deberíamos haber actualizado nuestro rDNS y haber olvidado hacer esto.

Un ping mostró el nombre de host correcto, pero un ping -a devolvió el nombre de host incorrecto.

Solución fácil: cambie el rDNS, haga un ipconfig / flushdns, espere 30 segundos (solo algo que hago), haga otro ping -a, vea cómo resuelve el nombre de host correcto, conecte ... beneficio.

Me encontré con esto y lo solucioné haciendo 2 cosas:

  1. Concesión de permisos de lectura / escritura de serviciosPrincipalName a la cuenta de servicio utilizando ADSI Edit, como se describe en https://support.microsoft.com/en-us/kb/811889

  2. Eliminar los SPN que existían previamente en la cuenta del equipo SQL Server (a diferencia de la cuenta de servicio) usando

    setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME

    donde 1234 era el número de puerto utilizado por la instancia (el mío no era una instancia predeterminada).

Me encontré con una variante de este problema, aquí estaban las características:

  • El usuario pudo conectarse con éxito a una instancia con nombre, por ejemplo, las conexiones al Server/Instance fueron exitosas
  • El usuario no pudo conectarse a la instancia predeterminada, por ejemplo, las conexiones al Server fallaron con la captura de pantalla del OP con respecto a SSPI
  • El usuario no pudo conectar la instancia predeterminada con un nombre completo, por ejemplo, las conexiones a Server.domain.com fallaron (tiempo de espera)
  • El usuario no pudo conectar la dirección IP sin una instancia con nombre, por ejemplo, las conexiones a 192.168.1.134 fallaron
  • Otros usuarios que no están en el dominio (por ejemplo, usuarios que VPN a la red) pero que usan credenciales de dominio pudieron conectarse con éxito a la instancia predeterminada y la dirección IP

Entonces, después de muchos dolores de cabeza al tratar de descubrir por qué este único usuario no podía conectarse, estos son los pasos que tomamos para solucionar la situación:

  1. Eche un vistazo al servidor en la lista SPN usando
    setspn -l Server
    a. En nuestro caso, decía Server.domain.com
  2. Agregue una entrada al archivo de hosts ubicado en C:/Windows/System32/drivers/etc/hosts (ejecute el Bloc de notas como administrador para modificar este archivo). La entrada que agregamos fue
    Server.domain.com Server

Después de esto, pudimos conectarnos con éxito a través de SSMS a la instancia predeterminada.

Me encontré con uno nuevo para esto: SQL 2012 alojado en el Servidor 2012. Me encargaron crear un clúster para SQL AlwaysOn.
El clúster fue creado, todos recibieron el mensaje SSPI.

Para solucionar los problemas se ejecutó el siguiente comando:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService == la cuenta de dominio que configuré para SQL Necesitaba un administrador de dominio para ejecutar el comando. Solo un servidor en el clúster tuvo problemas.

Luego reinició SQL. Para mi sorpresa, pude conectarme.

No es en absoluto una solución ideal, solo quería agregar esto para referencia futura para cualquiera que vea esta página:

Estaba teniendo este problema al intentar conectarme a una instancia remota de SQL Server usando mi cuenta de dominio, intentar lo mismo en una instancia alojada en una máquina diferente funcionó bien.

Entonces, si tiene la opción de usar una instancia diferente, puede ayudar, pero en realidad esto no resuelve el problema.

Parece que el problema está relacionado con el servidor DNS. Para resolver este problema, cambie la dirección IP a ComputerName.

Ejemplo: cambie el valor "10.0.0.10 / TestDB" a "YourcomputerName / TestDB"

Pasé unas dos horas con el mismo problema. Resultó que "Integrated Security=true" causó el problema.

Intente eliminar este parámetro de la cadena de conexión.

Recibí este error al conectarme a través de SQL Server Management Studio usando la autenticación de Windows. Mi contraseña había expirado pero aún no la había cambiado. Una vez cambiado, tuve que cerrar sesión y volver a iniciarla para que la máquina funcionara con mis nuevas credenciales.

Recibía el mismo error al intentar la autenticación de Windows. Suena ridículo, pero en caso de que ayude a alguien más: fue porque mi cuenta de dominio se bloqueó de alguna manera mientras todavía estaba conectado (!). Desbloqueo de la cuenta lo arregló.

Solo para agregar otra solución potencial a este error tan ambiguo The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider) The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider) The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider) :

Verifique que la IP que se resuelve al hacer ping al Servidor SQL sea la misma que la del Administrador de configuración. Para verificar, abra el Administrador de configuración de SQL Server y luego vaya a Configuración de red de SQL Server> Protocolos para MSSQLServer> TCP / IP.

Asegúrese de que TCP / IP esté habilitado y en la pestaña Direcciones IP, asegúrese de que la IP que resuelve el servidor al hacer ping es la misma aquí. Eso solucionó este error para mí.

También tuve este problema en SQL Server 2014 al iniciar sesión con la autenticación de Windows, para resolver el problema, reinicié mi servidor una vez y luego intenté iniciar sesión, funcionó para mí.

Tuve el mismo problema, pero bloquear y desbloquear la máquina funcionó para mí. A veces, los problemas del firewall darán errores.

No estoy seguro de que funcione para usted o no, solo comparto mi experiencia.

Tuve el mismo problema. Recientemente cambié mi contraseña de Windows y mi sitio web arrojó el error. Traté de cerrar sesión e iniciar sesión pero no funcionó. Entonces me di cuenta de que configuré mi defaultappppol usando mi cuenta en la sección "cuenta personalizada" y configuré la cuenta una vez más usando la nueva contraseña. Esto hizo la magia !!! Por favor, hágame saber sus comentarios sobre esta solución.

Tuve este problema al acceder a la aplicación web. Puede deberse a que he cambiado una contraseña de Windows recientemente.

Este problema se resolvió cuando actualicé la contraseña del grupo de aplicaciones donde alojé la aplicación web.

Tuve este problema con una aplicación ASP.NET MVC en la que estaba trabajando.

Me di cuenta de que había cambiado mi contraseña recientemente y pude arreglarla cerrando la sesión y volviendo a iniciarla.

Tuve este problema en mi servidor sql. Configuré -n mssqlsvc / Hostname.domainname Hostname luego detuve e inicié mi servicio de servidor SQL.

Estoy pensando que simplemente detenerlo e iniciar mi servicio sql lo habría hecho.

Verifique las coincidencias de reloj entre el cliente y el servidor.

Cuando tuve este error de forma intermitente, ninguna de las respuestas anteriores funcionó, luego descubrimos que el tiempo se había desviado en algunos de nuestros servidores, una vez que se sincronizaron nuevamente, el error desapareció. Busque w32tm o NTP para ver cómo sincronizar automáticamente la hora en Windows.