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

89

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.

ingrese la descripción de la imagen aquí

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.

El borde
fuente
No ejecutamos un servidor DNS interno. Pero para eliminar esto como un problema, ¿estás diciendo que debería hacer "ping -a xxxx" o hay otra forma de determinar si hay duplicados?
TheEdge
No soy un experto, pero pensé que los SPN y SSPI eran cosa de Kerberos. ¿Estás seguro de que no estás usando Kerberos?
Dylan Smith
@DylanSmith No es que pueda ver ..... Cuando ejecuté SP en SQL Server (Olvídese del nombre ahora), todo apareció como NTLM. ¿Sabes cómo reviso?
TheEdge
Sé que la pregunta es antigua, así que ahorre tiempo y ejecute esta herramienta: microsoft.com/en-us/download/…
Eduardo

Respuestas:

57

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.

Slothario
fuente
1
Este era mi problema. contraseña cambiada. tenía mi cuenta ejecutando el grupo de aplicaciones.
Dragos Durlut
cuando tuve este problema, me desconecté y volví a iniciar sesión. Resuelto el problema.
shary.sharath
Problema similar. Esto me ayudó a recordar mis acciones. TQ
Reddy
24

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.

Matt Shepherd
fuente
22

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

Anatolyevich
fuente
¿Cómo eliminas eso si la conexión es a través de SSMS?
Geoff Dawdy
23
Así, la eliminación claramente Integrated Security va a evitar este error, ya que el error 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.
Auspex
2
@GeoffDawdy, ¿mi respuesta a continuación puede ayudar? Se debió a una contraseña caducada, que me obligaba a cambiar mi contraseña, cerrar la sesión y volver a iniciarla y luego todo funcionó con normalidad.
Matt Shepherd
3
Ahorre tiempo y ejecute esta herramienta: microsoft.com/en-us/download/…
Eduardo
15

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ó.

Abubakar Mehmood
fuente
12

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.

Don
fuente
Eso es ridículo. Y funcionó. He perdido mucho tiempo con esto. ¡Gracias!
mcb2k3
2
Vaya, eso no fue todo. SSMS me cambió cuando no estaba mirando y regresé a mi cuenta de SQL Server. Pero finalmente intenté cambiar de usar una cuenta de Microsoft para iniciar sesión localmente a usar una cuenta local localmente. Eso funcionó, y parece funcionar ahora incluso si inicio sesión con mi PIN.
mcb2k3
Sí, usar la contraseña en lugar del pin también funcionó para mí. +1 para Microsoft.
BrunoMartinsPro
¡DIOS MIO! ¡No puedo creer que esto realmente haya hecho una diferencia!
arni
8

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í.

Alex
fuente
7

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

ingrese la descripción de la imagen aquí

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/

Sarah
fuente
Esto solucionó el problema para mí. Los SPN se registraron en el objeto de usuario incorrecto en Active Directory. ¡El Administrador de configuración de Kerberos para SQL Server lo solucionó con dos clics!
Craig - MSFT
6

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"

usuario685590
fuente
Tuve un problema similar (iMac vpn con una máquina virtual de Windows). Lo resolví agregando los servidores DNS de mi trabajo a la configuración de la red Wi-Fi de mi Mac. Supongo que hay una forma mejor, pero esto me hizo funcionar.
Erik Pearson
5

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.

Frank.Germain
fuente
hizo su respuesta en mi máquina cliente y SQL Box plus ipconfig/releasey ipconfig/renewen mi máquina cliente y no funcionó para mí; (
AlbatrossCafe
4

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).

EM0
fuente
Cambié una instancia de MS SQL Server de ejecutarse usando NT Service\MSSQLSSERVERa ejecutarse como una cuenta de servicio administrada. Después de hacerlo, SSMS podría conectarse a la base de datos localmente en el servidor, pero no de forma remota desde mi computadora portátil. La reparación de los SPN solucionó el problema.
Hydrargyrum
4

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

mxasim
fuente
Lo mismo
ocurre con
4

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.

Graham Walker
fuente
3

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
  1. 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>
    
  2. 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>
  1. 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.

Nate S.
fuente
2

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.

Ramki
fuente
2

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.

Daniel Bailey
fuente
1

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.

Greg
fuente
Este problema solo me sucedió cuando agregué un certificado a la conexión SQL. El certificado se emitió para el FQDN, así que cuando me conecto a FQDN \ Instance, funcionó.
Slogmeister Extraordinaire
1

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 ...

CrainBramp
fuente
1

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.

Preguntas101
fuente
Tuve el mismo problema, pero no estaba en un clúster. Había cambiado el inicio de sesión del servicio SQL Engine a una cuenta de dominio. Tuve que eliminar los MSSQLSvc/SERVER_FQNName:*SPN de la cuenta de la computadora y luego agregarlos a la cuenta de usuario que ejecuta el servicio.
Slogmeister Extraordinaire
1

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.

AlbatrosCafe
fuente
Experiencia similar, SQLServer 2016 en VM. No estoy seguro de por qué las conexiones comenzaron a fallar. El reinicio de la VM lo solucionó sin necesidad de reiniciar el cliente.
you cantryreachingme
1

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.

Jeff
fuente
Esto es lo que hice después de compararlo setspn -L <Hostname>con un servidor que funcionó. Resultó que todas las instancias que funcionaron no tenían SPN registrado. Realmente no sé qué estoy haciendo, pero aparentemente sin esos SPN registrados, se puede usar NTLM. ¡Gracias!
BenderBoy
Tenga en cuenta que esta no es realmente una solución si desea utilizar Kerberos en lugar de NTLM, como aparentemente debería hacerlo : serverfault.com/a/384721 . De hecho, esta solución básicamente desactiva la autenticación de Kerberos.
BenderBoy
1

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.

somu
fuente
1

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.

Julie
fuente
De hecho, configuré el mío en "TCP / IP". No sé si el acto de cambiarlo solucionó el problema o la configuración específica para mi situación de red ...
Zarepheth
1

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

Como ficou minha configuração do DNS

kbral
fuente
1

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.
S3minaki
fuente
1
Tuve el mismo mensaje. Estaba tratando de conectarme con IP, así que lo hice como stackoverflow.com/users/8568873/s3minaki , es decir, pasos 1-6 pero habilité TCP / IP en lugar de Named Pipes. También en IPALL borré el puerto dinámico TCP y configuré el puerto TCP en su lugar. Asegúrese de que ninguna otra instancia ejecute este puerto o la instancia no se reiniciará. También necesitaba un usuario de SQL, la autenticación de Windows no funcionará. En el Administrador de SQL se conecta con xxxx \ nombre de instancia, portnr. ie 127.0.0.1 \ SQLEXPRESS, 1433
Tomas Hesse
1

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.

Michael Csikos
fuente
1

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.

El_01
fuente
1

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

usuario2442020
fuente
0

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.

sorrell
fuente
0

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í.

harikrishna puppala
fuente