O nome principal de destino está incorreto. Não é possível gerar contexto SSPI

Estou lutando para obter uma conexão do SQL Server da máquina A para a máquina B que está executando o SQL Server.

Pesquisei muito no Google e todas as coisas que encontrei não funcionaram. Nem o conduzem passo a passo pelo processo de resolver isso.

Não estamos usando Kerberos, mas NTLM onde estiver configurado.

As máquinas envolvidas são (xx é usado para ocultar alguns dos nomes da máquina para fins de segurança):

• xxPRODSVR001 - Controlador de Domínio Windows Server 2012
• xxDEVSVR003 - Windows Server 2012 (esta máquina está gerando o erro)
• xxDEVSVR002 - Windows Server 2012 (esta máquina está executando o SQL Server 2012)

Os seguintes SPNs estão registrados no DC (xxPRODSVR001). Eu obscurei o domínio com yyy para fins de segurança:

ServicePrincipalNames registrados para CN = xxDEVSVR002, CN = Computadores, 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 registrados para CN = xxDEVSVR003, CN = Computadores, 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

Agora, se apenas a mensagem de erro do SQL Server fosse mais descritiva e me dissesse a qual nome principal ele estava tentando se conectar, eu poderia diagnosticar isso.

Alguém pode me mostrar como resolver este problema ou você pode ver algo errado no que eu forneci?

Eu ficaria feliz em gerar mais informações de depuração, apenas me diga o que você precisa.

Tive esse problema com um aplicativo ASP.NET MVC no qual estava trabalhando.

Percebi que havia mudado minha senha recentemente e consegui consertá-la fazendo logout e login novamente.

Recebi este erro ao conectar por meio do SQL Server Management Studio usando a autenticação do Windows. Minha senha havia expirado, mas eu ainda não a havia alterado. Depois de alterado, tive que fazer logout e login novamente para que a máquina funcionasse usando minhas novas credenciais.

Tente configurar Integrated Security=truepara remover este parâmetro da string de conexão.

IMPORTANTE: Como o usuário @Auspex comentou,

Remover a Segurança Integrada evitará esse erro, porque o erro ocorre ao tentar fazer o login com suas credenciais do Windows. Infelizmente, na maioria das vezes, você deseja poder fazer o login com suas credenciais do Windows

Eu estava recebendo o mesmo erro ao tentar a autenticação do Windows. Parece ridículo, mas apenas no caso de ajudar alguém: foi porque minha conta de domínio foi bloqueada de alguma forma enquanto eu ainda estava logado (!). Desbloquear a conta corrigiu isso.

Eu estava fazendo login no Windows 10 com um PIN em vez de uma senha. Em vez disso, fiz logout e login novamente com minha senha e consegui entrar no SQL Server por meio do Management Studio.

O erro de contexto SSPI definitivamente indica que a autenticação está sendo tentada usando Kerberos .

Como a autenticação Kerberos, a autenticação do Windows do SQL Server depende do Active Directory , que requer uma relação de confiança entre o seu computador e o controlador de domínio da rede, você deve começar validando essa relação.

Você pode verificar rapidamente essa relação por meio do seguinte comando do Powershell: Test-ComputerSecureChannel .

Test-ComputerSecureChannel -verbose

Se retornar False , você deve reparar o canal seguro do Active Directory do seu computador, pois sem ele nenhuma validação de credenciais de domínio é possível fora do seu computador.

Você pode reparar o canal seguro do seu computador, por meio do seguinte comando Powershell :

Test-ComputerSecureChannel -Repair

Verifique os logs de eventos de segurança, se você estiver usando kerberos, deverá ver tentativas de logon com o pacote de autenticação: Kerberos.

A autenticação NTLM pode estar falhando e, portanto, uma tentativa de autenticação Kerberos está sendo feita. Você também pode ver uma falha de tentativa de logon NTLM em seu log de eventos de segurança.

Você pode ativar o log de eventos do Kerberos no dev para tentar depurar por que o Kerberos está falhando, embora seja muito prolixo.

O Kerberos Configuration Manager da Microsoft para SQL Server pode ajudá-lo a diagnosticar e corrigir rapidamente esse problema.

Aqui está uma boa história para ler: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Apenas para adicionar outra solução potencial para o mais ambíguo dos erros The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Verifique se o IP que é resolvido ao fazer o ping do SQL Server é o mesmo do Gerenciador de configuração. Para verificar, abra o SQL Server Configuration Manager e vá para SQL Server Network Configuration> Protocols for MSSQLServer> TCP / IP.

Certifique-se de que o TCP / IP esteja habilitado e na guia Endereços IP, certifique-se de que o IP que o servidor resolve ao fazer o ping seja o mesmo aqui. Isso corrigiu esse erro para mim.

O problema parece ser um problema de credenciais do Windows. Eu estava recebendo o mesmo erro no meu laptop de trabalho com VPN. Supostamente, estou logado como meu domínio / nome de usuário, que é o que uso com êxito ao me conectar diretamente, mas assim que mudo para uma VPN com outra conexão, recebo este erro. Achei que fosse um problema de DNS, pois poderia fazer ping no servidor, mas descobri que precisava executar o SMSS explicitamente como meu usuário no prompt de comando.

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

Faça login em seu SQL Box e em seu cliente e digite:

ipconfig /flushdns
nbtstat -R

Se isso não funcionar, renove seu DHCP em sua máquina cliente ... Isso funciona para 2 PCs em nosso escritório.

Acabei de encontrar isso e corrigi-lo fazendo duas coisas:

1. Concessão de permissões de leitura / gravação servicePrincipalName para a conta de serviço usando ADSI Edit, conforme descrito em https://support.microsoft.com/en-us/kb/811889

2. Remover os SPNs que existiam anteriormente na conta do computador do SQL Server (em oposição à conta do serviço) usando

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

   onde 1234 era o número da porta usado pela instância (a minha não era uma instância padrão).

No meu caso, reiniciar o SQL Server 2014 (no meu servidor de desenvolvimento) corrigiu o problema.

Eu estava testando o IPv6 em um cluster de PCs em uma rede isolada e tive esse problema quando reverti seu IPv4. Eu tinha jogado no diretório ativo, DNS e DHCP, então não tenho ideia do que cutuquei para quebrar a configuração do Kerberos.

Testei novamente a conexão fora do meu software com esta dica útil para conectar a conectividade remota que encontrei.

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

em seguida, após uma breve pesquisa, encontrou isso no site da Microsoft https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message .

execute a ferramenta no servidor SQL para ver se há algum problema se o status indicar erro e aperte o botão de correção que aparece.

Isso resolveu o problema para mim.

Isso geralmente ocorre devido a nomes de princípios de serviço (SPNs) ausentes, incorretos ou duplicados

Passos para resolver:

1. Confirme qual conta do AD SQL Server está usando
2. Execute o seguinte comando no Powershell ou CMD no modo de administrador (a conta de serviço não deve conter o domínio)

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

3. Certifique-se de que a saída retornada contenha um SPN totalmente qualificado, não totalmente qualificado, com uma porta e sem uma porta.

   Resultado 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. Se você não vir tudo acima, execute o seguinte comando no PowerShell ou CMD no modo de administrador (certifique-se de alterar a porta se você não usar o padrão 1433)

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. Depois que o acima for concluído, normalmente leva alguns minutos para a propagação do DNS

Além disso, se você receber uma mensagem sobre SPNs duplicados encontrados, convém excluí-los e recriá-los

Tive esse problema ao acessar o aplicativo web. Pode ser porque eu mudei uma senha do Windows recentemente.

Esse problema foi resolvido quando eu atualizei a senha do pool de aplicativos em que hospedei o aplicativo da web.

Verifique as correspondências do relógio entre o cliente e o servidor.

Quando eu tive esse erro de forma intermitente, nenhuma das respostas acima funcionou, então descobrimos que o tempo havia passado em alguns de nossos servidores, uma vez que eles foram sincronizados novamente, o erro foi embora. Pesquise w32tm ou NTP para ver como sincronizar automaticamente a hora no Windows.

Como cheguei aqui procurando uma solução para o meu próprio problema, vou compartilhar minha solução aqui, caso outros pousem aqui também.

Eu estava me conectando bem ao SQL Server até que minha máquina foi movida para outro escritório em outro domínio . Então, após a troca, eu estava recebendo este erro em relação ao nome principal de destino. O que corrigiu foi a conexão usando um nome totalmente qualificado , como: server.domain.com . E, na verdade, depois de me conectar ao primeiro servidor dessa maneira, pude me conectar a outros servidores usando apenas o nome do servidor (sem a qualificação completa), mas sua milhagem pode variar.

Corri para isso hoje e queria compartilhar minha correção, já que este é simplesmente esquecido e fácil de corrigir.

Gerenciamos nosso próprio rDNS e recentemente refizemos nosso esquema de nomenclatura de servidor. Como parte disso, deveríamos ter atualizado nosso rDNS e esquecido de fazer isso.

Um ping mostrou o nome de host correto, mas um ping -a retornou o nome de host errado.

Correção fácil: mude o rDNS, faça um ipconfig / flushdns, espere 30 segundos (só algo que eu faço), faça outro ping -a, veja resolvendo o hostname correto, conecte ... lucro.

Encontrei um novo para isso: SQL 2012 hospedado no Server 2012. Recebi a tarefa de criar um cluster para SQL AlwaysOn.
O cluster foi criado, todos receberam a mensagem SSPI.

Para corrigir os problemas, execute o seguinte comando:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== a conta de domínio que configurei para SQL, precisava de um administrador de domínio para executar o comando. Apenas um servidor no cluster apresentou problemas.

Em seguida, reiniciou o SQL. Para minha surpresa, consegui me conectar.

Eu estava tentando me conectar a uma VM executando o SQL Server 2015 do meu laptop em um aplicativo de console do Visual Studio 2015. Eu executei meu aplicativo na noite anterior e está tudo bem. De manhã, tento depurar o aplicativo e recebo este erro. Eu tentei ipconfig/flushe release+renew e um monte de outro lixo, mas no final ...

Reinicie sua VM e reinicie o cliente. Isso resolveu para mim. Eu deveria saber, reiniciar funciona sempre.

Eu tive esse problema no meu servidor sql. Eu setspn -D mssqlsvc \ Hostname.domainname Hostname então parei e iniciei meu serviço de servidor SQL.

Estou pensando que apenas parar e iniciar meu serviço sql teria resolvido.

Eu tive o mesmo problema, mas bloquear e desbloquear a máquina funcionou para mim. Às vezes, problemas de firewall apresentam erros.

Não tenho certeza se vai funcionar para você ou não, apenas compartilhando minha experiência.

Tentei todas as soluções aqui e nenhuma delas funcionou ainda. Uma solução alternativa que está funcionando é clicar em Conectar , inserir o nome do servidor, selecionar Opções, guia Propriedades da conexão. Defina o "Protocolo de rede" como "Pipes nomeados". Isso permite que os usuários se conectem remotamente usando suas credenciais de rede. Vou postar uma atualização quando eu conseguir uma correção.

No meu caso, o problema foi configurar o DNS no wifi. Eu removi as configurações, deixei-as vazias e funcionei.

Certifique-se de que "Pipes nomeados" estejam habilitados no "SQL Server Configuration Manager". Isso funcionou para mim.

1. Abra "SQL Server Configuration Manager".
2. Expanda "Configuração de rede do SQL Server" na lista à esquerda.
3. Selecione "Protocolos para [seu nome de instância]".
4. Clique com o botão direito em "Pipes nomeados", na lista à direita.
5. Selecione "Habilitar"
6. Reinicie seu serviço de instância.

Esta ferramenta da Microsoft é como mágica. Execute-o, conecte-o ao servidor SQL e clique em Reparar

A versão antiga vinculada aqui funcionava no SQL server 2017.

Kerberos Configuration Manager para SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

Na minha situação, estava tentando usar a Segurança Integrada para me conectar de um PC ao SQL Server em outro PC em uma rede sem domínio. Em ambos os PCs, eu estava entrando no Windows com a mesma conta da Microsoft . I transferido para uma conta local em ambos os PCs e SQL Server agora se conecta com êxito.

No meu caso, como estava trabalhando em meu ambiente de desenvolvimento, alguém desligou o controlador de domínio e as credenciais do Windows não puderam ser autenticadas. Após ligar o Controlador de Domínio, o erro desapareceu e tudo funcionou perfeitamente.

Outro nicho para este problema causado por conexões de rede. Eu me conecto por meio do cliente VPN do Windows e esse problema surgiu quando mudei de Wifi para uma conexão com fio. A correção para minha situação foi ajustar manualmente a métrica do adaptador.

No PowerShell, use Get-NetIPInterface para ver todos os valores métricos. Os números mais baixos têm custo mais baixo e, portanto, são preferidos pelo Windows. Troquei a ethernet e a VPN e as credenciais chegaram onde precisavam para que o SSMS ficasse feliz.

Para configurar o recurso de Métrica Automática: No Painel de Controle, clique duas vezes em Conexões de Rede. Clique com o botão direito em uma interface de rede e selecione Propriedades. Clique em Protocolo de Internet (TCP / IP) e selecione Propriedades. Na guia Geral, selecione Avançado. Para especificar uma métrica, na guia Configurações de IP, desmarque a caixa de seleção Métrica automática e, a seguir, insira a métrica desejada no campo Métrica da interface.

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

Encontrei uma variante desse problema, aqui estão as características:

• O usuário conseguiu se conectar com sucesso a uma instância nomeada, por exemplo, conexões paraServer\Instance foram bem-sucedidas
• O usuário não conseguiu se conectar à instância padrão, por exemplo, conexões paraServer falharam com a captura de tela do OP em relação ao SSPI
• O usuário não conseguiu conectar a instância padrão com nome totalmente qualificado, por exemplo, conexões para Server.domain.com falha (tempo limite)
• O usuário não conseguiu conectar o endereço IP sem uma instância nomeada, por exemplo, conexões para 192.168.1.134 falha
• Outros usuários que não estão no domínio (por exemplo, usuários que usam VPN para a rede), mas usando credenciais de domínio, conseguiram se conectar à instância e ao endereço IP padrão

Então, depois de muitas dores de cabeça tentando descobrir por que esse único usuário não conseguiu se conectar, aqui estão as etapas que realizamos para corrigir a situação:

1. Dê uma olhada no servidor na lista SPN usando
   setspn -l Server
   a. No nosso caso, disseServer.domain.com
2. Adicione uma entrada ao arquivo hosts localizado em C:\Windows\System32\drivers\etc\hosts(execute o bloco de notas como administrador para alterar este arquivo). A entrada que adicionamos foi
   Server.domain.com Server

Depois disso, pudemos nos conectar com êxito via SSMS à instância padrão.

Eu também tive esse problema no SQL Server 2014 ao fazer logon com a autenticação do Windows, para resolver o problema, reiniciei meu servidor uma vez e tentei fazer o login, funcionou para mim.