Pergunta

Eu estou trabalhando em um aplicativo .NET onde eu estou tentando construir os scripts de banco de dados. Embora a construção do projeto, eu estou recebendo um erro "Não é possível criar SSPI contexto.". Este erro é mostrado na janela de saída (dentro VS2008 tela) e o processo de construção falhou. Por favor, ajude com isso. SQL Server está configurado para trabalhar em autenticação do Windows e executado como serviço de rede (essas duas coisas são obrigação para o meu projeto).

Por favor, ajuda sobre isso. Este erro não é parece ser consistente. Ele foi fixada no passado reiniciando a máquina, alterar a hora do sistema para coincidir com o tempo de domínio e algumas sugestões na rede. Por favor, ajude com isso.

Foi útil?

Solução

É bem um erro comum com uma variedade de causas: começar aqui com KB 811889

  • Qual versão do SQL Server?
  • E Windows no cliente e servidor?
  • instância do SQL local ou de rede?
  • Domínio ou grupo de trabalho? Provider?
  • Alterar senha
  • janelas locais registrar erros?
  • Quaisquer outros aplicativos afetados?

Outras dicas

Parece que o seu PC não tem contato com um controlador de domínio de autenticação por pouco tempo. (Eu costumava ter isso acontecer no meu laptop algumas vezes.)

Também pode acontecer se sua senha expira.

Eu tive o mesmo problema depois de mudar o usuário que estava executando o MSSQLSERVER-Service

Para resolver SPN incorreto com o SQL Server eu usei esta ferramenta

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

No meu caso, funcionou muito bem.

Este erro geralmente ocorre quando a conta de usuário do Windows expirou e ele já está logado com senha antiga. Basta perguntar ao usuário reiniciar o seu equipamento e verifique se a senha está expirado ou ele mudou a senha. Espero que isso ajude !!!!!

A primeira coisa que você deve fazer é ir para os logs (Management\SQL Server Logs) e ver se successfully registered the Service Principal Name (SPN) SQL Server. Se você ver 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 você sabe por onde começar.

Vimos isso acontecer quando nós mudamos a conta do SQL Server foi executado. Redefini-lo a conta do sistema local resolveu o problema. A Microsoft também tem um guiar sobre como configurar manualmente o SPN.

Eu resolvi meu erro Cannot Generate SSPI Context usando o SQL Server Configuration Manager. Desde que eu tenho SQL Server Native Client 10.0 na minha máquina, a conexão com o servidor está tentando usar pipes nomeados (ou memória compartilhada?). Outras máquinas poderia executar o meu aplicativo sem nenhum problema. Quando olhei para o gerenciador de configuração, pipes nomeados e memória compartilhada foram habilitados (bom). No entanto, sob alias, o nome do computador estava lá com TCP forçado. Desde que eu não sabia o efeito mudando isso teria, eu mudei a seqüência de conexão no meu programa para usar . em seu lugar. Fixo.

Se você está hospedando no IIS, certifique-se a senha para a conta AppPool não mudou .

Se ele tem, então siga estes passos:

  • Vá para IIS
  • Clique em pools de aplicativos
  • Selecione o AppPool de sua aplicação
  • clique direito em seu AppPool
  • Configurações avançadas
  • Identidade
  • Atualização de senha
  • Restart AppPool

O erro "Não é possível gerar contexto SSPI" é muito genérica e pode acontecer por uma infinidade de razões. É apenas um erro de cobertura para qualquer subjacentes erro Kerberos / NTLM. ligação KB artigo de GBN é um bom ponto de partida e usualy resolve os problemas. Se você ainda tiver problemas eu recomendo seguir os passos de resolução de problemas em Erros de Kerberos .

Eu também emitiu este problema, e os administradores do servidor resolvido-lo seguindo a mesma solução que indu_teja proposto em http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx

A solução proposta pela indu_teja diz:

Se você receber esse "erro contexto SSPI". Os problemas que enfrentamos são:

  1. Não será capaz de se conectar ao SQL Server remotamente.
  2. No entanto, será capaz de se conectar ao servidor com a conta local.

Causa: O problema pode ser becasue de não adequada sincronização happenign fro SPN no Active Directory.

Resolução:

  1. Você precisa redefinir SPN. Use o synytax "SET SPN". Você pode verificar a sintaxe em vez net.
  2. Alterar a conta de serviço SQL Server a partir da conta de domínio para a conta local, reciclar sql, e depois reiniciar novamente com sua conta de domínio e reciclar o SQL Server.

Eu só tive o mesmo problema e tudo que eu fiz foi apagar o registo de usuário em credenciais no servidor SQL usando outro ID do usuário e adicioná-los de volta.

Aqui é o meu caso. Eu tinha uma máquina remota que sediou SQL Server. De minha máquina local, eu estava tentando acessar a instância de SQL através de algum código C # e eu estava ficando este erro. Minha senha da conta de usuário na minha máquina / domínio tinha expirado . Eu fixo-lo com o seguinte:

  1. Inaugurado a máquina remota, que me levou para uma alteração de senha
  2. Eu mudei minha senha dentro deste pronta e conectado ao computador remoto
  3. I "bloqueado" minha máquina local (usando windows chave L + então eu não tenho que assinar completamente fora) para que eu pudesse voltar para o sign-on página
  4. I assinado de volta para minha máquina local com a nova senha

Tudo então funcionou bem.

No meu caso, foi um SPN faltando, teve de correr estes dois comandos:

setspn -a MSSQLSvc: SERVERNAME SERVERNAME setspn -a MSSQLSvc: SERVERNAME: 1433 SERVERNAME

Em outras palavras meu caso eu tive o FQDN lá já corretamente, mas não apenas o nome NETBIOS, depois de adicionar estes funcionou muito bem. Bem, inicialmente, isso não aconteceu, mas depois de esperar 2 minutos ele fez.

Eu tinha essa de erros isso aconteceu porque minha senha expirou e eu tive que mudá-lo. Eu não percebi isso, porque em alguns programas que eu ainda podia entrar e tudo iria funcionar normalmente (incluindo janelas), mas eu não podia fazer logon para qualquer servidor SQL.

Talvez você tenha usado Integrated Security = SSPI na seqüência de conexão. SSPI é usado para conexões confiáveis ??usando o Windows Authentication.hence, para funcionar corretamente no Windows Authentication, seja o servidor do sistema e banco de dados deve estar no mesmo domínio e usando o endereço dos servidores DNS mesma, ou devem estar em domínio confiável.

Se o seu sistema eo servidor de banco de dados está em mesmo domínio, verificar o endereço dos servidores DNS das propriedades IPv4 conexão de rede do seu sistema e fornecer mesmo servidor DNS a ser utilizado por servidor de banco de dados.

Em vb.net, se você estiver usando um servidor ligado do que verificar a sua cadeia de conexão. Integrated Security = true; não funciona em todos os provedores de SQL, ele lança uma exceção quando usado com o provedor OLE DB. Então, basicamente Integrated Security = SSPI; é o preferido desde funciona tanto com SQLClient & OleDB proporcionar. Se você ainda atingido com erro, remova a sintaxe completamente.

Eu posso capaz de obter este resolvidos reiniciando o domínio (máquina do servidor, que é o domínio servidor, mas não relacionados com o SQL Server, exceto gestão de domínio), seguido pelas máquinas clientes.

Obrigado a todos por seu apoio imediato!

Tive uma instância muito estranho deste; Todos os produtos da web que tiveram seqüências de conexão que contêm o nome do computador janelas do servidor SQL funcionou bem, mas os produtos que tiveram um FQDN com o domínio interno anexado deu um erro SSPI. i.e. NOME DO COMPUTADOR vs computername.domain (Ping sempre funcionou como esperado)

Esta só deu problemas quando um novo servidor SQL estava sendo usado e arquivos hosts apontou tanto o nome do computador e o nome do computador como um FQDN para as seqüências de conexão.

solução neste caso foi o de definir todas as seqüências de conexão para o nome do computador apenas, removendo as referências de domínio.

SQL: 2008R2 SQL2012

O IIS: 2008R2

Tivemos esta questão em instâncias em que mudaram o utilizador do serviço de Domain1 \ ServiceUser para Domain2 \ ServiceUser. Os SPNs permaneceu registrada sob Domain1 \ ServiceUser, e nunca registrada sob Domain2 \ ServiceUser. Registramos os SPN sob Domain2 \ ServiceUser, mas a questão persistiu. Em seguida, removeu os SPN sob Domain1 \ ServiceUser, eo problema foi resolvido.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top