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

Nesta página

Sumário

Este artigo passo a passo descreve como resolver problemas das fontes mais típicas da mensagem de erro "Não é possível gerar contexto SSPI". Poderá receber esta mensagem de erro sob as seguintes condições:
  • Está a ligar ao SQL Server.
  • Está a utilizar a Segurança Integrada.
  • O Kerberos é utilizado 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 correctamente 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 efectua 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
  • 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 o Kerberos para delegar por TCP/IP e não consegue concluir as operações necessárias para delegar correctamente 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 escolhe o NTLM ou o Kerberos

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 de rede. 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.
Por exemplo, 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 relacionados com a forma como 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.

Por exemplo, os 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 directó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, tenta utilizar o SPN mas não pode, originando 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 aos contentores inadequados. Resumindo, cada SPN deve ser associado a um único contentor.

O principal factor 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 da 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 da linha de comandos Ping resolve o DNS completamente qualificado do SQLServer1, execute o seguinte comando:
ping -a IPAddress
Por exemplo:
C:\>ping SQLSERVER1

A efectuar 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 efectuar 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 EndereçoIP resolve para o DNS correcto 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 críticas da interacçã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, visite o seguinte Web site da Microsoft:
http://msdn2.microsoft.com/en-us/library/ms676056.aspx

Explicação simplificada

Se executar o serviço SQL Server na conta LocalSystem, o SPN é automaticamente registado e o Kerberos interage correctamente 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 ao utilizar 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 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 o sistema local Apenas pode haver um SPN, que tem de ser associado ao contentor adequado. Normalmente, trata-se da conta de serviço SQL Server actual. No entanto, esta é a conta de computador com o sistema local.

Verificar o domínio

Verifique se o domínio no qual inicia sessão pode comunicar com o domínio ao qual o computador que está a executar o SQL Server 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 correctamente 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" é apenas necessário 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 2003 podem utilizar o utilitário para controlar o SPN associado a um serviço e a uma conta. No caso de SQL Server, apenas pode haver um SPN. O SPN tem de ser associado ao próprio conteúdo, a conta de serviço do SQL Server actual 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 sempre que 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" no SQL Server 2000 Books Online. Para tal, visite o seguinte Web site da Microsoft:
    http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx
    Para mais informações sobre os Resource Kits dos Windows 2000, visite 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 correctamente. 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

Como 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 modificar as definições de controlo de acesso da conta no serviço de directó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 modificar de forma incorrecta os atributos de objectos do Active Directory, poderá provocar sérios problemas. Estes problemas poderão forçar a reinstalação do Microsoft Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, ou de ambos (Windows e Exchange). Não podemos garantir que os problemas resultantes da modificação incorrecta dos atributos de objectos do Active Directory possam ser resolvidos. Modifique 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 objecto na lista Aplicar em e, em seguida, certifique-se de que as caixas de verificação das seguintes permissões estão seleccionadas 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.

Verifique o ambiente do servidor

Verifique algumas definições básicas no computador em que o SQL Server está instalado.
  1. O Kerberos não é suportado 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á não ser concluída com êxito. Para obter mais informações, clique no número de artigo que se segue para ver o artigo na Base de Dados de Conhecimento da Microsoft:
    235529 Suporte do 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 do 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/en-us/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á correctamente instalado e activado no cliente. Para obter mais informações, clique no número de artigo que se segue para ver 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 estiver 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 nomeado Security.dll. Se qualquer outra aplicação instalar um ficheiro com este nome, o outro ficheiro pode ser utilizado, em vez do ficheiro SSPI actual. Para obter mais informações, clique no número de artigo que se segue para ver 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 ver 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 seleccionar 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 tiver sido 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 aliar 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.

Informações a recolher para abrir um caso de Suporte Técnico da Microsoft (PSS)

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 Técnico da Microsoft (PSS):

Para obter uma lista completa dos números de telefone do Suporte Técnico da Microsoft, bem como informações sobre os custos de suporte, visite 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. No nó que não liga ao SQL Server, escreva o seguinte comando a partir da linha de comandos:
    net start > started.txt
    Este comando gera um ficheiro nomeado Started.txt no directó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, obtenha 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 efectuar 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 efectuar 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.

Como configurar manualmente um Nome do Principal do Serviço para o 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 o Kerberos activado 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 seus 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 efectuar 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, correctamente configurado. 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).

Referências

Para mais informações como funciona a segurança do Kerberos e 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 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 activar 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
326985 Como resolver problemas de questões relacionadas com o Kerberos em IIS
Para ver um papel branco sobre a segurança do Microsoft SQL Server 2000, visite o seguinte Web site da Microsoft:
http://technet.microsoft.com/en-us/cc984178.aspx

Propriedades

Artigo: 811889 - Última revisão: 17 de setembro de 2011 - Revisão: 3.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
Palavras-chave: 
kbsqlsetup 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