Sobre como resolver a mensagem de erro "Não é possível gerar contexto SSPI"

Traduções de Artigos Traduções de Artigos
Artigo: 811889 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Compreender o problema

Reduzir esta imagemExpandir esta imagem
assets folding start collapsed
Esta secção dá-lhe informações gerais sobre o porque da mensagem de erro "Não é Possível Gerar Contexto SSPI" ocorrer e sobre como resolver o erro. Poderá receber esta mensagem de erro caso se verifiquem as seguintes condições:
  • Está a ligar ao Microsoft SQL Server.
  • Está a utilizar a Segurança Integrada.
  • A autenticação do Kerberos é utilizada para realizar a delegação de segurança.
Compreender a terminologia Kerberos e o Nome Principal de Serviço
O controlador de SQL Server num computador cliente utiliza a segurança integrada para utilizar o token de segurança Windows da conta de utilizador para ligar corretamente para um computador que está a executar o SQL Server. O token de segurança do Windows é delegado do cliente para o computador que está a executar o SQL Server. O controlador de SQL Server efetua esta delegação quando o token de segurança do utilizador é delegado de um computador para outro, através de uma das seguintes configurações:
  • NTLM por Pipes Nomeados (sem utilização da Interface do Fornecedor de Suporte de Segurança [SSPI])
  • NTLM por sockets TCP/IP com SSPI
  • Autenticação Kerberos por sockets TCP/IP com SSPI
A Interface do Fornecedor de Suporte de Segurança (SSPI) é um conjunto de APIs do Windows que permite a delegação e autenticação mútua em qualquer camada de transporte de dados genéricos, tais como sockets TCP/IP. Por conseguinte, o SSPI permite que um computador com o sistema operativo Windows delegue com segurança um token de segurança de utilizador de um computador para outro por qualquer camada de transporte que possa transmitir bytes de dados não processados.

O erro "Não é possível gerar contexto SSPI" é criado quando o SSPI utiliza a autenticação Kerberos para delegar por TCP/IP e não consegue concluir as operações necessárias para delegar corretamente o token de segurança do utilizador para o computador de destino que está a executar o SQL Server.
Porque é que a Interface de Fornecedor de Suporte de Segurança utiliza a autenticação Kerberos ou NTLM
A autenticação Kerberos utiliza um identificador nomeado "Nome Principal do Serviço" (SPN). Considere um SPN como domínio ou identificador único de floresta de alguma instância num recurso de servidor. Pode ter um SPN para um serviço Web, para um serviço SQL ou para um serviço SMTP. Também pode ter múltiplas instâncias de serviços Web no mesmo computador físico que tem um SPN único.

Um SPN para o SQL Server é constituído pelos seguintes elementos:
  • Classe de Serviço: Identifica a classe geral de serviço. É sempre MSSQLSvc para o SQL Server.
  • Anfitrião: O DNS nome de domínio completamente qualificado do computador que se encontra a executar o SQL Server.
  • Porta: O número da porta que o serviço está a escutar.
Em seguida apresentamos um exemplo de um SPN típico para um computador com o SQL Server em execução:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
O formato de um SPN para uma instância predefinida e o formato de um SPN para uma instância nomeada não são diferentes. O número da porta relaciona um SPN a uma instância em particular.

Quando o controlador de SQL Server num cliente utiliza a segurança integrada para ligar ao SQL Server, o código do controlador no cliente tenta resolver o DNS totalmente qualificado do computador que executa o SQL Server, utilizando os APIs de rede WinSock. Para realizar esta operação, o código do controlador chama os APIs WinSock gethostbyname e gethostbyaddr. Mesmo se um endereço de IP ou um nome de anfitrião for transmitido como o nome do computador em que o SQL Server está a ser executado, o controlador de SQL Server tenta resolver o DNS totalmente qualificado do computador, se o computador utilizar segurança integrada.

Quando o controlador de SQL Server no cliente resolve o DNS completamente qualificado do computador que executa o SQL Server, o DNS correspondente é utilizado para formar o SPN para este computador. Portanto, quaisquer problemas sobre a forma como o endereço de IP ou o nome de anfitrião está resolvido para o DNS completamente qualificado por WinSock, poderá levar o controlador de SQL Server a criar um SPN inválido para o computador que está a executar o SQL Server.

Em seguida apresentamos um exemplo de SPNs inválidos que o controlador de SQL Server do lado do cliente pode formar como DNS completamente qualificado e resolvido:
  • 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 controlador SQL Server forma um SPN inválido, a autenticação continuará a funcionar uma vez que a interface SSPI tenta procurar o SPN no serviço de diretório Active Directory, e não encontra o SPN. Se a interface SSPI não encontrar encontrar o SPN, a autenticação Kerberos não é realizada. Nessa altura, a camada SSPI alterna para o modo de autenticação NTLM e o início de sessão utiliza a autenticação NTLM e normalmente é bem sucedida. Se o controlador de SQL Server forma um SPN válido, mas que não está associado ao contentor adequado, este tenta utilizar o SPN mas não pode. Isto causa uma mensagem de erro "Não é Possível Gerar Contexto SSPI". Se a conta de início do SQL Server for uma conta de sistema local, o contentor adequado é o nome do computador. Em qualquer conta, o contentor adequado é a conta de início do SQL Server. Uma vez que a autenticação tentará utilizar o primeiro SPN que encontrar, certifique-se de que não existem SPNs associados a contentores inadequados. Resumindo, cada SPN deve ser associado a um único contentor.

O principal fator que possibilita a autenticação Kerberos é a validade da funcionalidade DNS na rede. Pode verificar esta funcionalidade no cliente e servidor, através do utilitário de linha de comandos Ping. No computador cliente, execute o seguinte comando para obter o endereço IP do servidor que está a executar o SQL Server (em que o nome do computador que está a executar o SQL Server é SQLServer1):
ping sqlserver1
Para confirmar se o utilitário Ping resolve o DNS completamente qualificado do SQLServer1, execute o seguinte comando:
ping -a IPAddress
Por exemplo:
C:\>ping SQLSERVER1

A efetuar o ping de SQLSERVER1 [123.123.123.123] com 32 bytes de dados:
	
Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128
	
Estatísticas de Ping para 123.123.123.123: Pacotes: Enviado = 4, Recebido = 4, Perdido = 0 (0% perdido), Tempo aproximado de ida e volta em milissegundos: Mínimo = 0ms, Máximo =  0ms, Média =  0ms
C:\>ping -a 123.123.123.123
	
A efetuar o ping de SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] com 32 bytes de dados:
	
Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128 Resposta de 123.123.123.123: bytes=32 tempo<10ms TTL=128 Estatísticas de Ping para 123.123.123.123: Pacotes: Enviado = 4, Recebido = 4, Perdido = 0 (0% perdido), Tempo aproximado de ida e volta em milissegundos: Mínimo = 0ms, Máximo =  0ms, Média =  0ms

C:\>
Quando o comando ping -a IPAddress resolve para o DNS correto completamente qualificado do computador que executa o SQL Server, a resolução do lado do cliente é executada com êxito.
Criação do Nome Principal do Serviço do SQL Server
Trata-se de uma das partes importantes da interação do Kerberos e do SQL Server. Com o SQL Server, pode executar o serviço SQL Server devido a uma das seguintes circunstâncias: uma conta de LocalSystem, uma conta de utilizador local ou uma conta de utilizador de domínio. Quando a instância do serviço SQL Server iniciar, tentará registar o seu próprio SPN no Active Directory, utilizando a chamada API DsWriteAccountSpn. Se a chamada não for bem sucedida, o seguinte aviso é registado no Visualizador de Eventos:

Origem: ID do Evento MSSQLServer: Descrição 19011: Informações SuperSocket: (SpnRegister): Erro 8344.

Para mais informações sobre a função DsWriteAccountSpn, consulte o seguinte Web site da Microsoft:
http://msdn.microsoft.com/pt-pt/library/ms676056.aspx
Explicação simplificada
Se executar o serviço SQL Server na conta LocalSystem, o SPN é automaticamente registado e o Kerberos interage corretamente com o computador que está a executar o SQL Server. No entanto, se executar o serviço SQL Server numa conta de domínio ou numa conta local, a tentativa de criar o SPN falhará na maior parte dos casos uma vez que a conta de domínio e a conta local não podem ter os seus próprios SPNs. Quando a criação de SPN não for concluída com êxito, isto significa que o SPN é configurado para o computador que executa o SQL Server. Se testar utilizando uma conta de administrador de domínio como a conta de serviço do SQL Server, o SPN é criado com êxito, uma vez que as credenciais do nível de administrador de domínio que tem de possuir para criar um SPN estão presentes.

Dado que poderá não utilizar uma conta de administrador de domínio para executar o serviço de SQL Server (para evitar riscos de segurança), o computador que está a executar o SQL Server não pode criar o seu próprio SPN. Por conseguinte, necessita de criar manualmente um SPN para o computador que está a executar o SQL Server, se pretende utilizar a autenticação Kerberos ao ligar a um computador que está a executar o SQL Server. Isto verifica-se se estiver a executar o SQL Server numa conta de utilizador de domínio ou numa conta de utilizador local. O SPN que cria tem de estar associado à conta de serviço do serviço SQL Server nesse computador em específico. O SPN não pode ser associado ao contentor de computador a não ser que o computador que se encontra a executar o SQL Server inicie com a conta de sistema local. Apenas pode haver um SPN, que tem de ser associado ao contentor adequado. Normalmente, esta é a conta de serviço do SQL Server atual, mas esta é o contentor da conta do computador com a conta de sistema local.
Reduzir esta imagemExpandir esta imagem
assets folding end collapsed

Resolver este problema

Reduzir esta imagemExpandir esta imagem
assets folding start collapsed
Esta secção mostra quais os passos para o ajudar a garantir que o seu computador não sofre nenhuns problemas SSPI.

Verificar o domínio
Verificar que o domínio no qual inicia sessão consegue comunicar com o domínio ao qual o computador que está a executar o Servidor SQL pertence. Também é necessário que exista uma resolução de nomes adequada no domínio.
  1. Certifique-se de que consegue iniciar sessão corretamente no Windows, utilizando a mesma conta de domínio e palavra-passe, como conta de início do serviço do SQL Server. Por exemplo, o erro de SSPI pode ocorrer numa das seguintes situações:
    • A conta de domínio está bloqueada.
    • A palavra-passe da conta foi alterada. No entanto, nunca reinicia o serviço SQL Server após a alteração da palavra-passe.
  2. Se o seu domínio de palavra-passe é diferente do domínio do computador que está a executar o SQL Server, verifique a relação de fidedignidade entre os domínios.
  3. Verifique se o domínio ao qual pertence o servidor e se a conta de domínio que utiliza para ligar estão na mesma floresta. Isto é necessário para que o SSPI funcione.
  4. Utilize a opção A conta é Fidedigna para Delegação em Utilizadores e Computadores do Active Directory ao iniciar ao SQL Server.

    Nota O direito de "A conta é Fidedigna para Delegação" é necessário apenas quando estiver a delegar credenciais a partir do servidor SQL para um servidor SQL remoto, tal como num cenário de salto duplo, como consultas distribuídas (consultas de servidor ligado) que utiliza a autenticação do Windows.
  5. Utilize o utilitário Manipular Principais do Serviço para Contas (SetSPN.exe) no Kit de Recursos 2000 do Windows. As contas do administrador de domínio do Windows 2000 ou contas de administrador do domínio Windows Server 2003 podem utilizar o utilitário para controlar o SPN associado a um serviço e a uma conta. Para o SQL Server, só deve existir um SPN. O SPN tem de ser associado ao próprio conteúdo, a conta de serviço do SQL Server atual em grande parte dos casos e a conta do computador quando o SQL Server inicia com a conta do sistema local. Se iniciar o SQL Server enquanto tiver sessão iniciada na conta LocalSystem, o SPN é configurado automaticamente. No entanto, se utilizar uma conta de domínio para iniciar o SQL Server, ou quando alterar a conta utilizada para iniciar o SQL Server, necessita de executar o SetSPN.exe para SPNs expirados e, em seguida, necessita de adicionar um SPN válido. Para obter mais informações, consulte o tópico "Delegação da Conta de Segurança" nos Livros Online do SQL Server 2000. Para tal, consulte o seguinte Web site da Microsoft:
    http://msdn.microsoft.com/pt-pt/library/aa905162(SQL.80).aspx
    Para mais informações sobre os Resource Kits dos Windows 2000, consulte o seguinte Web site da Microsoft:
    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true
  6. Verifique se a resolução do nome está a ocorrer corretamente. Os métodos de resolução de nome podem incluir ficheiros DNS, WINS, Hosts e Lmhosts. Para obter mais informações sobre os problemas de resolução de nome e resolução de problemas, clique no seguinte número de artigo para aceder ao artigo na Base de dados de Conhecimento Microsoft.
    169790 Como resolver problemas básicos de TCP/IP
  7. Para mais informações sobre como resolver problemas de acessibilidade e firewall com o Active Directory, clique nos seguintes números de artigo para ver os artigos na Base de Dados de Conhecimento Microsoft:
    291382 Perguntas mais frequentes sobre o DNS do Windows 2000 e do Windows Server 2003 DNS
    224196 Restrição do tráfego de replicação do Active Directory e tráfego de RPC cliente para uma porta específica
Configurar o serviço SQL Server para criar SPNs dinamicamente para as instâncias do SQL Server
Para configurar o serviço SQL Server para criar SPNs dinamicamente, necessita de alterar as definições de controlo de acesso da conta no serviço de diretório Active Directory. Tem de conceder a permissão "Read servicePrincipalName" e a permissão "Write servicePrincipalName" para a conta de serviço SQL Server.

Aviso Se utilizar as Interfaces de Serviço do Active Directory (ADSI) Editar snap-in, o utilitário LDP, ou qualquer outro cliente LDAP versão 3 e alterar de forma incorreta os atributos de objetos do Active Directory, poderá provocar sérios problemas. Estes problemas poderão força-lo a reinstalar o Microsoft Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, ou tanto o Windows como o Exchange. Não podemos garantir que os problemas resultantes da alteração incorreta dos atributos de objetos do Active Directory possam ser resolvidos. Altere estes atributos por sua conta e risco.

Nota Para garantir as permissões adequadas e direitos de utilizador para a conta de início do SQL Server, necessita de ter iniciado sessão como administrador de domínio, ou necessita de solicitar ao seu administrador de domínio a realização desta tarefa.

Para configurar o teclado serviço SQL Server para criar SPNs dinamicamente, siga estes passos:
  1. Clique em Iniciar, clique em Executar, escreva Adsiedit.msce, em seguida, clique em OK.
  2. No snap-in Editar ADSI , expanda o Domínio [DomainName], expanda DC= RootDomainName, expanda CN=Users, clique com o botão direito em CN= AccountName e, em seguida clique em Propriedades.

    Notas
    • DomainName é um marcador de posição para o nome do domínio.
    • RootDomainName é um marcador de posição para o domínio de raiz.
    • AccountName é um marcador de posição para a conta que especifica para iniciar o serviço SQL Server.
    • Se especifica a conta do Sistema Local para iniciar o serviço SQL Server, AccountName é um marcador de posição para a conta que utiliza para iniciar sessão no Microsoft Windows.
    • Se especificar uma conta de utilizador do domínio para iniciar o serviço SQL Server, AccountName é um marcador de posição para a conta de utilizador de domínio.
  3. Na caixa de diálogo CN= AccountName Propriedades, clique no separador Segurança.
  4. No separador Segurança, clique em Avançado.
  5. Na caixa de diálogo Definições Avançadas de Segurança, certifique-se de que SELF está listado nas Entradas de permissões.

    Se SELF não estiver listado, clique em Adicionar e adicione SELF.
  6. Em Entradas de permissões, clique em SELF e, em seguida, clique em Editar.
  7. Na caixa de diálogo Entrada de permissões, clique no separador Propriedades.
  8. No separador Propriedades, clique em Apenas este objeto na lista Aplicar em e, em seguida, certifique-se de que as caixas de verificação das seguintes permissões estão selecionadas em Permissões:
    • Ler servicePrincipalName
    • Escrever servicePrincipalName
  9. Clique em OK três vezes e, em seguida, saia do snap-in Editar ADSI.
Para obter ajuda deste processo, contacte o suporte de produto Active Directory e mencione este artigo da Base de Dados de Conhecimento Microsoft.

Importante Recomendamos que não conceda direito de EscritadeNomedoPrincipaldoServiço à conta de serviço de SQL quando se verificarem as seguintes condições:
  • Existem múltiplos controladores de domínio.
  • O SQL Server está em cluster.
Neste cenário, o SPN para o SQL Server pode ser eliminado dada a latência da replicação do Active Directory. Isto pode provocar problemas de conectividade à instância do SQL Server.

Assuma que possui o seguinte:
  • Uma instância virtual de SQL denominada Sqlcluster com dois nós: Nó A e Nó B.
  • O Nó A é autenticado pelo controlador de domínio A e o Nó B é autenticado pelo controlador de domínio B.


Pode ocorrer o seguinte:
  1. A instância Sqlcluster está ativa no Nó A e registada no SQL SPN no domínio do controlador A durante o arranque.
  2. A instância Sqlcluster falha no Nó B quando o Nó A é encerrado normalmente.
  3. A instância Sqlcluster anulou o seu SPN do controlador de domínio A durante o processo de encerramento no Nó A.
  4. O SPN é removido do controlador de domínio A mas a alteração ainda não foi replicada no controlador de domínio B.
  5. Ao arrancar o Nó B a instância Sqlcluster tenta registar o SQL SPN com o controlador de domínio B. Visto que o SPN ainda existe e o Nó B não regista o SPN.
  6. Após algum tempo, o controlador de domínio A replica a eliminação do SPN (a partir do passo 3) para o controlador de domínio B como parte da replicação do Active Directory. Como resultado final não existe nenhum SPN válido para a instância SQL no domínio e, logo, vê problemas de ligação à instância Sqlcluster.

Nota Este problema está resolvido no SQL Server 2012.
Verifique o ambiente do servidor
Verifique algumas definições básicas no computador em que o SQL Server está instalado.
  1. A autenticação Kerberos não é suportada em computadores com o Windows 2000 que estão a executar o Windows Clustering, a não ser que tenha instalado o Service Pack 3 (ou posterior) no Windows 2000. Assim sendo, qualquer tentativa de utilização da autenticação SSPI numa instância em cluster do SQL Server poderá falhar. Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft:
    235529 Autenticação Kerberos em clusters de servidores baseados no Windows 2000
  2. Verifique se o servidor está a executar o Windows 2000 Service Pack 1 (SP1). Para obter mais informações sobre a autenticação Kerberos em servidores baseados no Windows 2000, clique no número de artigo que se segue para visualizar o artigo na Base de Dados de Conhecimento Microsoft:
    267588 A mensagem de erro "Não é possível gerar contexto SSPI" é apresentada ao ligar ao SQL Server 2000
  3. Num cluster, se a conta que utiliza para iniciar o SQL Server, SQL Server Agent, ou serviços de procura de texto completo, como nova palavra-passe, siga os passos proporcionados no seguinte artigo da Base de Dados de Conhecimento Microsoft:
    239885 Como alterar as contas de serviço para um computador em cluster a executar o SQL Server
  4. Verifique que a conta que utiliza para iniciar o SQL Server tem as permissões adequadas. Se estiver a utilizar uma conta que não pertence ao grupo de Administradores Locais, consulte o tópico "Configurar Contas de Serviços do Windows" em SQL Server Books Online para uma lista detalhada das permissões que esta conta deve ter:
    http://msdn.microsoft.com/pt-pt/library/aa176564(SQL.80).aspx
Verifique o ambiente do cliente
Verifique o seguinte no cliente:
  1. Certifique-se de que o Fornecedor de Suporte de Segurança NTLM está instalado corretamente e ativado no cliente. Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft:
    269541 Mensagem de erro ao ligar para o SQL Server se a chave do registo do Fornecedor de Suporte de Segurança NTLM do Windows estiver ausente: "não é possível gerar contexto SSPI"
  2. Determine se está a utilizar credenciais em cache. Se tiver sessão iniciada no cliente com credenciais em cache, termine a sessão no computador e, em seguida, inicie sessão quando conseguir ligar para um controlador de domínio para evitar que as credenciais em cache sejam utilizadas. Para mais informações sobre como determinar se está a utilizar credenciais em cache, clique no número de artigo que segue para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
    242536 O utilizador não é alertado ao iniciar sessão com credenciais em cache de domínio
  3. Verifique se as datas no cliente e servidor são válidas. Se as datas estiverem demasiado afastadas, é possível que os certificados sejam considerados inválidos.
  4. O SSPI utiliza um ficheiro denominado Security.dll. Se qualquer outra aplicação instalar um ficheiro que utiliza este nome, o outro ficheiro pode ser utilizado, em vez do ficheiro SSPI atual. Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft:
    253577 Erro: 80004005 - MS ODBC O controlador do SQL Server não consegue inicializar o pacote SSPI
  5. Se o sistema operativo do cliente for o Microsoft Windows 98, necessita de instalar o Cliente para componentes das redes Microsoft no cliente. Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft:
    267550 ERRO: "Falha de asserção" ao ligar a um SQL Server através de TCP/IP
Verifique o utilitário de rede do cliente
O Utilitário de Rede do Cliente (CNU) é apresentado juntamente com o Microsoft Data Access Components (MDAC) e é utilizado para configurar a conectividade a computadores que estão a executar o SQL Server. Pode utilizar o utilitário MDAC Cliconfg.exe CNU para configurar a conectividade:
  1. No separador Geral a forma como os protocolos são definidos variam de acordo com a versão do MDAC. Com versões anteriores do MDAC, pode selecionar um protocolo "predefinido". Nas versões anteriores do MDAC, pode permitir um ou mais protocolos, com um no topo da lista ao ligar para o SQL Server. Uma vez que o SSPI se aplica apenas a TCP/IP, pode utilizar um protocolo diferente, tal como Pipes Nomeados, para evitar o erro.
  2. Verifique o separador Alias no CNU para confirmar se um alias foi definido para o servidor ao qual pretende ligar. Se um alias do servidor estiver definido, verifique as definições para saber como está configurada a ligação deste computador ao SQL Server. Pode verificar isto, eliminando o servidor alias para ver se o comportamento é alterado.
  3. Se o servidor alias não estiver definido no CNU, adicione o alias ao servidor ao qual está a ligar. Ao executar esta tarefa, também está explicitamente a definir o protocolo e a definir opcionalmente o endereço IP e a porta.
Configurar manualmente um Nome do Principal do Serviço para o SQL Server
Para obter mais informações sobre como configurar manualmente um Nome do Principal do Serviço para o SQL Server, clique no número de artigo que se segue para visualizar o artigo na Base de Dados de Conhecimento Microsoft:
319723 Como utilizar a autenticação Kerberos no SQL Server
A Interface do Fornecedor de Suporte de Segurança (SSPI) é a interface para a segurança do Microsoft Windows NT utilizada para a autenticação Kerberos, e suporta o esquema de autenticação do Fornecedor de Suporte de Segurança NTLM. A autenticação ocorre no nível de sistema operativo quando inicia sessão num domínio Windows. A autenticação Kerberos apenas está disponível em computadores baseados no Windows 2000 que têm a autenticação Kerberos ativada e que estão a utilizar o Active Directory.

O SSPI apenas é utilizado para ligações TCP/IP que são realizadas através da Autenticação Windows. O Windows Authentication também é conhecido como Ligações Fidedignas ou Segurança Integrada. O SSPI não utilizado para Pipes Nomeados ou ligações multiprotocolo. Assim sendo, pode evitar o problema, configurando os clientes para que liguem de um protocolo diferente de TCP/IP.

Quando o cliente SQL Server tenta utilizar segurança integrada através de sockets TCP/IP para um computador remoto que está a executar o SQL Server, a biblioteca de rede cliente SQL Server utiliza o SSPI API para realizar a delegação de segurança. O cliente de rede SQL Server (Dbnetlib.dll) faz uma chamada para a função AcquireCredentialsHandle e transmite "negociar" para o parâmetro pszPackage. Isto notifica o fornecedor de segurança adjacente para efetuar delegação de negociação. Neste contexto, a negociação significa que tentar o Kerberos ou autenticação a NTLM em computadores baseados no Windows. Por outras palavras, o Windows utiliza a delegação Kerberos se o computador de destino que está a executar o SQL Server tem um SPN associado, configurado corretamente. Caso contrário, o Windows utiliza a delegação NTLM.

Nota Verifique se não está a utilizar uma conta nomeada "SYSTEM" para iniciar qualquer tipo dos serviços SQL Server (MSSQLServer, SQLServerAgent, MSSearch). A palavra-passe SYSTEM pode causar conflitos com o Centro de Distribuição de Chaves (KDC).
Reduzir esta imagemExpandir esta imagem
assets folding end collapsed

Recolha informações para abrir um caso de Suporte ao Cliente da Microsoft (CSS)

Reduzir esta imagemExpandir esta imagem
assets folding start collapsed
Se não conseguir obter a causa do problema utilizando os passos de resolução de problemas neste artigo recolha as seguintes informações e abra um caso de Suporte ao Cliente da Microsoft (CSS).

Para obter uma lista completa dos números de telefone do Suporte ao Cliente da Microsoft, bem como informações sobre os custos de suporte, consulte o seguinte Web site da Microsoft:
http://support.microsoft.com/contactus/?ln=pt&ws=support#tab0
  1. Gerar um relatório sqldiag do SQL Server. Para obter mais informações, consulte os seguintes tópicos "Utilitário sqldiag" no SQL Server Books Online:
  2. Execute a captura de ecrã do erro no cliente.
  3. Abra uma linha de comando no nó que não liga ao SQL Server e, em seguida, escreva o seguinte comando:
    net start > started.txt
    Este comando gera um ficheiro nomeado Started.txt no diretório em que executa o comando.
  4. Guarde os valores para a chave do registo na seguinte tecla de registo no computador cliente:
    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
  5. Num ambiente em cluster, descubra o valor da seguinte tecla de registo para cada nó do cluster:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  6. Num ambiente em cluster, verifique se a seguinte chave de registo existe em cada nó de servidor de cluster:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
  7. Capture os resultados se ligar ao SQL Server através de um nome Universal Naming Convention (UNC) (ou o Nome de Rede SQL num cluster) do cliente.
  8. Capture os resultados se efetuar o ping do nome do computador (ou o Nome de Rede SQL num cluster) do cliente.
  9. Guarde o nome das contas do utilizador que utiliza para iniciar cada um dos serviços SQL Server (MSSQLServer, SQLServerAgent, MSSearch).
  10. Os profissionais de suporte necessitam de saber se o SQL Server está configurado para Autenticação Misturada ou Apenas Autenticação do Windows.
  11. Verifique se consegue efetuar ligação ao computador que está a executar o SQL Server a partir do mesmo cliente que utiliza a Autenticação do SQL Server.
  12. Verifique se consegue estabelecer ligação através do protocolo Pipes Nomeados.

Referências

Para mais informações como funciona a autenticação do Kerberos e segurança SSPI, clique nos números de artigo que se seguem para visualizar os artigos na Base de Dados de Conhecimento Microsoft:
266080 Respostas às perguntas mais frequentes sobre a autenticação Kerberos
231789 Processo de início de sessão local para Windows 2000
304161 A autenticação mútua SSPI está 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 com Kerberos no Windows 2000
262177 Como ativar o registo de eventos Kerberos
277658 O Setspn falha se o nome de domínio diferir do nome NetBIOS em que o SQL Server SPN está registado
244474 Como forçar o Kerberos a utilizar TCP em vez de UDP no Windows Server 2003, no Windows XP e no Windows 2000
Para ver um papel branco sobre a segurança do Microsoft SQL Server 2000, consulte o seguinte Web site da Microsoft:
http://technet.microsoft.com/pt-pt/cc984178.aspx
Reduzir esta imagemExpandir esta imagem
assets folding end collapsed

Propriedades

Artigo: 811889 - Última revisão: 27 de junho de 2014 - Revisão: 4.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL 2005 Server Workgroup
  • 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
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Enterprise Evaluation
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Datacenter
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Express
  • Microsoft SQL Server 2008 R2 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Integration Services
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Standard Edition for Small Business
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2008 Reporting Services
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 Standard Edition for Small Business
  • Microsoft SQL Server 2008 Web
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • SQL Server 2012 Enterprise Core
Palavras-chave: 
kbsqlsetup kbhowtomaster kbhowto kbsmbportal 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