Como usar a autenticação Kerberos no SQL Server

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

Neste artigo

Sumário

Você pode usar a autenticação Kerberos com o Microsoft SQL Server 2000. SQL Server 2000 suporta esta funcionalidade como parte de um típico Microsoft Windows 2000 ou Domínio do Active Directory do Microsoft Windows Server 2003 instalação. Com o Microsoft Windows 2000 Service Pack 3 (SP3) e Windows Server 2003, você pode ativar o Autenticação Kerberos em clusters de servidor.

Para obter mais informações sobre isso adicionado funcionalidade, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
235529Suporte ao Kerberos em clusters de servidor baseado no Windows 2000

Observação Você só pode usar esse recurso se você estiver executando o Windows 2000 SP3 ou Windows Server 2003.

SQL Server 2000 cluster de failover também usa essa funcionalidade. Quando o nome da rede recursos do SQL Server depende está em um cluster baseado no Windows 2000, Você pode usar a autenticação Kerberos no recurso após a atualização do computador para o Windows 2000 SP3 ou para o Windows Server 2003. Para instalar o SQL Server cluster de failover, você deve ter o Microsoft SQL Server 2000 Enterprise Edition ou Developer Edition instalado.

Observação Os conceitos e as discussões neste artigo se aplicam ao SQL Server 2000 também se aplicam ao SQL Server 2005. Para obter mais informações sobre esse assunto no SQL Server 2005, consulte os seguintes tópicos nos Manuais Online do SQL Server 2005:
  • Como: ativar a autenticação Kerberos incluindo servidores virtuais do SQL Server em Clusters de servidor
  • Registro de nome Principal de serviço
Para obter mais informações sobre como se certificar de que você está usando a autenticação Kerberos no SQL Server 2005, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
909801Como se certificar de que você está usando a autenticação Kerberos ao criar uma conexão remota com uma instância do SQL Server 2005

Mais Informações

SQL Server pode usar a autenticação Kerberos para o servidor clusters. Você pode usar a autenticação Kerberos com computadores autônomos que executando o SQL Server, ou com instâncias do SQL Server que estiver executando em um servidor virtual.

Conectar a um servidor que esteja executando o Microsoft Serviços de informações da Internet e fazer uma conexão Kerberos para SQL Server 2000

Esta seção descreve como se conectar a um servidor que está executando Serviços de Informações da Internet da Microsoft (IIS) para fazer uma conexão Kerberos para um servidor que esteja executando o SQL Server.

Nota
antes de executar o procedimento de instalação, baixe o Kerbtray e utilitários SetSPN.

Para baixar o utilitário Kerbtray, visite o seguinte Web site da Microsoft: Com Kerbtray.exe, você pode facilmente verificar ou remover (ou ambos) Tíquetes Kerberos de qualquer um dos computadores associados que estão sendo usados.

Para baixar o utilitário SetSPN, visite o seguinte Microsoft Web site:
http://www.microsoft.com/downloads/details.aspx?FamilyId=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en


O procedimento a seguir fornece um exemplo de um programa de instalação seqüência em que você usa a autenticação Kerberos por meio de uma página do IIS para acessar um servidor que está executando o SQL Server.

Etapa 1: Configurar o controlador de domínio

Em um controlador de domínio no Active Directory Users and Computers:
  1. Com o botão direito no computador que você deseja definir para delegação (servidor de serviços do IIS) e, em seguida, clique para selecionar Esta relação de confiança computador para delegação. Se o computador que está executando o SQL Server o que parece ser o último computador contatado, mas esse computador tem um vinculado servidor, ele também deve ter permissões de delegação. Se não for o último computador na cadeia, todos os computadores são intermediários devem ser confiável para delegação.
  2. Conceder permissão de delegação para o serviço do SQL Server conta de usuário de domínio de conta. Você deve ter uma conta de usuário de domínio para o cluster Instalações do SQL Server (essa etapa não é necessária para computadores que estejam executando o SQL Server que estiver usando uma conta de sistema local):
    1. No Usuários pasta, clique com botão direito do conta de usuário e clique em Propriedades.
    2. Na caixa de diálogo de propriedades do conta de usuário, clique no Conta guia.
    3. Em Opções de conta, clique para selecionar o Conta é confiável para delegação caixa de seleção. Certifique-se de que o Conta é sigilosa e não pode ser delegada seleção caixa está desmarcada para esta conta.

      Observação O direito 'Conta é confiável para delegação' só é necessário para a conta de serviço do SQL Server quando você está delegando as credenciais do servidor SQL de destino para um servidor SQL remoto, como em um cenário de salto duplo como consultas distribuídas (consultas de servidor vinculado) que usam a autenticação do Windows.
    Observação Estas etapas se aplicam somente ao Windows 2000 Server. Se você estiver usando o Windows Server 2003, visite o seguinte site da Microsoft Developer Network (MSDN):
    http://technet2.microsoft.com/WindowsServer/en/Library/bef202b0-c8e9-4999-9af7-f56b991a4fd41033.mspx
  3. Use o utilitário Kerbtray.exe exe para verificar que Kerberos tíquetes foram recebidos do controlador de domínio e host:
    1. Com o botão direito no ícone Kerbtray na notificação área e, em seguida, clique em remover permissões.
    2. Aguarde até que o ícone Kerbtray verde alterar de verde para amarelo. Assim que isso ocorrer, abra uma janela de prompt de comando e executá-lo comando:
      net session * /d
      Isso irá soltar as sessões existentes e forçar uma nova sessão para ser estabelecido e um tíquete Kerberos recebidos.

Etapa 2: Configurar o servidor de serviços do IIS

  1. Substituir os arquivos do Web site Wwwroot padrão com o exemplo arquivos. ASP. Para criar os arquivos. ASP de exemplo, use o código que é fornecido no a seção "Teste de ASP script para recuperação de dados do SQL Server".
  2. Adicione o arquivo para a pasta Wwwroot. Para fazer isso, use o código de exemplo na seção "ASP teste Script de SQL Server recuperação de dados". Salve o arquivo como default. ASP.
  3. Reconfigurar o servidor Web para usar o Windows integrada Autenticação:
    1. Com o botão direito o servidor Web padrão e, em seguida, clique no Pasta de segurança.
    2. Na pasta de segurança, faça as alterações corretas, e em seguida, clique para desmarcar acesso anônimo.
    3. Em um prompt de comando, execute este comando:
      cscript C:\Inetpub\Adminscripts\adsutil.vbs obter W3SVC/NTAuthenticationProviders
      Se Negotiate for habilitada, será retornado o seguinte:
       NTAuthenticationProviders : (STRING) Negotiate,NTLM
      Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
      215383Como configurar o IIS para suportar o protocolo Kerberos e o protocolo NTLM para autenticação de rede
    Anotações
    • Você deve instalar o Microsoft Data Access (MDAC) 2.6 ou posterior, em o servidor de serviços do IIS. Para fazer isso (e para disponibilizar as ferramentas para teste), instale o SQL Server 2000 client tools para o servidor Web. Para instalar apenas o MDAC 2.6 ou posterior (sem instalar as ferramentas de cliente), visite o seguinte site da Web Microsoft:
      http://msdn2.microsoft.com/en-US/Data/aa937730.aspx
    • O IIS é um sistema comum de camada intermediária. No entanto, o IIS não é o sistema de camada intermediária somente. Se o IIS não é o sistema de camada intermediária em seu ambiente, siga as etapas apropriadas para seu sistema de camada intermediária.
  4. Verifique se o
    HKLM\SW\MS\MSSQLSERVER\Client\DSQUERY
    valor estiver presente no registro. Se o valor não for exibido, adicioná-lo como
    DSQUERY:Reg_SZ:DBNETLIB
    .
  5. Use o utilitário Kerbtray.exe exe para verificar que Kerberos tíquetes foram recebidos do controlador de domínio e host:
    1. Com o botão direito no ícone Kerbtray na área de notificação, e, em seguida, clique em remover permissões.
    2. Aguarde até que o ícone Kerbtray verde alterar de verde para amarelo. Assim que isso ocorrer, abra uma janela de prompt de comando e executá-lo comando:
      net session * /d
      Isso irá soltar as sessões existentes e forçar uma nova sessão para ser estabelecido e um tíquete Kerberos recebidos.

Etapa 3: Configurar o serviço do SQL Server para criar SPNs dinamicamente

Para fazer isso, você deve conceder as seguintes configurações de controle de acesso para a conta de serviço do SQL Server no serviço de diretório do Active Directory:
  • Ler servicePrincipalName
  • Escrever servicePrincipalName
Avisos
  • Se você usar o snap-in Active Directory Service Interfaces (ADSI) Edit, o utilitário LDP ou os clientes LDAP 3 e modificar incorretamente os atributos de objetos do Active Directory, sérios problemas. Para resolver esses problemas, talvez você precise reinstalar o Microsoft Exchange 2000 Server ou Microsoft Exchange Server 2003. Em alguns casos, você terá que reinstalar o Microsoft Windows 2000 Server ou Microsoft Windows Server 2003 e, em seguida, reinstale o Microsoft Exchange 2000 Server ou Exchange Server 2003. Não podemos garantir que esses problemas podem ser resolvidos. Modificar estes atributos em seu próprio risco.
  • Você deve estar conectado como um administrador de domínio. Como alternativa, você deve pedir seu administrador de domínio para conceder as permissões adequadas e direitos de usuário adequados para a conta de inicialização do SQL Server.
Para configurar o serviço do SQL Server para criar SPNs dinamicamente quando o serviço SQL Server é iniciado, siga estas etapas:
  1. Clique em Iniciar, clique em Executar, tipo ADSIEdit. msce, em seguida, clique em OK.

    Observação A ferramenta ADSIEdit está incluída nas ferramentas de suporte do Windows. Para obter as ferramentas de suporte do Windows, visite o seguinte site da Microsoft:
    http://www.microsoft.com/downloads/details.aspx?FamilyId=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en
  2. No snap-in ADSI Edit, expanda [DomínioNome_do_domínio], expanda DC = RootDomainName, expanda CN = Users, clique com botão direito CN = AccountName e, em seguida, clique em Propriedades.

    Anotações
    • Nome_do_domínio é um espaço reservado para o nome do domínio.
    • RootDomainName é um espaço reservado para o nome do domínio raiz.
    • AccountName é um espaço reservado para a conta que você especificar para iniciar o serviço do SQL Server.
    • Se você especificar a conta Sistema Local para iniciar o serviço do SQL Server, AccountName é um espaço reservado para a conta que você usa para fazer logon no Microsoft Windows.
    • Se você especificar uma conta de usuário de domínio para iniciar o serviço do SQL Server, AccountName é um espaço reservado para a conta de usuário de domínio.
  3. No CN = AccountName Propriedades caixa de diálogo, clique no Segurança guia.
  4. Sobre o Segurança Clique em Avançado.
  5. No Configurações de segurança avançadas diálogo caixa, certifique-se de que AUTO- está listado em Entradas de permissão.

    Se AUTO- não é listado, clique em Adicionare, em seguida, adicionar AUTO-.
  6. Em Entradas de permissão, clique em AUTO-e, em seguida, clique em Editar.
  7. No Entrada de permissão caixa de diálogo, clique no Propriedades guia.
  8. Sobre o Propriedades Clique em Apenas este objeto no Aplica-se ao lista e, em seguida, clique para selecionar as caixas de seleção para as seguintes permissões em Permissões:
    • Ler servicePrincipalName
    • Escrever servicePrincipalName
  9. Clique em OK duas vezes.

    Observação Para obter ajuda com esse processo, entre em contato com o suporte de produto do Active Directory e Mencione este artigo da Base de dados de Conhecimento da Microsoft.

    Observação Para usar a ferramenta dsacls para determinar se a conta self tem a permissão de gravação ServicePrincipalName, use o comando dsacls . A sintaxe é:
    dsacls <distinguished_Name_of_service_account>
    Se a conta self tem a permissão de gravação ServicePrincipalName, você verá a seguinte saída:
    Allow NT Authority\SELF SPECIAL ACCESS for Validated Write to Service principal name
    WRITE PROPERTY
    A ferramenta dsacls faz parte das ferramentas de suporte.
  10. No CN = AccountName Propriedades caixa de diálogo, clique em Editor de atributos.
  11. Em Atributos, clique em servicePrincipalName no Atributo coluna e clique em Editar.
  12. No Editor de seqüência de caracteres de valores múltiplos diálogo caixa, remova os nomes de princípio de serviço (SPNs) para as instâncias do SQL Server que usam essa conta de serviço do SQL Server.

    Aviso Você só deve excluir os SPNs para as instâncias do SQL Server que você está trabalhando atualmente. Outras instâncias do SQL Server que usam essa conta de serviço será capazes de remover os SPNs estão relacionados a estas instâncias na próxima vez que iniciar essas instâncias.
  13. Feche o snap-in ADSI Edit.
Após seguir essas etapas, o SPN problemas também são eliminados se você alterar a porta TCP/IP ou o nome de domínio para novas instalações do SQL Server 2005 ou instâncias existentes do SQL Server 2005.

Importante Recomendamos que você não conceda WriteServicePrincipalName direita para a conta do serviço SQL quando as seguintes condições forem verdadeiras:
  • Existem vários controladores de domínio.
  • SQL Server está em cluster.
Nesse cenário, o SPN para o SQL Server pode ser excluído devido à latência de replicação do Active Directory. Isso pode causar problemas de conectividade para a instância do SQL Server.

Suponha que você tenha o seguinte:
  • Uma instância SQL virtual chamada Sqlcluster com dois nós: nó A e o nó B.
  • Nó A é autenticado por um controlador de domínio e o nó B é autenticado pelo controlador de domínio B.


Pode ocorrer o seguinte:
  1. A instância de Sqlcluster está ativa no nó A e registrado o SPN do SQL em um controlador de domínio durante a inicialização do backup...
  2. A instância de Sqlcluster failover para o nó B ao nó A é desligado normalmente.
  3. A instância de Sqlcluster o registro cancelado o SPN de um controlador de domínio durante o processo de desligamento 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 de Sqlcluster tenta registrar o SPN do SQL com o controlador de domínio B. Desde então, o SPN ainda existe nó B não registrar o SPN.
  6. Após algum tempo, o controlador de domínio A replica a exclusão do SPN (da etapa 3) para o controlador de domínio B como parte da replicação do Active Directory. O resultado final é que não existe nenhum SPN válido para a instância SQL no domínio e, portanto, você pode ver os problemas de conexão com a instância de Sqlcluster.

Observação Esse problema é corrigido no SQL Server 2012.


Etapa 4: Configurar os computadores cliente

  1. Para cada cliente que irá se conectar, verifique se que a Microsoft Internet Explorer está configurado para usar autenticação do Windows:
    1. No Internet Explorer, sobre o Ferramentasmenu, clique em Opções da Internet.
    2. Clique no Avançado guia.
    3. Em Segurança, clique para selecionar Ativar autenticação integrada do Windows (requer reinicialização), e, em seguida, clique em OK.

Etapa 5: Testar a configuração

Para cada computador que está envolvido:
  1. Faça logon computador e, em seguida, use Kerbtray.exe para verificar Se o computador pode obter um tíquete Kerberos válido do domínio controlador.
  2. Use Kerbtray.exe para remover todas as permissões sobre o computador.
  3. Criar e conectar-se à página da Web que retorna o SQL Dados do servidor.

    Observação Substituir NOME_SERVIDOR_SQL com o nome de o computador que está executando o SQL Server:
    • Se os dados são retornados, esta página exibe a tipo de autenticação Negotiatee os dados do SQL Server para obter o resultado de sp_helpdb procedimento armazenado que deve retornar uma lista dos bancos de dados em o servidor que está sendo conexão com à.Página do ASP.
    • Se você tiver auditoria ativada no SQL Server, além de Log de aplicativo, você verá que a conexão é "confiável".

Script de teste ASP para recuperação de dados do SQL Server

Eis aqui um script de teste ASP para dados do SQL Server. Se você usá-lo amostra de código, certifique-se de que você substitua NOME_SERVIDOR_SQL com o nome do computador que está executando o SQL Server.
<%@ Language=VBScript %>
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">
</HEAD>
<BODY>
<%="'auth_user' is" & request.servervariables("auth_user")%>
<P>
<%="'auth_type' is" & request.servervariables("auth_type")%>
<P>
Connections string is " Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=pubs;Data Source=SQLSERVERNAME 
<P>
<%
	set rs = Server.CreateObject("ADODB.Recordset")
	set cn = Server.CreateObject("ADODB.Connection")
	cn.Open "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=pubs;Data Source=SQLSERVERNAME"
	rs.open "MASTER..sp_helpdb",cn
	Response.Write cstr(rs.Fields.Count) +"<BR>"
	while not rs.EOF
		Response.Write cstr(rs(0))+"<BR>"
		rs.MoveNext
	wend
	rs.Close
	cn.Close
	set rs = nothing ' Frees memory reserved by the recordset.
	set cn = nothing ' Frees memory reserved by the connection.
%>
</BODY>
</HTML>
					

Como obter uma lista de princípio de servidor do Active Directory informações de nome

Para obter uma lista de nome principal do servidor do Active Directory (SPN) informações, digite o seguinte comando em um dos controladores de domínio, onde betaland é o nome de domínio NetBIOS e NewoutputUsers.txt é o nome do arquivo de saída que você usará os resultados da porta. Se você não usar um caminho completo, o arquivo. é colocado na pasta atual em que você executa a linha de comando. Este exemplo comando consulta o domínio inteiro:
LDIFDE -d "CN = Users, DC =betaland"servicePrincipalName -l -F NewoutputUsers. txt
Essa sintaxe cria um arquivo chamado NewoutputUsers.txt que contém informações semelhantes a saída no nível de domínio" seção de saída de NewouputUsers.txt"neste artigo.

Esta saída pode ser complicado quando coletá-los para um domínio inteiro. Portanto, para limitar a as informações coletadas para um nome de usuário específico, use a seguinte sintaxe, onde Nome de usuário é o nome de usuário e betaland é o domínio que você está consultando:
LDIFDE -d "CN =Nome de usuárioDC =betaland"servicePrincipalName -l -F NewoutputUsers. txt
Coleta as informações para um usuário específico reduz bastante o dados que você deve pesquisar. Se você reunir as informações de um todo domínio, procure o nome de usuário específico do servidor em questão. No exemplo de saída, consulte:
  • Entradas para os servidores que não existem mais, mas que não foram completamente removido do Active Directory.
  • O usuário"Nome de usuário"é válido Informações de SPN sobre dez servidores diferentes.
Além disso, você pode usar o serviço do Active Directory Interfaces de ferramenta (ADSI) para corrigir as entradas do Active Directory que não são válidas.

Aviso Se você usar o snap-in ADSI Edit, o utilitário LDP ou qualquer outro Cliente do LDAP versão 3 e modificar incorretamente os atributos do Active Objetos de diretório, você pode causar problemas sérios. Esses problemas podem exigir a reinstalação do Microsoft Windows 2000 Server, Microsoft Windows Server 2003 Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003 ou Windows e do Exchange. A Microsoft não garante que os problemas que ocorrem se você modificar incorretamente os atributos de objeto podem ser resolvidos de Active Directory. Modificar Esses atributos de sua responsabilidade.

Saída de nível de domínio de NewouputUsers.txt

	dn: CN=User Name,CN=Users,DC=betaland
	changetype: add
	servicePrincipalName: MSSQLSvc/CLUSTERDEFAULT.betaland:1257
	servicePrincipalName: MSSQLSvc/INST3.betaland:3616
	servicePrincipalName: MSSQLSvc/INST2.betaland:3490
	servicePrincipalName: MSSQLSvc/SQLMAN.betaland:1433
	servicePrincipalName: MSSQLSvc/VSS1.betaland:1433
	servicePrincipalName: MSSQLSvc/INST1.betaland:2536
	servicePrincipalName: MSSQLSvc/INST4.betaland:3967
	servicePrincipalName: MSSQLSvc/SQLVIRTUAL1.betaland:1434
	servicePrincipalName: MSSQLSvc/SQLVIRTUAL.betaland:1433
	servicePrincipalName: MSSQLSvc/SQLBUSTER.betaland:1315

Referências

Para obter mais informações sobre delegação de conta de segurança, consulte o tópico "Delegação de conta de segurança" nos Manuais Online do SQL Server.

Para obter mais informações, clique nos números abaixo Para visualizar os artigos na Base de dados de Conhecimento da Microsoft:
262177Como ativar o log de evento Kerberos
321708 Como usar a ferramenta de diagnóstico de rede (Netdiag.exe) no Windows 2000
326985 Como solucionar problemas relacionados ao Kerberos no IIS
244474 Como forçar o Kerberos a utilizar TCP em vez de UDP no Windows Server 2003, Windows XP e Windows 2000

Propriedades

ID do artigo: 319723 - Última revisão: domingo, 7 de abril de 2013 - Revisão: 2.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2000 Standard Edition nas seguintes plataformas
    • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Palavras-chave: 
kbinfo kbmt KB319723 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 319723

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