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

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 en Google mucho y todas las cosas que he encontrado no han funcionado. Tampoco lo guían paso a paso a través del proceso para resolver esto.

No estamos usando Kerberos, pero NTLM donde está configurado.

Las máquinas involucradas son (xx se usa 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 genera el error)
• xxDEVSVR002 - Windows Server 2012 (esta máquina ejecuta SQL Server 2012)

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

ServicePrincipalNames registrado para CN = xxDEVSVR002, CN = Computadoras, DC = yyy, 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

ServicePrincipalNames registrado para CN = xxDEVSVR003, CN = Computadoras, DC = yyy, 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 bien, si solo el mensaje de error de SQL Server fuera más descriptivo y me dijera con qué nombre principal estaba tratando de conectarse, podría diagnosticar esto.

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

Estaría feliz de generar más información de depuración, solo dime lo que necesitas.

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 solucionarlo cerrando la sesión y volviendo a iniciarla.

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 la sesión y volver a iniciarla para que la máquina funcionara con mis nuevas credenciales.

Intente configurar Integrated Security=truepara eliminar este parámetro de la cadena de conexión.

IMPORTANTE: Como comentó el usuario @Auspex,

La eliminación de Integrated Security evitará este error, ya que se produce al intentar iniciar sesión con sus credenciales de Windows. Desafortunadamente, la mayoría de las veces, desea poder iniciar sesión con sus credenciales de Windows

Recibí el mismo error al intentar a través de 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 aún estaba conectado (!). El desbloqueo de la cuenta lo solucionó.

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

Solo para agregar otra posible solución a este error tan ambiguo 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 comprobarlo, 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 a la que resuelve el servidor al hacer ping sea la misma aquí. Eso solucionó este error para mí.

El error de contexto SSPI definitivamente indica que se está intentando la autenticación mediante Kerberos .

Dado que la autenticación Kerberos, la autenticación de Windows de SQL Server se basa en Active Directory , que requiere una relación sólida entre su computadora y su controlador de dominio de red, debe comenzar por validar esa relación.

Puede verificar rápidamente esa relación, a través del siguiente comando de Powershell Test-ComputerSecureChannel .

Test-ComputerSecureChannel -verbose

Si devuelve Falso , debe reparar el canal seguro de Active Directory de su computadora, ya que sin él no es posible la validación de credenciales de dominio fuera de su computadora.

Puede reparar el canal seguro de su computadora, a través del siguiente comando de Powershell :

Test-ComputerSecureChannel -Repair

Verifique 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 en el 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 tratar de depurar por qué falla el kerberos, aunque es muy detallado.

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

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

El problema parece ser un problema de credenciales de Windows. Recibía el mismo error en mi computadora portátil de trabajo con una VPN. Supuestamente he iniciado sesión como mi dominio / nombre de usuario, que es lo que uso con éxito cuando me conecto directamente, pero tan pronto como me muevo a una VPN con otra conexión, recibo este error. Pensé que era un problema de DNS ya que podía hacer ping al servidor, pero resulta que necesitaba ejecutar SMSS explícitamente como mi usuario desde el símbolo del sistema.

por ejemplo, runas / netonly / user: YourDoman \ YourUsername "C: \ Archivos de programa (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"

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.

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

1. Otorgar permisos de lectura / escritura servicePrincipalName a la cuenta de servicio mediante ADSI Edit, como se describe en https://support.microsoft.com/en-us/kb/811889

2. Eliminar los SPN que existían anteriormente en la cuenta de equipo de 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 (la mía no era una instancia predeterminada).

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

Estaba probando IPv6 en un grupo de PC en una red aislada y encontré este problema cuando revirtí mi 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 dice error, luego presione el botón de reparación que aparece.

Esto me resolvió el problema.

Esto generalmente se debe a nombres de principios de servicio (SPN) faltantes, incorrectos o duplicados

Pasos para resolver:

1. Confirme que cuenta AD está usando SQL Server
2. Ejecute el siguiente comando en Powershell o CMD en modo administrador (la cuenta de servicio no debe contener el dominio)

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

3. Asegúrese de que la salida devuelta contenga un SPN que esté completamente calificado, no completamente calificado, con un puerto y sin un puerto.

   Rendimiento esperado:

   Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
   MSSQLSvc/<ServerName>.<domain>.com:1433
   MSSQLSvc/<ServerName>:1433                                           
   MSSQLSvc/<ServerName>.<domain>.com
   MSSQLSvc/<ServerName>
   

4. Si no ve todo lo anterior, ejecute el siguiente comando en PowerShell o CMD en modo de administrador (asegúrese de cambiar el puerto si no usa el 1433 predeterminado)

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>

5. Una vez que se completa lo anterior, normalmente toma unos minutos para la propagación de DNS

Además, si recibe un mensaje sobre SPN duplicados encontrados, es posible que desee eliminarlos y volver a crearlos.

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 para el grupo de aplicaciones donde alojé la aplicación web.

Compruebe que su reloj coincide 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.

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

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 solucionó fue conectarse usando un nombre completo como: servidor.dominio.com . Y de hecho, 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 millaje puede variar.

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 nomenclatura de servidores. Como parte de eso, deberíamos haber actualizado nuestro rDNS y habernos olvidado de 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 se resuelve el nombre de host correcto, conecte ...

Me encontré con uno nuevo para esto: SQL 2012 alojado en el servidor 2012. Se le asignó la tarea de crear un clúster para SQL AlwaysOn.
Se creó el clúster. Todos recibieron el mensaje SSPI.

Para solucionar los problemas, 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 del clúster tuvo problemas.

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

Estaba intentando conectarme a una máquina virtual 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, intento depurar la aplicación y aparece este error. Intenté ipconfig/flushy release+ renewy un montón de basura, pero al final ...

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

Tuve este problema en mi servidor sql. Setpn -D mssqlsvc \ Hostname.domainname Hostname luego detuve e inicié mi servicio de servidor SQL.

Estoy pensando que simplemente detener e iniciar mi servicio SQL lo habría hecho.

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

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

He probado todas las soluciones aquí y ninguna 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 tenga una solución.

En mi caso, el problema fue configurar DNS en el wifi. Eliminé los ajustes, los dejé vacíos y trabajé.

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

1. Abra "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.

Esta herramienta de Microsoft es como Magic. Ejecútelo, conéctelo al servidor SQL y haga clic en Reparar

La versión anterior vinculada aquí funcionó en SQL Server 2017.

Administrador de configuración de Kerberos para SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

En mi situación, estaba intentando usar Integrated Security para conectarme desde una PC a SQL Server en otra PC en una red sin dominio. En ambas PC, estaba iniciando sesión en Windows con la misma cuenta de Microsoft . Me cambié a una cuenta local en ambas PC y SQL Server ahora se conecta correctamente.

En mi caso, ya que estaba trabajando en mi entorno de desarrollo, alguien había cerrado el controlador de dominio y las credenciales de Windows no se pudieron autenticar. Después de encender el controlador de dominio, el error desapareció y todo funcionó bien.

Otro nicho de este problema causado por las conexiones de red. Me conecto a través del cliente VPN de Windows y este problema apareció cuando cambié de Wifi a una conexión por cable. La solución para mi situación fue ajustar manualmente la métrica del adaptador.

En powershell, use Get-NetIPInterface para ver todos los valores de las métricas. Los números más bajos son de menor costo y, por lo tanto, son los preferidos por Windows. Cambié ethernet y VPN y las credenciales llegaron donde debían estar para que SSMS fuera feliz.

Para configurar la función Métrica automática: En el Panel de control, haga doble clic en Conexiones de red. Haga clic con el botón derecho en una interfaz de red y luego seleccione Propiedades. Haga clic en Protocolo de Internet (TCP / IP) y luego seleccione Propiedades. En la pestaña General, seleccione Avanzado. Para especificar una métrica, en la pestaña Configuración de IP, seleccione para desmarcar la casilla de verificación Métrica automática y luego ingrese la métrica que desee en el campo Métrica de interfaz.

Fuente: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

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

• El usuario pudo conectarse con éxito a una instancia con nombre, por ejemplo, las conexiones Server\Instancefueron exitosas
• El usuario no pudo conectarse a la instancia predeterminada, por ejemplo, las conexiones Serverfallaron con la captura de pantalla del OP con respecto a SSPI
• El usuario no pudo conectar la instancia predeterminada con el nombre completo, por ejemplo, las conexiones Server.domain.comfallaron (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.134fallaron
• Otros usuarios que no están en el dominio (por ejemplo, usuarios que usan VPN a la red) pero que usan credenciales de dominio pudieron conectarse exitosamente a la instancia y dirección IP predeterminadas

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

1. Eche un vistazo al servidor en la lista de SPN usando
   setspn -l Server
   a. En nuestro caso, decíaServer.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.

Yo también tuve este problema en SQL Server 2014 mientras iniciaba 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í.