Como solucionar a mensagem de erro "Não é possível gerar contexto SSPI"

Traduções deste artigo Traduções deste artigo
ID do artigo: 811889 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Este artigo descreve detalhadamente como solucionar as origens mais comuns da mensagem de erro "Não é possível gerar contexto SSPI". Você pode receber esta mensagem de erro sob as seguintes condições:
  • Você está se conectando ao SQL Server.
  • Você está usando segurança integrada.
  • Kerberos é usado para realizar a delegação de segurança.

Entendendo a terminologia Kerberos e o nome de princípio de serviço

O driver do SQL Server em um computador cliente usa segurança integrada para usar o símbolo de segurança do Windows da conta de usuário para se conectar com êxito a um computador que está executando SQL Server. O símbolo de segurança do Windows é delegado a partir do cliente para o computador que está executando SQL Server. O driver do SQL Server realiza esta delegação quando o símbolo de segurança do usuário é delegado a partir de um computador para outro usando as seguintes configurações:
  • NTLM sobre pipes nomeados (sem usar a interface do provedor de suporte de segurança [SSPI])
  • NTLM sobre soquetes TCP/IP com SSPI
  • Kerberos sobre soquetes TCP/IP com SSPI
A Interface do provedor de suporte de segurança (SSPI) é um conjunto de APIs do Windows que permite a delegação e autenticação mútua sobre qualquer camada de transporte de dados genéricos, como soquetes TCP/IP. Por isso, o SSPI permite que um computador executando um sistema operacional do Windows delegue com segurança um símbolo de segurança do usuário a partir de um computador para outro sobre qualquer camada de transporte que possa transmitir bytes de dados não-processados.

A mensagem de erro "Não é possível gerar contexto SSPI" é gerada quando o SSPI usa Kerberos para delegar sobre TCP/IP e o Kerberos não pode concluir as operações necessárias para delegar com êxito o símbolo de segurança do usuário para o computador de destino que está executando o SQL Server.

Porque a interface do provedor de suporte de segurança escolhe NTLM ou Kerberos

Kerberos usa um identificador chamado "Nome de princípio de serviço" (SPN). Considere um SPN com um identificador de domínio ou floresta exclusivo de alguma instância em um recurso de servidor de rede. É possível ter um SPN para um serviço da Web, para um serviço SQL ou para um serviço SMTP. Você também pode ter diversas instâncias de serviço da Web no mesmo computador que possui um SPN exclusivo.

Um SPN para SQL Server é composto dos seguintes elementos:
  • ServiceClass (Classe do serviço): Isso identifica a classe geral do serviço. Isso é sempre MSSQLSvc para SQL Server.
  • Host: Este é o nome de domínio DNS totalmente qualificado do computador executando SQL Server.
  • Port (Porta): Este é o número da porta na qual o serviço está escutando.
Por exemplo, um SPN típico para um computador executando o SQL Server é:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Os formatos de um SPN para uma instância padrão e para uma instância nomeada não são diferentes. O número da porta é o que amarra o SPN a uma instância particular.

Quando o driver SQL Server em um cliente usar a segurança integrada para se conectar ao SQL Server, o código do driver no cliente tenta resolver o DNS completamente qualificado do computador, que está executando o SQL Server, usando as APIs de rede WinSock. Para realizar esta operação, o código do driver chama as APIs WinSock gethostbyname e gethostbyaddr. Mesmo se um endereço IP ou nome de host for passado como o nome do computador executando SQL Server, o driver do SQL Server tenta resolver o DNS totalmente qualificado do computador se este estiver usando segurança integrada.

Quando o driver do SQL Server no cliente resolve o DNS totalmente qualificado do computador executando SQL Server, o DNS correspondente é usado para formar o SPN para este computador. Por isso, quaisquer problemas relacionados à maneira que o endereço IP ou nome do host é resolvido para o DNS totalmente qualificado pelo WinSock podem fazer com que o driver do SQL Server crie um SPN inválido para o computador que está executando SQL Server.

Por exemplo, os SPNs inválidos que o driver do SQL Server do lado do cliente pode formar como DNS totalmente qualificado são:
  • 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 procura o SPN no serviço de diretório do Active Directory e não o encontra. Se a interface SSPI não encontrar o SPN, a autenticação Kerberos não será realizada. Neste ponto, a camada do SSPI alterna para um modo de autenticação NTLM e o logon usa autenticação NTLM e geralmente tem êxito. Se o driver do SQL Server forma um SPN válido, mas não atribuído ao recipiente apropriado, ele tenta usar o SPN mas não pode, causando uma mensagem de erro "Não é possível gerar contexto SSPI". Se a conta de inicialização do SQL Server for uma conta de sistema local, o recipiente apropriado será o nome do computador. Para qualquer outra conta, o recipiente apropriado é a conta de inicialização do SQL Server. Como a autenticação irá tentar usar o primeiro SPN que encontrar, verifique se não existem SPNs atribuídos a recipientes inapropriados. Em outras palavras, cada SPN deve estar atribuído a apenas um recipiente.

O principal fator que causa o êxito da autenticação Kerberos é a funcionalidade DNS válida na rede. Você pode verificar esta funcionalidade no cliente e no servidor usando o utilitário de linha de comando Ping. No computador cliente, execute o seguinte comando para obter o endereço IP do servidor executando SQL Server (no qual o nome do computador que está executando o SQL Server é SQLServer1):
ping sqlserver1
Para verificar se o utilitário de linha de comando resolve o DNS totalmente qualificado do SQLServer1, execute o seguinte comando:
ping -a EndereçoIP
Por exemplo:
C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] com 32 bytes de dados:
	
Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128
	
Estatísticas Ping para 123.123.123.123: Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda), Tempo de resposta aproximado em milissegundos: Mínimo = 0ms, Máximo =  0ms, Médio =  0ms
C:\>ping -a 123.123.123.123
	
Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] com 32 bytes de dados:
	
Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 time<10ms TTL=128 Estatísticas de Ping para 123.123.123.123: Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda), Tempo de resposta aproximado em milissegundos: Mínimo = 0ms, Máximo = 0ms, Médio = 0ms

C:\>
Quando o comando ping -a EndereçoIP resolve para DNS totalmente qualificado correto do computador que está executando o SQL Server, a resolução do lado do cliente também tem êxito.

Criação do nome de princípio de serviço do SQL Server

Esta é uma das partes críticas da interação de Kerberos e SQL Server. Com o SQL Server, é possível executar o serviço SQL Server em um dos seguintes: Uma conta do sistema local, uma conta de usuário local ou uma conta de usuário do domínio. Quando a instância do serviço do SQL Server inicia, ele tenta registrar seu próprio SPN no Active Directory usando a chamada API DsWriteAccountSpn. Se a chamada não tiver êxito, o seguinte aviso será registrado em Visualizar eventos:

Origem: MSSQLServer EventID: 19011 Descrição: SuperSocket info: (SpnRegister) : Erro 8344.

Para obter mais informações sobre a função DsWriteAccountSpn, visite o seguinte site da Microsoft (em inglês):
http://msdn2.microsoft.com/en-us/library/ms676056.aspxp

Explicação simplificada

Se executar o serviço SQL Server na conta do sistema local, o SPN será automaticamente registrado e o Kerberos irá interagir com êxito com o computador que está executando SQL Server. No entanto, se executar o serviço SQL Server em uma conta de domínio ou em uma conta local, a tentativa de criar o SPN irá falhar na maior parte dos casos, porque a conta de domínio e a conta local não possuem o direito de definir seus próprios SPNs. Quando a criação do SPN não tem êxito, significa que nenhum SPN foi definido para o computador que está executando o SQL Server. Se você testar usando uma conta de administrador de domínio como a conta de serviço do SQL Server, o SPN será criado com êxito, porque as credenciais do nível de administrador de domínio necessárias para a criação de um SPN estão presentes.

Como uma conta de administrador de domínio não deve ser usada para executar o serviço SQL Server (para impedir risco de segurança), o computador executando o SQL Server não pode criar seu próprio SPN. Por isso, é necessário criar manualmente um SPN para o seu computador executando o SQL Server se quiser usar Kerberos ao conectar-se a um computador que está executando o SQL Server. Isso é verdade se você estiver executando o SQL Server em uma conta de usuário de domínio ou em uma conta de usuário local. O SPN criado deve ser atribuído à conta de serviço do serviço do SQL Server neste computador específico. O SPN não pode ser atribuído ao recipiente do computador a menos que o computador executando o SQL Server inicie com o sistema local. Deve existir apenas um SPN e ele deve ser atribuído ao recipiente apropriado. Em geral, esta é a conta de serviço atual do SQL Server. No entanto esta é a conta do computador com sistema local.

Verificar o domínio

Verifique se o domínio no qual você se conectou pode se comunicar com o domínio do qual o computador executando SQL Server pertence. Também deve haver resolução apropriada de nome no domínio.
  1. Se o seu domínio de logon for o mesmo domínio do qual o computador que está executando SQL Server pertence, use a autenticação do Windows para fazer o logon no SQL Server. Se a autenticação falhar, haverá um problema com a conta do Windows ou conta de domínio que você deve abordar. Contate seu administrador de segurança ou de rede para verificar a conta do Windows ou a conta de domínio para obter as permissões apropriadas.
  2. Se o seu domínio de logon for diferente do domínio do computador executando SQL Server, verifique a relação de confiança entre os domínios.
  3. Verifique se o domínio do qual o servidor pertence e a conta de domínio usada para se conectar estão na mesma floresta. Isso é necessário para que o SSPI funcione.
  4. Use a opção A conta é confiável para delegação em Usuários e computadores do Active Directory ao iniciar o SQL Server.
  5. Use o utilitário Manipular nomes de princípio de serviço para contas (SetSPN.exe) no Windows 2000 Resource Kit. Contas de administrador de domínio do Windows 2000 ou contas de administrador de domínio do Windows 2003 podem usar o utilitário para controlar o SPN atribuído a um serviço e uma conta. No caso do SQL Server, deve existir apenas um SPN. O SPN deve ser atribuído ao recipiente apropriado, a conta de serviço atual do SQL Server na maior parte dos casos e a conta do computador quando o SQL Server inicia com a conta de sistema local. Se você iniciar o SQL Server enquanto estiver conectado com a conta do sistema local, o SPN é definido automaticamente. No entanto, se usar uma conta de domínio para iniciar o SQL Server, ou sempre que alterar a conta usada para iniciar o SQL Server, será necessário executar SetSPN.exe para remover SPNs que expiraram e adicionar um SPN válido. Para obter informações adicionais, consulte o tópico "Delegação de conta de segurança" nos Manuais online do SQL Server 2000. Para isso, visite o seguinte site da Microsoft (em inglês):
    http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx
    Para obter mais informações sobre os Kits de recursos do Windows 2000, visite o seguinte site da Microsoft (em inglês):
    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true
  6. Verifique se a resolução de nome está ocorrendo corretamente. Métodos de resolução de nome podem incluir arquivos DNS, WINS, HOSTS e arquivos LMHOSTS. Para obter informações adicionais sobre problemas de resolução de nomes e soluções para estes problemas, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    169790 Como solucionar problemas básicos de TCP/IP
  7. Para obter informações adicionais sobre como solucionar problemas de acessibilidade e de firewall com o Active Directory, clique nos números abaixo para ler os artigos na Base de Dados de Conhecimento Microsoft (alguns artigos podem estar em inglês):
    291382 Perguntas freqüentes sobre Windows 2000 DNS e Windows Server 2003 DNS
    224196 Restringindo tráfego de duplicação do Active Directory e tráfego do RPC cliente para uma porta específica

Como configurar o serviço do SQL Server para criar SPNs de maneira dinâmica para as instâncias do SQL Server

Para configurar o serviço do SQL Server para criar SPNs de maneira dinâmica, é necessário modificar as configurações do controle de acesso da conta no serviço do diretório do Active Directory. É necessário conceder as permissões "Read servicePrincipalName" e "Write servicePrincipalName" para a conta do serviço do SQL Server.

Aviso Se usar o snap-in Active Directory Service Interfaces (ADSI) Edit, o utilitário LDP ou qualquer outro cliente de LDAP versão 3 e modificar incorretamente os atributos dos objetos do Active Directory, isso poderá causar sérios problemas. Esses problemas podem exigir a reinstalação do Microsoft Windows Server 2003, do Microsoft Windows 2000 Server, do Microsoft Exchange Server 2003, do Microsoft Exchange 2000 Server, ou tanto do Windows quanto do Exchange. Não podemos garantir que os problemas decorrentes da modificação incorreta dos atributos de objetos do Active Directory possam ser resolvidos. A modificação destes atributos é de sua responsabilidade.

Aviso Para conceder as permissões e direitos de usuário adequados para a conta de inicialização do SQL Server, é necessário efetuar logon como administrador do domínio ou solicitar que um administrador do domínio efetue essa tarefa.

Para configurar o servidor SQL Server para criar SPNs de maneira dinâmica, execute as seguintes etapas:
  1. Clique em Iniciar, em Executar, digite Adsiedit.msc e clique em OK.
  2. No snap-in ADSI Edit, expanda Domain [Nome_do_domínio], expanda DC= NomedoDomínioRaiz, expanda CN=Users, clique com o botão direito do mouse em CN=NomedaConta e clique em Propriedades.

    Observações
    • Nome_do_domínio é um espaço reservado para o nome do domínio.
    • NomedoDomínioRaiz é um espaço reservado para o nome do domínio raiz.
    • NomedaConta representa a conta especificada para iniciar o serviço do SQL Server.
    • Se você especificou a conta do Sistema local para iniciar o serviço do SQL Server,NomedaConta representa a conta usada para efetuar logon no Microsoft Windows.
    • Se você especificou uma conta de usuário do domínio para iniciar o serviço do SQL Server,NomedaConta é um espaço reservado para o nome de usuário do domínio.
  3. No CN=NomedaConta Na caixa de diálogo Propriedades clique na guia Segurança.
  4. Na guia Segurança, clique em Avançado.
  5. Na caixa de diálogo Configurações de segurança avançada, certifique-se que SELF está relacionado na lista em Entradas de permissão.

    Se SELF não estiver listado, clique em Adicionar e adicione SELF.
  6. Em Entradas de permissão, clique em SELF e, em seguida clique em Editar.
  7. Na caixa de diálogo Entrada de permissão, clique na guia Propriedades.
  8. Na guia Propriedades, clique em Apenas este objeto na lista Aplicar em e, em seguida certifique-se de que as caixas de seleção das seguintes permissões estão marcadas em Permissões:
    • Nome Principal de serviço de Leitura
    • Nome Principal de serviço de gravação
  9. Clique três vezes em OK e feche o snap-in ADSI Edit.
Para obter ajuda neste processo, contate o suporte do produto do Active Directory e mencione este artigo da Base de Dados de Conhecimento Microsoft.

Verificar o ambiente do servidor

Verifique algumas configurações básicas no computador no qual o SQL Server está instalado:
  1. Kerberos não é compatível com computadores com o Windows 2000 executando os serviços de cluster do Windows a menos que você tenha aplicado o Service Pack 3 (ou posterior) ao Windows 2000. Por isso qualquer tentativa de usar autenticação SSPI em uma instância do SQL Server pode não ter êxito. Para obter mais informações, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    235529 Suporte para Kerberos em clusters de servidor com base no Windows 2000
  2. Verifique se o servidor está executando o Windows 2000 Service Pack 1 (SP1). Para obter informações adicionais sobre o suporte ao Kerberos em servidores com o Windows 2000, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    267588 A mensagem de erro "Não é possível gerar contexto SSPI" é exibida quando você se conecta ao SQL Server 2000
  3. Em um cluster, se a conta que você usa para iniciar SQL Server, SQL Server Agent ou serviços de pesquisa de texto completo mudar, como uma nova senha, execute as etapas fornecidas no seguinte artigo da Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    239885 Como alterar as contas de serviço em um computador agrupado que está executando SQL Server
  4. Verifique se a conta que você usa para iniciar o SQL Server possui as permissões apropriadas. Se você estiver usando uma conta que não é membro de grupo Administradores locais, consulte o tópico "Configurando as contas de serviço do Windows" nos Manuais online do SQL Server para obter uma lista detalhada de permissões que esta conta deve ter (em inglês):
    http://msdn2.microsoft.com/en-us/library/aa176564(SQL.80).aspx

Verificar o ambiente do cliente

Verifique o seguinte no cliente:
  1. Certifique-se de que o provedor de suporte de segurança NTLM está instalado e ativado corretamente no cliente. Para obter mais informações, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    269541 Mensagem de erro quando você tenta se conectar ao SQL Server se a chave de Registro do provedor de suporte de segurança LM do Windows NT está faltando: "não é possível gerar contexto SSPI"
  2. Determine se você está usando credenciais armazenadas em cache. Se você estiver conectado ao cliente com credenciais armazenadas em cache, faça logoff no computador e faça logon quando puder se conectar a um controlador de domínio para impedir o uso das credenciais armazenadas em cache. Para obter informações adicionais sobre como determinar se está usando credenciais armazenadas em cache, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    242536 O usuário não é alertado ao fazer o logon com credenciais de domínio armazenadas em cache
  3. Verifique se as datas no cliente e no servidor são válidas. Se as datas forem muito distintas, seus certificados podem ser considerados inválidos.
  4. O SSPI usa um arquivo chamado Security.dll. Se qualquer outro aplicativo instalar um arquivo com este nome, o outro arquivo poderá ser usado em vez do arquivo real do SSPI. Para obter mais informações, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    253577 Erro: 80004005 - Driver ODBC do SQL Server da MS não pode inicializar pacote SSPI
  5. Se o sistema operacional no cliente for Microsoft Windows 98, será necessário instalar o componente Cliente para redes Microsoft no cliente. Para obter mais informações, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
    267550 BUG: "Falha de declaração" ao conectar-se a um SQL Server por meio de TCP/IP

Verificar o utilitário de rede para cliente

O utilitário de rede para cliente (CNU) é fornecido junto com o Microsoft Data Access Components (MDAC) e é usado para configurar a conectividade para computadores que estão executando o SQL Server. Você pode usar o utilitário de rede para cliente Cliconfg.exe do MDAC para configurar a conectividade:
  1. Na guia Geral, a maneira que os protocolos são definidos varia de acordo com a versão do MDAC. Com versões mais antigas do MDAC, você pode selecionar um protocolo "padrão". Nas versões posteriores do MDAC, você pode habilitar um ou mais protocolos com um no topo da lista ao conectar-se ao SQL Server. Como o SSPI se aplica apenas a TCP/IP, você pode usar um protocolo diferente, como pipes nomeados, para evitar o erro.
  2. Verifique a guia Alias no CNU (utilitário de rede para cliente) para verificar se um alias foi definido para o servidor que está tentando conectar. Se um alias de servidor tiver sido definido, verifique as configurações da maneira que este computador está configurado para conectar-se ao SQL Server. Você pode verificar isso excluindo o servidor alias para verificar se o comportamento muda.
  3. Se o servidor alias não tiver sido definido no CNU, adicione o alias para o servidor com o qual está se conectando. Ao realizar esta tarefa, estará também definindo de maneira explícita o protocolo e definindo, de forma opcional, o endereço IP e a porta.

Informações a serem coletadas para abrir um caso no Atendimento Microsoft (PSS)

Se não for possível obter a causa do problema usando as etapas para solução de problema neste artigo, colete as seguintes informações e abra um caso no Atendimento Microsoft (PSS):

Para obter uma lista completa dos números de telefone do Atendimento Microsoft e informações sobre os custos de suporte, visite o seguinte site da Microsoft:
http://support.microsoft.com/contactus/?ws=support
  1. Gere um relatório sqldiag do SQL Server. Para obter informações adicionais, consulte o tópico "Utilitário sqldiag" nos Manuais online do SQL Server:
  2. Capture uma cópia da tela do erro no cliente.
  3. No nó que não pode se conectar ao SQL Server, digite o seguinte comando a partir do prompt de comando:
    net start > started.txt
    Este comando gera um arquivo chamado Started.txt no diretório no qual executou o comando.
  4. Salve os valores para a chave do Registro na seguinte chave do Registro no seu computador cliente:
    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
  5. Em um ambiente em cluster, obtenha o valor da seguinte chave do Registro para cada nó do cluster:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  6. Em um ambiente em cluster, verifique se a seguinte chave do Registro existe em cada nó do servidor de cluster:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
  7. Capture os resultados se você se conectar ao SQL Server usando um nome UNC (Universal Naming Convention) (ou o nome de rede do SQL em um cluster) a partir do cliente.
  8. Capture os resultados se você executar um ping no nome do computador (ou no nome de rede do SQL em um cluster) a partir do cliente.
  9. Salve o nome das contas de usuário usadas para iniciar cada um dos serviços do SQL Server (MSSQLServer, SQLServerAgent, MSSearch).
  10. O profissional de suporte deve saber se o SQL Server está configurado para autenticação mista ou apenas do Windows.
  11. Verifique se você pode conectar-se ao computador executando SQL Server a partir do mesmo cliente usando a autenticação do SQL Server.
  12. Verifique se você pode conectar usando o protocolo Pipes nomeados.

Como configurar manualmente um nome de princípio de serviço para SQL Server

Para obter informações adicionais sobre com configurar manualmente um Nome de princípio de serviço para o SQL Server, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
319723 Como usar a autenticação Kerberos no SQL Server


A Interface do Provedor de Suporte de Segurança (SSPI) é a interface para a segurança do Windows NT que é usada na autenticação do Kerberos e suporta o esquema de autenticação do provedor de suporte de segurança NTLM. A autenticação ocorre no nível do sistema operacional ao fazer logon em um domínio do Windows. A autenticação Kerberos está disponível apenas em computadores com o Windows 2000 que possuem Kerberos habilitado e que usam Active Directory.

SSPI é usado apenas para conexões TCP/IP feitas usando a autenticação do Windows. (A autenticação do Windows também é conhecida como conexões confiáveis ou segurança integrada). SSPI não é usado por pipes nomeados ou conexões com vários protocolos. Por isso, é possível evitar o problema configurando seus clientes para conectar a partir de um protocolo diferente de TCP/IP.

Quando um cliente SQL Server tenta usar segurança integrada sobre soquetes TCP/IP para um computador remoto executando SQL Server, a biblioteca de rede do cliente SQL Server usa a API do SSPI para realizar uma delegação de segurança. O cliente de rede do SQL Server (Dbnetlib.dll) faz uma chamada para a função AcquireCredentialsHandle e passa "negociar" para o parâmetro pszPackage. Isso notifica o provedor de segurança subjacente para realizar a delegação de negociação. Neste contexto, negociar significa tentar a autenticação Kerberos ou NTLM nos computadores com o Windows. Em outras palavras, o Windows usa delegação Kerberos se o computador de destino que executa o SQL Server possuir um SPN associado e configurado corretamente. Caso contrário, o Windows usa delegação NTLM.

Observação Verifique se você não está usando uma conta chamada "SYSTEM" para iniciar qualquer um dos serviços do SQL Server (MSSQLServer, SQLServerAgent, MSSearch). A palavra-chave SYSTEM pode causar conflitos com o Centro de distribuição de chaves (KDC).

Referências

Para obter informações adicionais sobre a segurança Kerberos e SSPI funcionam, clique nos números abaixo para ler os artigos na Base de Dados de Conhecimento Microsoft (alguns artigos podem estar em inglês):
266080 Respostas às perguntas freqüentes sobre Kerberos
231789 Processo de logon local para Windows 2000
304161 Autenticação mútua do SSPI é indicada no lado do cliente, mas não no lado do servidor
232179 Administração Kerberos no Windows 2000
230476 Descrição de erros comuns relacionados a Kerberos no Windows 2000
262177 Como habilitar o registro de evento Kerberos
277658 Setspn falha se o nome de domínio for diferente do nome do NetBIOS no qual o SPN do SQL Server está registrado
244474 Como forçar Kerberos para usar TCP no lugar de UDP no Windows Server 2003, Windows XP e no Windows 2000
326985 Como solucionar problemas relacionados ao Kerberos no IIS
Para consultar um documento sobre segurança do Microsoft SQL Server 2000, visite o seguinte site da Microsoft (em inglês):
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sp3sec00.mspx

Propriedades

ID do artigo: 811889 - Última revisão: terça-feira, 16 de julho de 2013 - Revisão: 22.1
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
Palavras-chave: 
kbsqlmanagementtools kbhowtomaster kbhowto KB811889

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com