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


Nota: O Kerberos Configuration Manager é uma ferramenta de diagnóstico que ajuda a resolver problemas associados ao Kerberos na conectividade com o SQL Server. Estes problemas podem desencadear erros, tais como "Não pode gerar contexto SSPI". Esta ferramenta está agora disponível e pode ser transferida a partir da seguinte localização:

http://www.microsoft.com/downloads/pt-pt/details.aspx

Para mais informações, consulte os seguintes artigos da Base de Dados de Conhecimento Microsoft:

Nova ferramenta: "O Microsoft Kerberos Configuration Manager para SQL Server" está pronto para resolver os seus problemas de Kerberos/Conectividade

Está disponível o Kerberos Configuration Manager para SQL Server

 

Esta secção fornece as informações de fundo sobre o motivo pelo qual ocorre a mensagem de erro "não pode gerar contexto SSPI" e como resolver o erro. Pode receber esta mensagem de erro caso se verifiquem as condições seguintes:

  • Está a estabelecer ligação ao Microsoft SQL Server.

  • Está a utilizar a Segurança Integrada.

  • A autenticação Kerberos é utilizada para efetuar a delegação de segurança.

Noções sobre terminologia e Nome Principal do Serviço Kerberos O controlador SQL Server num computador cliente utiliza segurança integrada para utilizar o token de segurança do Windows da conta de utilizador para ligar com êxito a um computador com 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 TCP/IP sockets com SSPI

A Interface do Fornecedor de Suporte de Segurança (SSPI) é um conjunto de APIs do Windows que permite delegação e autenticação mútua através de qualquer camada de transporte de dados genérica, como sockets TCP/IP. Assim, o SSPI permite que um computador com o sistema operativo Windows delegue de forma segura um token de segurança de utilizador de um computador para outro em qualquer camada de transporte que possa transmitir bytes de dados em formato raw.

O erro "Não pode gerar contexto SSPI" é gerado quando o SSPI utiliza a autenticação Kerberos para delegar através de TCP/IP e a autenticação Kerberos não consegue concluir as operações necessárias para delegar com êxito o token de segurança de utilizador ao computador de destino que está a executar o SQL Server.

Porque a Interface do Fornecedor de Suporte de Segurança utiliza a autenticação NTLM ou Kerberos A autenticação Kerberos utiliza um identificador denominado "Nome Principal do Serviço" (SPN). Considere um SPN como um identificador exclusivo de domínio ou 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 várias instâncias de serviço Web no mesmo computador físico com um SPN exclusivo.

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.

Por exemplo, um SPN típico para um computador com o SQL Server é o seguinte:


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. Assim, qualquer problema sobre como o endereço IP ou o nome de anfitrião é resolvido para o DNS totalmente qualificado pela WinSock pode fazer com que o controlador SQL Server crie um SPN inválido para o computador onde corre o SQL Server.

Por exemplo, os SPNs inválidos que o controlador do SQL Server do lado do cliente pode formar como estando completamente qualificado para DNS são os seguintes:

  • 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 SQL Server formar um SPN válido, mas não estiver atribuído ao contentor apropriado, ele tenta utilizar o SPN mas não consegue. Isto origina a 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. Dado que a autenticação tentará utilizar o primeiro SPN que encontra, certifique-se de que não existem SPNs associados a contentores incorretos. 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 no servidor utilizando o utilitário de linha de comandos Ping. No computador cliente, execute o seguinte comando para obter o endereço IP do servidor com o SQL Server (onde o nome do computador que está a executar o SQL Server é SQLServer1):

ping sqlserver1 Para verificar se o utilitário Ping resolve o DNS completamente 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 resolve para o DNS completamente qualificado correto do computador com o SQL Server, a resolução do lado do cliente também é bem-sucedida.

Criação do Nome Principal do Serviço do SQL Server Trata-se de uma das partes importantes da autenticação Kerberos e da interação com o SQL Server. Com o SQL Server, pode executar o serviço SQL Server sob um dos seguintes: uma conta 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: Para mais informações sobre a função DsWriteAccountSpn, aceda aos seguintes Web sites da Microsoft:

http://msdn2.microsoft.com/library/ms676056.aspx

Explicação simplificada Se executar o serviço SQL Server na conta LocalSystem, o SPN é registado automaticamente e a autenticação Kerberos interage com êxito 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 conta de serviço do SQL Server, o SPN é criado com êxito porque as credenciais de administrador do domínio que tem de ter 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. Assim, tem de criar manualmente um SPN para o computador que executa o SQL Server se pretender utilizar a autenticação Kerberos quando ligar a um computador com 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. Não é possível atribuir o SPN ao contentor do computador, a menos que o computador que está a executar o SQL Server seja iniciado 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 este é o contentor de contas de computador com a conta de sistema local.
 

 

Esta secção mostra os passos para ajudar a garantir que o computador não tem problemas de SSPI.

Verificar o domínio Verifique se o domínio com o qual inicia sessão pode comunicar com o domínio ao qual o computador com o SQL Server pertence. Também tem de ter a resolução de nomes correta 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 domínio de início de sessão for diferente do domínio do computador com 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 o SQL Server.


    Nota "A conta é fidedigna para delegação" é necessária apenas quando está a delegar credenciais do servidor SQL de destino a um servidor SQL remoto como, por exemplo, num cenário de salto duplo, como consultas distribuídas (consultas de servidor ligadas) que utilizem 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 de administrador do domínio do Windows 2000 ou do Windows Server 2003 podem utilizar o utilitário para controlar o SPN atribuído a um serviço e a uma conta. Para o SQL Server, tem de existir um e apenas 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, terá de executar SetSPN.exe para remover SPNs expirados e, em seguida, terá de adicionar um SPN válido. Para obter mais informações, consulte o tópico "Security Account Delegation" no SQL Server 2000 Books Online: Para tal, visite o seguinte Web site da Microsoft:

    http://msdn2.microsoft.com/library/aa905162(SQL.80).aspx Para mais informações sobre o Windows 2000 Resource Kits, visite o seguinte 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 nomes podem incluir DNS, WINS, ficheiros Hosts e ficheiros 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 DNS do Windows Server 2003
     

    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, tem de alterar as definições de controlo de acesso da conta no serviço de diretório do 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 o snap-in de edição do Active Directory Service Interfaces (ADSI), o utilitário LDP ou qualquer outro cliente LDAP versão 3 e modificar de forma incorreta os atributos de objetos do Active Directory, poderá provocar problemas graves. Estes problemas poderão forçar a reinstalação do Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003 ou de ambos (Windows e Exchange). Não é possível garantir que os problemas causados pela alteração incorreta dos atributos dos objetos do Active Directory podem ser resolvidos. Todo e qualquer risco decorrente da modificação destes atributos é da responsabilidade do utilizador.

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.msc e, 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 nome do domínio de raiz.

    • AccountName é um marcador de posição para a conta que especifica para iniciar o serviço SQL Server.

    • Se especificar 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 a 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 WriteServicePrincipalName à conta de serviço SQL quando se verificarem as seguintes condições:

  • Existem vários controladores de domínio.

  • SQL Server está em cluster.

Neste cenário, o SPN para o SQL Server pode ser eliminado devido a latência na replicação do Active Directory. Isto poderá causar problemas de conectividade à instância do SQL Server.

Assumir que tem o seguinte:

  • Uma instância virtual de SQL denominada Sqlcluster com dois nós: O Nó A e o 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 registou o SQL SPN no controlador de domínio A durante o arranque..

  2. A instância Sqlcluster falha para Nó B quando o Nó A é encerrado normalmente.

  3. A instância Sqlcluster anula o registo do 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 para o controlador de domínio B.

  5. Ao iniciar no Nó B, a instância Sqlcluster tenta registar o SPN SQL com o controlador de domínio B. Visto que o SPN ainda existe, 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 (do passo 3) para o controlador de domínio B como parte da replicação do Active Directory. O resultado final é não existir um SPN válido para a instância SQL no domínio e, por isso, vê problemas de ligação à instância Sqlcluster.


Nota Este problema é corrigido no SQL Server 2012.

Verifique o ambiente do servidor Verifique algumas definições básicas no computador onde o SQL Server está instalado:

  1. A autenticação Kerberos não é suportada em computadores baseados no Windows 2000 que estejam a executar o Clustering do Windows, a menos que tenha aplicado o Service Pack 3 (ou uma versão posterior) ao Windows 2000. Assim, qualquer tentativa de utilizar a autenticação SSPI numa instância em cluster do SQL Server pode falhar. Para obter mais informações, clique no número de artigo seguinte para ver o artigo na Base de Dados de Conhecimento Microsoft:

    235529 Suporte da 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 o suporte da 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 se 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://msdn2.microsoft.com/library/aa176564(SQL.80).aspx

Verificar 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 seguinte para ver o artigo na Base de Dados de Conhecimento Microsoft:

    269541 Mensagem de erro ao ligar ao 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 utilizando credenciais em cache, termine a sessão no computador e volte a iniciar sessão quando conseguir ligar a um controlador de domínio para impedir 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 se segue para visualizar o artigo na Base de Dados de Conhecimento 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. SSPI utiliza um ficheiro com o nome Security.dll. Se qualquer outra aplicação instalar um ficheiro que utilize este nome, o outro ficheiro poderá ser utilizado em vez do ficheiro SSPI real. Para obter mais informações, clique no número de artigo seguinte para ver o artigo na Base de Dados de Conhecimento Microsoft:

    253577 Mensagem de 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 seguinte para ver o artigo na Base de Dados de Conhecimento Microsoft:

    267550 ERRO: "Falha de asserção" ao ligar a um SQL Server através de TCP/IP
     

Verificar o utilitário de rede do cliente O Client Network Utility (CNU) é fornecido em conjunto com o Microsoft Data Access Components (MDAC) e é utilizado para configurar a conectividade a computadores com 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 varia 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 verificar se um alias está definido para o servidor a que está a tentar ligar. Se for definido um alias de servidor, verifique as definições de configuração deste computador para se ligar ao SQL Server. Pode verificar isto eliminando o alias de servidor para ver se o comportamento muda.

  3. Se o alias de servidor não estiver definido em CNU, adicione o alias para o 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.

Configure manualmente um Nome 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 só está disponível em computadores baseados no Windows 2000 que tenham 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. A Autenticação do Windows também é conhecida como Ligações Fidedignas ou Segurança Integrada. O SSPI não utilizado para Pipes Nomeados ou ligações multiprotocolo. Assim, pode evitar o problema configurando clientes para ligar a partir 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 com o SQL Server tiver 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).
 

 

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 incidente 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 do suporte, visite o seguinte web site da Microsoft.

http://support.microsoft.com/pt-pt/contactus/?ws=support

  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. Captura de ecrã do erro no cliente.

  3. Abra uma linha de comandos no nó que não consegue ligar ao SQL Server e, em seguida, escreva o seguinte comando:

    net start > started.txt Este comando gera um ficheiro denominado Started.txt no diretório em que executa o comando.

  4. Guarde os valores para a chave de registo na seguinte chave de registo no computador cliente:

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO

  5. Num ambiente em cluster, localize o valor da seguinte chave 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ó do cluster de servidores:

    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 de 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 ligar ao computador com o SQL Server a partir do mesmo cliente utilizando a Autenticação SQL Server.

  12. Verifique se pode estabelecer ligação utilizando o protocolo Pipes Nomeados.

Referências Para obter mais informações sobre como a autenticação Kerberos e a segurança SSPI funcionam, 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 livro branco sobre segurança do Microsoft SQL Server 2000, visite o seguinte Web site da Microsoft:

http://technet.microsoft.com/cc984178.aspx

Precisa de mais ajuda?

Aumente os seus conhecimentos
Explore as formações
Seja o primeiro a obter novas funcionalidades
Aderir ao Microsoft insiders

As informações foram úteis?

Obrigado pelos seus comentários!

Obrigado pelo seu feedback! Parece que poderá ser benéfico reencaminhá-lo para um dos nossos agentes de suporte do Office.

×