Não é possível criar o contexto SSPI
estou a trabalhar numa aplicação. NET onde estou a tentar construir os scripts da base de dados. Ao construir o projeto, estou recebendo um erro " Não pode criar contexto SSPI.". Este erro é mostrado na janela de saída (dentro do ecrã VS2008) e o processo de construção falhou. Por favor, ajuda nisto. O servidor SQL está configurado para trabalhar na autenticação do Windows e a correr como serviço de rede (estas duas coisas são necessárias para o meu projecto).
Por favor, ajuda-me nisto. Este erro não parece ser consistente. Foi fixado no passado reiniciando a máquina, mudando o tempo do sistema para corresponder o tempo do domínio e algumas sugestões na rede. Por favor, ajuda nisto.16 answers
É um erro bastante comum com uma variedade de causas: comece aqui com KB 811889
- que versão do servidor SQL? E janelas no cliente e no servidor?
- instância local ou de rede SQL?
- domínio ou grupo de trabalho? Provedor?
- mudar a senha
- erros locais no registo do windows? Mais alguma aplicação afectada?
Também pode acontecer se a sua senha expirar.
Tive o mesmo problema depois de mudar o utilizador que estava a executar o serviço MSSQLSERVER
Para resolver SPNs incorrectos com o servidor SQL, usei esta ferramenta
Http://www.microsoft.com/en-us/download/details.aspx?id=39046 - Microsoft® Kerberos Configuration Manager for SQL Server
No meu caso, funcionou muito bem.A primeira coisa que deves fazer é entrar nos registos ({[[0]}) e ver se o servidor SQL successfully registered the Service Principal Name (SPN)
. Se vir algum tipo de erro (The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service
, então sabe por onde começar.
Este erro costuma ocorrer quando a conta do utilizador do Windows está expirada e ele já está ligado com a senha antiga. Basta pedir ao Usuário para reiniciar sua máquina e verificar se a senha está expirada ou ele mudou a senha. Espero que isto ajude!!!!!
Resolvi o meu erro Cannot Generate SSPI Context
usando o Gestor de configuração do servidor SQL. Uma vez que eu tenho o cliente nativo do servidor SQL 10.0 na minha máquina, a conexão com o servidor está tentando usar pipes nomeadas (ou memória compartilhada?). Outras máquinas podiam executar a minha aplicação sem problemas. Quando eu olhei para o gerente de configuração, os pipes Nomeados e memória compartilhada foram ambos ativados (bom). No entanto, sob alias, o nome do computador estava lá com TCP forçado. Desde que eu não sabia que efeito mudar isto teria, eu mudei o texto de conexão em meu programa para usar
Se estiver a hospedar no IIS, Certifique-se de que a senha da conta do AppPool não mudou.
Se tem, então siga estes passos:
- Vá para IIS
- clique em conjuntos de aplicações
- Seleccione o AppPool da sua aplicação
- Clique com o botão direito no seu AppPool
- Configuração Avançada
- identidade
- Actualizar A Senha
- Reiniciar AppPool
O erro "Não pode gerar contexto SSPI" é muito genérico e pode acontecer por uma infinidade de razões. É apenas um erro de cobertura para qualquer erro de Kerberos/NTLM subjacente. O link do artigo KB do Gbn é um ponto de partida muito bom e usualy resolve as questões. Se ainda tiver problemas, recomendo seguir os passos de resolução de problemas em Resolução de erros do Kerberos .
Eu também emiti este problema, e os administradores do servidor resolveram-no seguindo a mesma solução que a indu_teja proposta em http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx
A solução proposta pela indu_teja diz:
Se conseguires este "erro de contexto SSPI". As questões que enfrentamos são:
A questão pode ser por não haver sincronia adequada. SPNs no directório activo.
- não seremos capazes de nos ligar ao servidor SQL remotamente.
- No entanto, seremos capazes de nos ligar ao servidor com a conta local.
Resolução:
Tens de reiniciar a SPN. Use o synytax "SET SPN". Você pode verificar a sintaxe na net uma vez.
- mude a sua conta de serviço do servidor sql de conta de domínio para conta Local, recicle sql, e depois reinicialize de novo com a sua conta de domínio e recicle o servidor sql.
Acabei de ter o mesmo problema e tudo o que fiz foi apagar as credenciais do utilizador no servidor sql usando outro id de utilizador e adicionando-as de volta.
Posso resolver isto se reiniciar o domínio (máquina do servidor, que é o servidor do domínio, mas não está relacionado com o servidor SQL excepto a gestão do domínio) seguido pelas máquinas do cliente.
Obrigado a todos pelo vosso apoio imediato!Teve uma instância muito estranha disso; todos os produtos web que tinham cadeias de conexão contendo o nome do computador do Windows do servidor SQL funcionaram bem, mas os produtos que tinham um FQDN com o domínio interno anexado deu um erro SSPI. seja. COMPUTADOR vs COMPUTADOR.DOMINIO (ping sempre funcionou como esperado)
Isto só deu problemas quando um novo servidor SQL estava a ser usado e os ficheiros hosts apontaram o nome do computador e o nome do computador como um FQDN para a ligação cadeia.
A solução neste caso era definir todas as cadeias de ligação apenas para o nome do computador, removendo as referências do domínio.
SQL: 2008R2 SQL2012
IS: 2008R2
- abriu a máquina remota, o que me levou a mudar a senha Mudei a minha password nesta linha de comandos e entrei na máquina remota. Eu "tranquei" o meu local. máquina (utilizando
windows
+ L
chave para que eu não tivesse que assinar completamente) para que eu pudesse voltar para o sinal na página
Voltei para a minha máquina local com a nova senha.
No meu caso era um NSPL em falta, tinha de executar estes dois comandos:
Setspn - a MSSQLSvc:SERVERNAME SERVERNAME setspn - a MSSQLSvc:SERVERNAME: 1433 SERVERNAME
Em outras palavras, no meu caso eu tinha o FQDN lá já corretamente, mas não apenas o nome NETBIOS, depois de adicioná-los funcionou bem. Bem, inicialmente não aconteceu, mas depois de esperar 2 minutos, aconteceu.
Talvez tenha usado a segurança integrada = SSPI no texto de ligação. SSPI é usado para conexões de confiança usando autenticação Windows.assim, para funcionar corretamente na autenticação do windows, tanto o seu sistema e servidor de banco de dados deve estar no mesmo domínio e usando o mesmo endereço do servidor de DNS, ou deve estar no domínio confiável.
Se o seu sistema e servidor de bases de dados estiverem no mesmo domínio, verifique o endereço do servidor de DNS das propriedades IPV4 na ligação de rede do seu sistema e forneça o mesmo DNS servidor a ser usado pelo servidor de bases de dados.