Erro "Não é possível gerar contexto de SSPI" ao usar autenticação do Windows para se conectar ao SQL Server

Aplica-se ao: SQL Server
Número original do KB: 811889

Ao usar o autenticação do Windows para conectar uma instância do SQL Server remotamente, você recebe a seguinte mensagem de erro:

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

Perguntas frequentes

O que é SSPI?

A SSPI (Security Support Provider Interface) é um conjunto de APIs do Windows que permite delegação e autenticação mútua em qualquer camada de transporte de dados genérico, como soquetes TCP/IP. Um ou mais módulos de software fornecem os recursos de autenticação reais. Cada módulo é chamado de SSP (Provedor de Suporte de Segurança) e é implementado como uma DLL (Biblioteca de Vínculo Dinâmico).

O que é Kerberos?

O protocolo Kerberos v5 é um pacote de segurança padrão do setor e é um dos três pacotes de segurança em sistemas operacionais Windows. Para obter mais informações, consulte SSPs (Provedores de Suporte de Segurança)

O que significa o erro "Não é possível gerar contexto SSPI"?

Esse erro significa que o SSPI tenta, mas não pode usar a autenticação Kerberos para delegar credenciais de cliente por meio de TCP/IP ou Pipes Nomeados para SQL Server. Na maioria dos casos, um SPN (Nome da Entidade de Serviço) configurado incorretamente causa esse erro.

O que é SPN?

Um SPN (Nomes de Entidade de Serviço) é um identificador exclusivo de uma instância de serviço. Os SPNs são usados pela autenticação Kerberos para associar uma instância de serviço a uma conta de logon de serviço. Esse processo de associação permite que um aplicativo cliente solicite que o serviço autentique uma conta mesmo que o cliente não tenha um nome de conta.

Por exemplo, um SPN típico para um servidor que está executando uma instância do SQL Server é o seguinte:

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

O formato de um SPN para uma instância padrão é o mesmo que um SPN para uma instância nomeada. O número da porta é o que vincula o SPN a uma instância específica. Para obter mais informações sobre como registrar os SPNs de Serviço do SQL Server, consulte Registrar um Nome da Entidade de Serviço para Conexões Kerberos.

Por que o SSPI usa autenticação NTLM ou Kerberos?

A autenticação do Windows é o método preferencial para que os usuários se autentiquem no SQL Server. Os clientes que usam a autenticação do Windows são autenticados usando NTLM ou Kerberos.

Quando um cliente SQL Server usa segurança integrada em soquetes TCP/IP para um servidor remoto que está executando o SQL Server, a biblioteca de rede do cliente SQL Server usa a API SSPI para executar a delegação de segurança. O cliente de rede do SQL Server faz uma chamada para a função AcquireCredentialsHandle e passa "negotiate" para o parâmetro pszPackage. Esse processo notifica o provedor de segurança subjacente para negociar a delegação. Nesse contexto, "negociar" significa experimentar a autenticação Kerberos ou NTLM em computadores baseados no Windows. Em outras palavras, o Windows usará a delegação Kerberos se o computador de destino SQL Server tiver um SPN associado e configurado corretamente. Caso contrário, o Windows usará a delegação NTLM. Se o cliente SQL Server estiver se conectando localmente no mesmo computador em que o SQL Server reside, o NTLM sempre será usado.

Por que a conexão não faz failover para NTLM depois de ter problemas com o Kerberos?

O código do de driver do SQL Server no cliente usa a API de rede WinSock para resolver o DNS totalmente qualificado do servidor quando o driver usa autenticação do Windows para se conectar ao SQL Server. Para executar essa operação, o código do driver chama as APIs WinSock gethostbyname e gethostbyaddr. Se a segurança integrada for usada, o driver tentará resolver o DNS totalmente qualificado do servidor, mesmo que um endereço IP ou um nome de host seja passado como o nome do servidor.

Quando o driver do SQL Server no cliente resolve o DNS totalmente qualificado do servidor, o DNS correspondente é usado para formar o SPN para o servidor. Portanto, problemas ao resolver o endereço IP ou o nome do host para um DNS totalmente qualificado pelo WinSock podem fazer com que o driver do SQL Server crie um SPN inválido para o servidor.

Por exemplo, o driver do SQL Server do lado do cliente pode ser usado como um DNS totalmente qualificado para resolver SPNs inválidos da seguinte maneira:

• MSSQLSvc/SQLSERVER1:1433
• MSSQLSvc/123.123.123.123:1433
• MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
• MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Quando o driver do SQL Server forma um SPN inválido, a autenticação ainda funciona porque a interface SSPI tenta pesquisar o SPN no serviço do Active Directory. Se a interface SSPI não encontrar o SPN, a autenticação do Kerberos não será executada. Nesse momento, a camada SSPI alterna para o modo de autenticação NTLM e o logon usa a autenticação NTLM e normalmente é bem-sucedido. Se o driver do SQL Server formar um SPN válido que não está atribuído ao contêiner apropriado, o driver testará o SPN, mas não poderá usá-lo. Nesse caso, pode ocorrer um erro "Não é possível gerar contexto SSPI". Se a conta de inicialização do SQL Server for uma conta do sistema local, o contêiner apropriado será o nome do computador. Para qualquer outra conta, o contêiner apropriado é a conta de inicialização do SQL Server. A autenticação usa o primeiro SPN encontrado, portanto, verifique se nenhum dos SPNs está atribuído a contêineres incorretos. Em outras palavras, cada SPN só deve ser atribuído a um contêiner.

Como posso verificar o método de autenticação da conexão?

Para determinar o método de autenticação de uma conexão, execute a seguinte consulta:

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;  

Para obter mais informações, consulte Determinar se estou conectado ao SQL Server usando Autenticação Kerberos.

Como criar SPNs para o SQL Server?

Quando uma instância do Mecanismo de Banco de Dados do SQL Server é iniciada, o SQL Server tenta registrar automaticamente o SPN para o serviço do SQL Server usando a API DsWriteAccountSpn. Essa chamada terá êxito se a conta de serviço do SQL Server tiver direitos de Leitura servicePrincipalName e Gravação servicePrincipalName no Active Directory. Caso contrário, você precisará que o administrador do Active Directory registre manualmente o SPN correto usando o Microsoft Kerberos Manager para SQL Server ou a ferramenta Setspn interna. Para obter mais informações sobre como gerenciar SPNs para SQL Server, consulte Registrar um Nome de Entidade de Serviço para Conexões Kerberos.

Corrigir o erro com o Kerberos Configuration Manager (Recomendado)

Há vários motivos pelos quais as conexões Kerberos falham, como SPNs configurados incorretamente, problemas de resolução de nomes ou direitos insuficientes para contas de inicialização do serviço do SQL Server. O Microsoft KCM (Kerberos Configuration Manager) é uma ferramenta que pode ajudar a verificar as causas do erro. O KCM também fornece opções para corrigir quaisquer problemas identificados no processo.

Siga estas etapas para corrigir o erro usando o KCM.

1. No computador em que você tem problemas de conectividade, baixe e instale o Kerberos Configuration Manager.

2. Inicie KerberosConfigMgr.exe na pasta %SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager. Em seguida, use uma conta de domínio que tenha permissões para se conectar ao computador do SQL Server ao qual não é possível se conectar.

3. Selecione Conectar, deixando o nome do servidor e outros detalhes conforme aplicável ao seu cenário em branco se você estiver executando o KCM no computador do SQL Server. Selecione Conectar para executar a análise. Depois que o KCM terminar de recuperar as informações necessárias, ele alterna automaticamente para a guia SPN e, por padrão, mostra informações para SQL Server, SQL Server Reporting Services, Analysis Services e Ouvintes do AG. Para solucionar esse erro, desmarque tudo, exceto o SQL Server.

4. Examine o diagnóstico da ferramenta usando a coluna Status e siga as etapas relevantes para resolver o problema:

   Status	Mais informações	Ação
   Good	O item verificado está configurado corretamente. Você pode prosseguir para o próximo item na saída.	Nenhuma ação necessária.
   O SPN necessário está ausente	Esse status é relatado quando o SPN identificado na coluna SPN Necessário está ausente para a conta de inicialização do SQL Server no Active Directory.	1. Selecione Corrigir para examinar as informações na caixa de diálogo Aviso. 2. Selecione Sim para adicionar o SPN ausente ao Active Directory. 3. Se sua conta de domínio tiver as permissões necessárias para atualizar o Active Directory, o SPN necessário será adicionado ao Active Directory. 4. Se sua conta de domínio não tiver as permissões necessárias para atualizar o Active Directory, use Gerar ou Gerar Tudo para gerar o script que ajudará o administrador do Active Directory a adicionar os SPNs ausentes. 5. Depois que os SPNs forem adicionados, execute o Kerberos Configuration Manager novamente para verificar se os problemas de SPN foram resolvidos. 6. Além disso, você pode usar os seguintes comandos: - Use SETSPN -Q spnName para localizar o SPN e suas contas correntes. - Use SETSPN -D para remover o SPN da conta incorreta.
   O TCP deve ser habilitado para usar a configuração Kerberos	Isso ocorre quando o TCP não está habilitado no computador cliente.	Para habilitar o protocolo TCP/IP para a instância SQL Server, siga estas etapas: 1. No SQL Server Configuration Manager, no painel console, expanda SQL Server Network Configuration. 2. No painel console, selecione Protocolos para <nome da instância>. 3. No painel detalhes, clique com o botão direito do mouse em TCP/IP e selecione Habilitar. 4. No painel console, selecione Serviços do SQL Server. 5. No painel detalhes, clique com o botão direito do mouse em SQL Server (<nome da instância>) e selecione Reiniciar para interromper e reiniciar o serviço do SQL Server. Para obter mais informações, consulte Habilitar ou Desabilitar um Protocolo de Rede do Servidor.
   Porta Dinâmica	Esta mensagem aparece para instâncias nomeadas que usam portas dinâmicas (configuração padrão). Em ambientes em que você precisa usar o Kerberos para se conectar ao SQL Server, defina sua instância nomeada como uma porta estática e use essa porta ao registrar o SPN.	A fim de configurar a instância do SQL Server para usar uma porta estática, siga estas etapas: 1. No SQL Server Configuration Manager, no painel console, expanda SQL Server Network Configuration, expanda Protocolos para <nome da instância> e clique duas vezes em TCP/IP. 2. Na caixa de diálogo Propriedades de TCP/IP, examine a configuração Escutar Tudo na guia Protocolo. 3. Se a configuração Escutar Tudo estiver definida como Sim, alterne para a guia Endereços IP e role até a parte inferior do Windows para localizar a configuração IPAll. Exclua o valor atual contido nas Portas Dinâmicas TCP e defina o valor desejado no campo Porta TCP. Selecione OK e reinicie a instância do SQL Server para que as configurações entrem em vigor. 4. Se a configuração Escutar Tudo estiver definida como Não, alterne para a guia Endereços IP e verifique cada um dos endereços IP que aparecem no IP1, IP2. Para endereços IP habilitados, remova o valor atual contido no campo Portas Dinâmicas TCP e defina o valor desejado no campo Porta TCP. Selecione OK e reinicie a instância do SQL Server para que as configurações entrem em vigor. Para obter mais informações, consulte Configurar um Servidor para Escutar em uma Porta TCP Específica.
   SPN duplicado	Você pode encontrar a situação quando o mesmo SPN é registrado em contas diferentes no Active Directory.	1. Selecione o botão Corrigir, exiba as informações na caixa de diálogo Aviso e selecione Sim se você puder adicionar o SPN ausente ao Active Directory. 2. Se sua conta de domínio tiver as permissões necessárias para atualizar o Active Directory, o SPN incorreto será excluído. 3. Se sua conta de domínio não tiver as permissões necessárias para atualizar o Active Directory, use o botão Gerar ou Gerar Tudo para gerar o script necessário que você pode entregar ao administrador do Active Directory para remover os SPNs duplicados. Depois que os SPNs forem removidos, execute novamente o KCM para verificar se os problemas de SPN foram resolvidos.

   Observação

   Se a conta de domínio que inicia o KCM não tiver privilégios para manipular SPNs no Active Directory, você poderá usar o botão Gerar ou Gerar Tudo correspondente na coluna Script SPN para gerar os comandos necessários e trabalhar com o administrador do Active Directory para corrigir os problemas identificados pelo KCM.

5. Depois de corrigir todos os problemas identificados no KCM, execute novamente a ferramenta. Certifique-se de que nenhum outro problema seja relatado e repita a conexão. Se a ferramenta ainda relatar problemas, repita o procedimento anterior.

Corrigir o erro sem o Kerberos Configuration Manager

Se você não puder usar o KCM, siga estas etapas:

Etapa 1: Verificar a resolução de nomes com o comando ping

O fator-chave que torna a autenticação Kerberos bem-sucedida é a funcionalidade DNS válida na rede. Você pode verificar essa funcionalidade no cliente e no servidor usando o utilitário do prompt de comando Ping. No computador cliente, execute o seguinte comando para obter o endereço IP do servidor que está executando o SQL Server (onde o nome do computador é SQLServer1):

ping sqlserver1

Para ver se o utilitário Ping resolve o DNS totalmente qualificado de SQLServer1, execute o seguinte comando:

ping -a <IPAddress>

Por exemplo:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

Quando o comando ping -a <IPAddress> é resolvido para o DNS totalmente qualificado correto do computador que está executando SQL Server, a resolução do lado do cliente também é bem-sucedida.

Para obter diagnóstico detalhado, use o cmdlet Test-NetConnection ou Test-Connection para testar a conectividade TCP de acordo com a versão do PowerShell instalada no computador. Para obter mais informações sobre o cmdlet do PowerShell, consulte Visão Geral do Cmdlet.

Verifique se existem aliases para o SQL Server no SQL Server Configuration Manager e no utilitário SQL Server Client Network. Se esse alias existir, verifique se ele está configurado corretamente verificando nomes de servidor, protocolo de rede, número da porta e assim por diante. Um alias do SQL Server pode fazer com que um SPN inesperado seja gerado. Isso resultará em credenciais NTLM se o SPN não for encontrado ou uma falha de SSPI, se corresponder inadvertidamente ao SPN de outro servidor.

Etapa 2: Verificar a comunicação entre domínios

Verifique se o domínio no qual você entra pode se comunicar com o domínio do servidor que está executando o SQL Server. Também deve haver resolução de nomes correta no domínio.

1. Verifique se você pode entrar no Windows usando a mesma conta de domínio e senha que a conta de inicialização do serviço do SQL Server. Por exemplo, o erro de SSPI pode ocorrer em uma das seguintes situações:

   • A conta de domínio está bloqueada.
   • Você não reiniciou o serviço do SQL Server depois que a senha da conta foi alterada.

2. Se o domínio de logon for diferente do domínio do servidor que está executando o SQL Server, verifique a relação de confiança entre os domínios.

3. Verifique se o domínio ao qual o servidor pertence e a conta de domínio que você usa para se conectar estão na mesma floresta. Essa etapa é necessária para que o SSPI funcione.

Etapa 3: verificar SQL Server SPNs usando ferramentas SQLCHECK e Setspn

Se você puder entrar localmente no computador SQL Server e ter acesso ao administrador, use SQLCHECK. O SQLCheck fornece a maioria das informações necessárias para a solução de problemas em um arquivo. Para obter mais informações sobre como usar a ferramenta e quais informações ela coleta, examine a home page da ferramenta. Você também pode verificar os pré-requisitos recomendados e a página da lista de verificação. Depois de gerar o arquivo de saída, examine a configuração do SPN para sua instância do SQL Server na seção Informações do SQL Server do arquivo de saída.

Exemplo de saída:

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

Use a saída acima para determinar as próximas etapas (veja os exemplos abaixo) e use a ferramenta Setspn para executar as ações corretivas necessárias para corrigir problemas de SPN.

Etapa 4: Verificar a permissão de conta para a de inicialização do SQL Server no servidor vinculado

Se você usar Representar como a opção de autenticação na página Segurança do servidor vinculado, o SQL Server será necessário para passar as credenciais de entrada para o SQL Server. A conta de inicialização do SQL Server em que o servidor vinculado é definido deve ter o direito A conta é confiável para Delegação atribuída a ela no Active Directory. Para obter mais informações, consulte Habilitar contas de computador e de usuário para serem confiáveis para delegação.

Confira também

• Solucionar problemas de conectividade no SQL Server
• Solucionar problemas de autenticação consistentes
• Ferramenta de cliente SSPI
• Habilitar o log de eventos Kerberos
• Como forçar o Kerberos a usar o TCP em vez do UDP no Windows