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):
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.
- 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.
- 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.
- 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.
- Use a opção A conta é confiável para
delegação em Usuários e computadores do Active Directory ao iniciar o
SQL Server.
- 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):Para obter mais informações sobre os Kits de recursos do Windows
2000, visite o seguinte site da Microsoft (em inglês):
- 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
(http://support.microsoft.com/kb/169790/
)
Como solucionar problemas básicos de TCP/IP
- 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
(http://support.microsoft.com/kb/291382/
)
Perguntas freqüentes sobre Windows 2000 DNS e Windows Server 2003 DNS
224196
(http://support.microsoft.com/kb/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:
- Clique em Iniciar, em
Executar, digite Adsiedit.msc e clique
em OK.
- 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.
- No CN=NomedaConta Na
caixa de diálogo Propriedades clique na guia
Segurança.
- Na guia Segurança, clique em
Avançado.
- 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. - Em Entradas de permissão, clique em
SELF e, em seguida clique em Editar.
- Na caixa de diálogo Entrada de permissão,
clique na guia Propriedades.
- 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
- 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:
- 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
(http://support.microsoft.com/kb/235529/
)
Suporte para Kerberos em clusters de servidor com base no Windows 2000
- 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
(http://support.microsoft.com/kb/267588/
)
A mensagem de erro "Não é possível gerar contexto SSPI" é exibida quando você se conecta ao SQL Server 2000
- 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
(http://support.microsoft.com/kb/239885/
)
Como alterar as contas de serviço em um computador agrupado que está executando SQL Server
- 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):
Verificar o ambiente do cliente
Verifique o seguinte no cliente:
- 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
(http://support.microsoft.com/kb/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"
- 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
(http://support.microsoft.com/kb/242536/
)
O usuário não é alertado ao fazer o logon com credenciais de domínio armazenadas em cache
- 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.
- 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
(http://support.microsoft.com/kb/253577/
)
Erro: 80004005 - Driver ODBC do SQL Server da MS não pode inicializar pacote SSPI
- 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
(http://support.microsoft.com/kb/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:
- 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.
- 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.
- 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:
- 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:
- Capture uma cópia da tela do erro no cliente.
- 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. - 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
- 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
- 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
- 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.
- 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.
- Salve o nome das contas de usuário usadas para iniciar
cada um dos serviços do SQL Server (MSSQLServer, SQLServerAgent,
MSSearch).
- O profissional de suporte deve saber se o SQL Server está
configurado para autenticação mista ou apenas do Windows.
- Verifique se você pode conectar-se ao computador executando
SQL Server a partir do mesmo cliente usando a autenticação do SQL
Server.
- 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
(http://support.microsoft.com/kb/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).
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
(http://support.microsoft.com/kb/266080/
)
Respostas às perguntas freqüentes sobre Kerberos
231789
(http://support.microsoft.com/kb/231789/
)
Processo de logon local para Windows 2000
304161
(http://support.microsoft.com/kb/304161/
)
Autenticação mútua do SSPI é indicada no lado do cliente, mas não no lado do servidor
232179
(http://support.microsoft.com/kb/232179/
)
Administração Kerberos no Windows 2000
230476
(http://support.microsoft.com/kb/230476/
)
Descrição de erros comuns relacionados a Kerberos no Windows 2000
262177
(http://support.microsoft.com/kb/262177/
)
Como habilitar o registro de evento Kerberos
277658
(http://support.microsoft.com/kb/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
(http://support.microsoft.com/kb/244474/
)
Como forçar Kerberos para usar TCP no lugar de UDP no Windows Server 2003, Windows XP e no Windows 2000
326985
(http://support.microsoft.com/kb/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):