O nome principal do alvo está incorrecto. Não é possível gerar o contexto SSPI
estou a lutar para conseguir uma ligação do servidor SQL da máquina a à máquina B que está a correr o servidor SQL.
Pesquisei muito no Google e todas as coisas que encontrei não resultaram. Também não o conduzem passo a passo ao longo do processo de resolução deste problema. Não estamos a usar Kerberos, mas NTLM onde está configurado.As máquinas envolvidas são (xx é usado para obscurecer alguns dos nomes da máquina para segurança finalidades):
- xxPRODSVR001 - Windows Server 2012 Domain Controller
- xxDEVSVR003 - Windows Server 2012 (Esta máquina está a gerar o erro)
- xxDEVSVR002 - Windows Server 2012 ( Esta máquina está a correr o SQL Server 2012)
os seguintes NPS estão registados na DC (xxPRODSVR001). Obscureci o domínio com o yyy para fins de segurança.
Agora, se ao menos a mensagem de erro do servidor SQL fosse mais descritiva e me dissesse que nome principal estava tentando se conectar a eu poderia ser capaz de diagnosticar isso. Então, alguém pode explicar-me como resolver este caso ou pode ver alguma coisa no que eu disse que está errado? Ficaria feliz em gerar mais informações de depuração, diga-me o que precisa.Nome do serviço registado 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
nomes de Serviços Registados 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
27 answers
Tente remover este param do texto de ligação.
Recebi este erro ao ligar-me através do SQL Server Management Studio usando a autenticação do Windows. A minha senha expirou, mas ainda não a tinha alterado. Uma vez mudado, eu então tive que sair e entrar de volta para que a máquina estava trabalhando usando minhas novas credenciais.
Só para adicionar outra solução potencial a esta mais ambígua de erros The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider)
:
Verifique se o IP que é resolvido ao passar o servidor SQL é o mesmo que o do Gestor de configuração. Para verificar, abra o Gestor de configuração do servidor SQL e, em seguida, vá para a configuração da rede do servidor SQL > protocolos para o servidor MSSQL > TCP/IP.
Certifique-se de que o TCP/IP está activo e na página de endereços IP, certifique-se de que o IP que o servidor resolve quando o pinging é o mesmo um aqui. Isso corrigiu este erro para mim.
Autentique-se tanto na sua caixa SQL como no seu cliente e escreva:
ipconfig /flushdns
nbtstat -R
Se isso não funcionar, renove o DHCP na máquina do cliente... Isto funciona para dois computadores no nosso escritório.
Estava a ter o mesmo erro ao tentar a autenticação do windows. Parece ridículo, mas só no caso de ajudar outra pessoa: foi porque a minha conta de domínio ficou bloqueada de alguma forma enquanto eu ainda estava logado (!). Desbloquear a conta corrigiu-o.
O erro de contexto SSPI indica definitivamente que a autenticação está a ser tentada usando o kerberos.
Verifique os registos dos eventos de segurança, se estiver a usar o kerberos, deverá ver as tentativas de logon com o pacote de autenticação: Kerberos.
A autenticação NTLM pode estar a falhar e por isso está a ser feita uma tentativa de autenticação kerberos. Você também pode ver um logon NTLM tentativa de falha no seu registro de eventos de segurança?
Podes ligar o registo de eventos do kerberos no dev para tentar debug why the kerberos is failing, although it is very verbose.
- conceder permissões de leitura / escrita do servicePrincipalName à conta de serviço usando o ADSI Edit, como descrito em https://support.microsoft.com/en-us/kb/811889
-
Remover os SPNs que existiam anteriormente no servidor SQL conta de computador (em oposição à conta de serviço) usando
setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
Onde 1234 foi o número do Porto utilizado pela instância (o meu não era um instância padrão).
Este problema foi resolvido Quando eu atualizei a senha para o pool de aplicativos onde eu hospedei a aplicação web.
Estava a ligar o fine ao servidor SQL até a minha máquina ser transferida para outro escritório em outro domínio. Então, depois do interruptor, eu estava recebendo este erro sobre o nome principal do alvo. O que é que se ligava usando um nome completamente qualificado como: server.domain.com e na verdade, uma vez que me conectei ao ... primeiro servidor dessa forma, eu poderia me conectar a outros servidores usando apenas o nome do servidor (sem a qualificação completa), mas sua quilometragem pode variar.
Um ping mostrou o nome correcto da máquina, mas um ping-a devolveu o nome errado.
Solução fácil: mudar o rDNS, fazer um ipconfig / flushdns, esperar 30 segundos( apenas algo que eu faço), fazer outro ping-a, vê - lo a resolver o nome correcto da máquina, ligue-se ... lucro.
O Cluster foi criado todos receberam a mensagem SSPI.
Para corrigir os problemas, executou o seguinte comando:
setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService
DomainNamerunningSQLService
== a conta de domínio I definida para SQL
Eu precisava de um administrador de domínio para executar o comando. Apenas um servidor no grupo tinha problemas.
Depois reiniciado SQL. Para minha surpresa, consegui me conectar.
Verifique se o seu relógio corresponde entre o cliente e o servidor.
Quando tive este erro intermitentemente, nenhuma das respostas acima funcionava, então descobrimos que o tempo tinha desaparecido em alguns dos nossos servidores, uma vez que eles foram sincronizados novamente, o erro desapareceu. Procure por w32tm ou NTP para ver como sincronizar automaticamente o tempo no Windows.- O Utilizador foi capaz de ligar com sucesso a uma instância nomeada, por exemplo, as ligações a
Server\Instance
foram bem sucedidas - O Utilizador foi incapaz de se ligar à instância predefinida, por exemplo, as ligações a
Server
falharam com a imagem do OP em relação ao SSPI - O Utilizador não foi capaz de ligar a instância predefinida com um nome totalmente qualificado, por exemplo, ligações a
Server.domain.com
falha (tempo-limite) - O Utilizador não conseguiu ligar o endereço IP sem uma instância nomeada, por exemplo, as ligações a
192.168.1.134
falharam - outros utilizadores que não estão no domínio (por exemplo, utilizadores que VPN à rede) mas que utilizam credenciais de domínio foram capazes de se ligar com sucesso à instância por omissão e ao endereço IP
- dê uma vista de olhos no servidor na lista SPN usando
setspn -l Server
A. No nosso caso, diziaServer.domain.com
- adicione um item ao ficheiro hosts localizado em
C:\Windows\System32\drivers\etc\hosts
(execute o bloco de notas como Administrador para alterar este ficheiro). A entrada que adicionámos foiServer.domain.com Server
Depois disso, fomos capazes de nos conectar com sucesso através do SSMS à instância padrão.
release
+ renew
e um monte de outro lixo, mas no fim...
Reinicie o seu VM e reinicie o cliente. Isso resolveu tudo para mim. Eu devia saber, reiniciar funciona sempre.
Eu também tive este problema no servidor SQL 2014 ao iniciar sessão com a autenticação do windows, para resolver o problema que reiniciei o meu servidor uma vez e depois tentar fazer login, funcionou para mim.
defaultappppol
usando a minha conta na secção" conta personalizada " e configurei a conta mais uma vez usando a nova senha. Isto fez a magia!!! Por favor, deixe-me saber o seu feedback sobre esta solução.
Eu corri {[[[0]} (Neste caso SQL01) tanto na máquina a que não consegui ligar, como numa máquina a que consegui. I then simply removed the additional entries in the problem machine and it all worked, e.g. setspn -D MSSQLSvc/SQL01.SQL.COM:1433 SQL01
Parece que o problema está relacionado com o servidor DNS. Para resolver este problema, mude o endereço IP para o nome do computador.
Exemplo: Alterar o valor "10. 0. 0. 10\TestDB "para" o seu nome completo\TestDB "Não é de todo uma solução ideal, eu só queria adicionar isto para referência futura para qualquer pessoa que veja esta página:
Eu estava a ter este problema a tentar ligar-me a uma instância remota do servidor SQL usando a minha conta de domínio, a tentar a mesma coisa numa instância hospedada numa máquina diferente funcionou bem.
Então, se você tem a opção de apenas usar uma instância diferente, isso pode ajudar, mas isso realmente não aborda o que quer que seja o problema.
No meu caso, reiniciar o servidor SQL 2014 (no meu servidor de desenvolvimento) corrigiu o problema.
Integrated Security=false
Faça com que esta bandeira seja falsa no texto de ligação webconfig
. Vai funcionar!
Verifique Por favor as permissões para o nome de utilizador mencionado no SQL server management studio Faça com que seja a opção sysadmin e depois faça Integrated Security=False
no .ficheiro de configuração.
Disparar 2 comandos na máquina cliente
Ipconfig / flushdns
Purga Klist.
Instale o Gestor de configuração kerbarose no computador do cliente.
Finalmente, reinicie a máquina cliente e os principais serviços de servidor SQL. Execute a aplicação na máquina cliente. Isto funciona 100% correctamente.