Compartilhar via

Visão geral da autenticação Kerberos para Produtos do Microsoft SharePoint 2010

  • Artigo

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

O Produtos do Microsoft SharePoint 2010 introduz aprimoramentos significativos no modo como a identidade é gerenciada na plataforma. É muito importante entender como essas alterações afetam o design de soluções e a configuração de plataformas para habilitar cenários que exigem que a identidade do usuário seja delegada a sistemas integrados. O protocolo Kerberos versão 5 desempenha um papel fundamental para habilitar a delegação e, às vezes, pode ser necessário nesses cenários.

Este conjunto de artigos fornece informações que o ajudam a fazer o seguinte:

  • Entender os conceitos de identidade nos Produtos do SharePoint 2010

  • Aprender como a autenticação Kerberos desempenha um papel muito importante em cenários de autenticação e delegação

  • Identificar as situações em que a autenticação Kerberos deve ser aproveitada ou pode ser exigida em designs de soluções

  • Configurar a autenticação Kerberos ponta a ponta no seu ambiente, incluindo cenários que usam diversos aplicativos de serviços no SharePoint Server

  • Testar e validar se a autenticação Kerberos está corretamente configurada e funcionando conforme esperado

  • Encontrar ferramentas e recursos adicionais para ajudá-lo a configurar a autenticação Kerberos no seu ambiente

Este conjunto de artigos está dividido em duas seções principais:

  • Esta visão geral da autenticação Kerberos em Produtos do SharePoint 2010

    Este artigo contém informações conceituais sobre como gerenciar a identidade no Produtos do SharePoint 2010, sobre o protocolo Kerberos e sobre como a autenticação Kerberos desempenha um papel fundamental nas soluções do SharePoint 2010.

  • Configuração passo a passo

    Este grupo de artigos aborda as etapas necessárias para configurar a delegação e autenticação Kerberos em vários cenários de soluções do SharePoint.

Quem deve ler estes artigos sobre a autenticação Kerberos?

A identidade e a delegação no Produtos do SharePoint 2010 são um tópico amplo, com muitas facetas e níveis de entendimento. Este conjunto de artigos aborda o tópico nos níveis conceitual e técnico, tendo sido elaborado para atender às necessidades de diversas audiências:

Do início ao fim

"Conte-me tudo a respeito de identidade e autenticação Kerberos no Produtos do SharePoint 2010"

Se você está apenas começando e precisa saber mais sobre o Produtos do SharePoint 2010, a autenticação Kerberos e a autenticação de declarações, convém ler a primeira parte deste documento. Ela abrange os conceitos básicos de identidade e delegação e fornece os fundamentos sobre a autenticação Kerberos e de Declarações. Acesse os links de artigos externos e informações adicionais para formar uma sólida base de conhecimentos antes de passar para os artigos de configuração passo a passo.

Atualizando do Office SharePoint Server 2007

"Conte-me o que foi alterado em relação à versão 2007 e qual a preparação necessária ao atualizar para a versão 2010"

Se você já possui um ambiente do Microsoft Office SharePoint Server 2007 configurado para usar a autenticação e a delegação Kerberos, leia os seguintes artigos:

  • Cenários de identidade nos Produtos do SharePoint 2010

  • Fundamentos sobre declarações

  • Alterações na autenticação Kerberos no Windows 2008 R2 e no Windows 7

  • Alterações na configuração Kerberos nos Produtos do SharePoint 2010

  • Considerações ao atualizar do SharePoint Server 2007

Se tiver outras dúvidas sobre como configurar a delegação para um determinado recurso ou cenário, leia os artigos de configuração passo a passo, principalmente as listas de verificação de configuração. Isso o ajudará a garantir que o seu ambiente seja configurado corretamente após a atualização.

Explicação passo a passo

"Desejo obter instruções passo a passo detalhadas sobre como configurar a delegação Kerberos no SharePoint Server e sobre aplicativos de serviço do SharePoint Server aplicáveis"

Os artigos sobre configuração passo a passo abrangem vários cenários do Produtos do SharePoint 2010 que podem ser configurados para usar a delegação Kerberos. Cada cenário é abordado em detalhes, incluindo uma lista de verificação de configuração e instruções passo a passo para ajudá-lo a configurar com êxito a autenticação Kerberos no seu ambiente. Os cenários abordados incluem:

Examine atentamente o primeiro cenário de configuração principal, pois ele é um pré-requisito para todos os cenários seguintes.

Observação

Os cenários incluem comandos "SetSPN" que você pode copiar deste documento e colar em uma janela de Prompt de Comando. Os comandos incluem caracteres de hífen. O Microsoft Word possui um recurso de Formatação Automática que tende a converter hifens em caracteres de traço. Se você ativar esse recurso no Word e depois executar uma operação de copiar e colar, os comandos não funcionarão corretamente. Transforme os traços em hifens para corrigir o erro. Para desativar o recurso de Formatação Automática no Word, selecione Opções no menu Arquivo, clique na guia Revisão de Texto e abra a caixa de diálogo Correção Automática.

Ambientes existentes dos Produtos do SharePoint 2010

"Tenho um ambiente existente dos Produtos do SharePoint 2010 e não consigo fazer com que a autenticação Kerberos funcione. Como validar e depurar minha configuração?"

Os artigos de Configuração passo a passo contêm várias listas de verificação para auxiliar na triagem de seu ambiente em vários cenários. Preste atenção especial ao Cenário 1, Configuração principal, que abrange técnicas e ferramentas básicas para triagem da configuração Kerberos.

Cenários de identidade nos Produtos do SharePoint 2010

Ao aprender sobre identidade no contexto de autenticação no Produtos do SharePoint 2010, você pode examinar conceitualmente a maneira como a plataforma lida com a identidade em três cenários principais: autenticação de entrada, autenticação entre e dentro de farms e autenticação de saída.

Diagrama de autenticação de farm

Identidade de entrada

O cenário de autenticação de entrada representa o meio pelo qual um cliente apresenta sua identidade à plataforma ou, em outras palavras, como ele é autenticado no aplicativo Web ou serviço Web. O SharePoint Server usará a identidade do cliente para autorizá-lo a acessar recursos protegidos do SharePoint Server, como páginas da Web, documentos e assim por diante.

O Produtos do SharePoint 2010 dá suporte a dois modos para autenticação de um cliente na plataforma: Modo clássico e Modo de declarações.

Modo clássico

O Modo clássico permite os métodos de autenticação típicos do IIS (Serviços de Informações da Internet), com os quais você talvez já tenha se familiarizado em versões anteriores do SharePoint Server. Quando um aplicativo Web do SharePoint Server 2010 é configurado para usar o modo clássico, você tem a opção de usar os seguintes métodos de autenticação do IIS:

Autenticação integrada do Windows

A autenticação integrada do Windows permite que clientes do Windows se autentiquem diretamente no SharePoint Server sem precisar fornecer credenciais manualmente (nome de usuário/senha). Os usuários que acessarem o SharePoint Server via Internet Explorer serão autenticados usando as credenciais com as quais o processo do Internet Explorer estiver sendo executado — por padrão, trata-se das credenciais com as quais o usuário fez logon na área de trabalho. Os serviços ou aplicativos que acessarem o SharePoint Server no modo integrado do Windows tentarão se autenticar usando as credenciais do thread em execução, que é a identidade do processo por padrão.

NTLM

O protocolo NTLM é o tipo de protocolo padrão quando a autenticação integrada do Windows é selecionada. Esse protocolo tira proveito de uma sequência de desafio/resposta em três partes para autenticar os clientes. Para obter mais informações sobre o NTLM, consulte o artigo sobre Microsoft NTLM (https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x416).

Prós:

  • É fácil de configurar e, normalmente, não requer configuração adicional de infraestrutura/ambiente para funcionar

  • Funciona quando o cliente não faz parte do domínio ou não está em um domínio confiável para o domínio em que o SharePoint Server reside

Contras:

  • Exige que o SharePoint Server contate o controlador de domínio sempre que a resposta a uma autenticação de cliente necessitar de validação, aumentando o tráfego para os controladores de domínio.

  • Não permite a delegação de credenciais de clientes a sistemas back-end, o que também é conhecido como regra de salto duplo.

  • É um protocolo patenteado.

  • Não oferece suporte à autenticação do servidor.

  • É considerado menos seguro que a autenticação Kerberos

Protocolo Kerberos

Kerberos é um protocolo mais seguro que oferece suporte à autenticação com tíquetes. Um servidor de autenticação Kerberos concede um tíquete em resposta a uma solicitação de autenticação de um computador cliente, caso a solicitação contenha credenciais de usuário válidas e um SPN (nome de entidade de serviço) válido. Em seguida, o computador cliente usa esse tíquete para acessar recursos da rede. Para habilitar a autenticação Kerberos, os computadores cliente e servidor devem ter uma conexão confiável com o KDC (Centro de Distribuição de Chaves) do domínio. O KDC distribui chaves secretas compartilhadas para habilitar a criptografia. Os computadores cliente e servidor também devem ser capazes de acessar serviços de diretório do Active Directory. No Active Directory, o domínio raiz da floresta é o centro de referências da autenticação Kerberos. Para obter mais informações sobre o protocolo Kerberos, consulte os artigos sobre funcionamento do protocolo de autenticação Kerberos Versão 5 (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x416) e Microsoft Kerberos. (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x416)

Prós:

  • Protocolo de autenticação integrada do Windows mais seguro

  • Permite a delegação de credenciais de clientes

  • Dá suporte à autenticação mútua de clientes e servidores

  • Produz menos tráfego para os controladores de domínio

  • Protocolo aberto com suporte para várias plataformas e fornecedores

Contras:

  • Exige configuração adicional da infraestrutura e do ambiente para funcionar corretamente

  • Requer que os clientes tenham conectividade com o KDC (controlador de domínio do Active Directory em ambientes Windows) sobre TCP/UDP na porta 88 (Kerberos) e TCP/UDP na porta 464 (Alterar Senha do Kerberos – Windows)

Outros métodos

Além da autenticação NTLM e Kerberos, o SharePoint Server dá suporte a outros tipos de autenticação do IIS, como Básica, Digest e baseada em certificado, que não são abordados neste documento. Para obter mais informações sobre como esses protocolos funcionam, consulte o artigo sobre métodos de autenticação com suporte no IIS 6.0 (IIS 6.0) (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x416).

Autenticação baseada em declarações

O suporte à autenticação de declarações é um recurso novo no Produtos do SharePoint 2010 e se baseia no Windows Identity Foundation (WIF). Em um modelo de declarações, o SharePoint Server aceita uma ou mais declarações sobre um cliente que está sendo autenticado, para identificar e autorizar o cliente. As declarações têm a forma de tokens de SAML e são fatos sobre o cliente declarados por uma autoridade confiável. Por exemplo, uma declaração poderia indicar que "Paulo é membro do grupo Administradores de Empresa do domínio Contoso.com". Se essa declaração for proveniente de um provedor de confiança do SharePoint Server, a plataforma poderá usar a informação para autenticar Paulo e autorizá-lo a acessar recursos do SharePoint Server. Para obter mais informações sobre a autenticação de declarações, consulte o artigo que fornece um guia para a identidade baseada em declarações e o controle de acesso (https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x416).

Os tipos de declarações com suporte no Produtos do SharePoint 2010 para autenticação de entrada são Declarações do Windows, Declarações de autenticação baseada em formulários e Declarações SAML.

Declarações do Windows

Na entrada do modo de declarações do Windows, o SharePoint Server autentica o cliente usando a autenticação integrada do Windows padrão (NTLM/Kerberos) e converte a identidade do Windows resultante em uma Identidade de Declarações.

Declarações de autenticação baseada em formulários

No modo de declarações de autenticação baseada em formulários, o SharePoint Server redireciona o cliente para uma página de logon que hospeda os controles de logon ASP.NET padrão. A página autentica o cliente usando provedores de funções e associação ASP.NET, de maneira semelhante ao funcionamento da autenticação baseada em formulários no Office SharePoint Server 2007. Após a criação do objeto de identidade que representa o usuário, o SharePoint Server converte essa identidade em um objeto de identidade de declarações.

Declarações SAML

No modo de Declarações SAML, o SharePoint Server aceita tokens de SAML de um STS (Provedor de Token de Segurança) externo confiável. Quando o usuário tenta fazer logon, o comentário é direcionado a um provedor de declarações externo (por exemplo, um provedor de declarações do Windows Live ID), que autentica o usuário e produz um token de SAML. O SharePoint Server aceita e processa esse token, aumentando as declarações e criando um objeto de identidade de declarações para o usuário.

Para obter mais informações sobre a autenticação baseada em declarações no Produtos do SharePoint 2010, consulte o artigo sobre identidade baseada em declarações do SharePoint.

Observação sobre a autenticação de declarações de entrada e C2WTS (Serviço de Tokens de Declarações para Tokens do Windows)

Alguns aplicativos de serviço exigem que você use o C2WTS (Serviço de Tokens de Declarações para Tokens do Windows) do Windows Identity Foundation (WIF) para converter declarações no farm em credenciais do Windows para autenticação de saída. É importante entender que o C2WTS só funcionará se o método de autenticação de entrada for o modo clássico ou de declarações do Windows. Se as declarações estiverem configuradas, o C2WTS exigirá apenas declarações do Windows; o aplicativo Web não pode usar vários formulários de declarações, caso contrário, o C2WTS não funcionará.

Identidade em um ambiente de Produtos do SharePoint 2010

Ambientes do Produtos do SharePoint 2010 usam a autenticação de declarações para comunicação entre e dentro de farms com a maioria dos aplicativos de serviços e produtos integrados do SharePoint, independentemente do mecanismo de autenticação de entrada utilizado. Isso significa que, mesmo que a autenticação clássica seja usada em um determinado aplicativo Web, os Produtos do SharePoint converterão a identidade de entrada em uma identidade de declarações para autenticação nos produtos e Aplicativos de Serviço do SharePoint com reconhecimento de declarações. Com a padronização do modelo de declarações para comunicação entre e dentro de farms, a plataforma pode se abstrair dos protocolos de entrada que são usados.

Observação

Alguns produtos integrados ao SharePoint Server, como o SQL Server Reporting Services, não têm reconhecimento de declarações e não tiram proveito da arquitetura de autenticação de declarações entre farms. O SharePoint Server também pode utilizar declarações e a delegação Kerberos clássica em outros cenários, por exemplo, quando a Web part de visualizador RSS é configurada para consumir um feed autenticado. Consulte a documentação de cada produto ou aplicativo de serviço para determinar se ele pode dar suporte à autenticação baseada em declarações e à delegação de identidade.

Identidade de saída

A identidade de saída no Produtos do SharePoint 2010 representa os cenários nos quais os serviços no farm precisam ser autenticados em serviços e sistemas de linha de negócios externos. Dependendo do cenário, a autenticação pode ser realizada em um destes dois modelos conceituais básicos:

Subsistema confiável

No subsistema confiável, o serviço front-end autentica e autoriza o cliente e, em seguida, é autenticado em serviços back-end adicionais sem passar a identidade do cliente para o sistema back-end. O sistema back-end confia no serviço front-end para realizar a autenticação e a autorização em seu nome. A forma mais comum de implementar esse modelo é utilizar uma conta de serviço compartilhada para autenticação no sistema externo:

Diagrama de subsistema confiável

No SharePoint Server, esse modelo pode ser implementado de diversas maneiras:

  • Usando a identidade do pool de aplicativos do IIS — geralmente obtida mediante a execução de um código no aplicativo Web que eleva as permissões ao fazer uma chamada para um sistema externo. Outros métodos, como o uso de RevertToSelf, também podem usar a identidade do pool de aplicativos para autenticação em sistemas externos.

  • Usando uma conta de serviço — normalmente obtida com o armazenamento de credenciais de aplicativos no Repositório Seguro e, em seguida, com o uso dessas credenciais para autenticação em um sistema externo. Outros métodos são o armazenamento das credenciais da conta de serviço de outras maneiras, como cadeias de caracteres de conexão inseridas.

  • Autenticação Anônima — esse é o local em que o sistema externo não requer autenticação. Portanto, o serviço front-end do SharePoint Server não precisa passar uma identidade ao sistema back-end.

Delegação

No modelo de Delegação, o serviço front-end autentica primeiro o cliente e, em seguida, usa a identidade desse cliente para autenticação em outro sistema back-end que executa sua própria autenticação e autorização:

Diagrama de processo de delegação

No Produtos do SharePoint 2010, esse modelo pode ser implementado de diversas maneiras:

  • Delegação Kerberos — se o cliente for autenticado no serviço front-end usando a autenticação Kerberos, a delegação Kerberos poderá ser usada para passar a identidade desse cliente ao sistema back-end.

  • Declarações — a autenticação de declarações permite que declarações do cliente sejam passadas entre serviços, desde que haja confiança entre os dois serviços e ambos tenham reconhecimento de declarações.

Observação

Atualmente, a maioria dos aplicativos de serviço incluídos no SharePoint Server não permite a autenticação de declarações de saída, mas as declarações de saída são um recurso de plataforma que será aproveitado no futuro. Além disso, muitos dos sistemas de linha de negócios mais comuns atualmente não dão suporte à autenticação de declarações de entrada, o que significa que o uso da autenticação de declarações de saída pode não ser possível ou exigirá desenvolvimento adicional para funcionar corretamente.

Delegação entre limites de domínios e florestas

Os cenários deste conjunto de artigos sobre a autenticação Kerberos exigem que fontes de dados externas e serviços do SharePoint Server residam no mesmo domínio do Windows, que é necessário para a delegação restrita de Kerberos. O protocolo Kerberos dá suporte a dois tipos de delegação, básica (irrestrita) e restrita. A delegação básica de Kerberos pode cruzar os limites de domínios em uma única floresta, mas não pode cruzar um limite de floresta, independentemente da relação de confiança. A delegação restrita de Kerberos não pode cruzar limites de domínio ou de floresta em cenário algum.

Alguns serviços do SharePoint Server podem ser configurados para usar a delegação Kerberos básica, mas outros serviços exigem que você use a delegação restrita. Qualquer serviço que dependa do C2WTS (Serviço de Tokens de Declarações para Tokens do Windows) deverá usar a delegação restrita de Kerberos para permitir que o C2WTS use a transição do protocolo Kerberos de forma a converter declarações em credenciais do Windows.

Os aplicativos de serviço e produtos a seguir exigem o C2WTS e a delegação restrita de Kerberos:

  • Serviços do Excel

  • Serviços PerformancePoint

  • InfoPath Forms Services

  • Serviços do Visio

Os produtos e aplicativos de serviço a seguir não são afetados por esses requisitos e, portanto, podem usar a delegação básica, se necessário:

  • Serviço de Conectividade de Dados Corporativos e Microsoft Serviços Corporativos de Conectividade

  • Serviços do Access

  • Microsoft SQL Server Reporting Services (SSRS)

  • Microsoft Project Server 2010

O aplicativo de serviço a seguir não permite a delegação de credenciais do cliente e, portanto, não é afetado por esses requisitos:

  • Microsoft SQL Server PowerPivot para Microsoft SharePoint

Fundamentos sobre declarações

Para ver uma introdução aos conceitos de Declarações e à autenticação baseada em Declarações, consulte os artigos de introdução a declarações (https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x416) e de identidade baseada em declarações do SharePoint (https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x416).

Fundamentos sobre o protocolo Kerberos

Para obter uma visão geral conceitual do protocolo Kerberos, consulte o artigo sobre Microsoft Kerberos (Windows) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x416), a explicação sobre Kerberos (https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x416) e as perguntas à equipe de serviços de diretório: Kerberos para o administrador ocupado (https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x416).

Benefícios do protocolo Kerberos

Antes de examinar os detalhes da configuração do SharePoint Server (ou de qualquer outro aplicativo Web) para usar o protocolo Kerberos, vamos falar sobre o protocolo Kerberos em geral e sobre os motivos para usá-lo.

Geralmente, há três razões principais para o uso do protocolo Kerberos:

  1. Delegação de credenciais de cliente — o protocolo Kerberos permite que a identidade de um cliente seja representada por um serviço, de forma que esse serviço passe a identidade para outros serviços de rede em nome do cliente. O NTLM não permite essa delegação (limitação conhecida como "regra de salto duplo". Assim como a autenticação Kerberos, a autenticação de declarações pode ser usada para delegar credenciais do cliente, mas exige que o aplicativo back-end tenha reconhecimento de declarações.

  2. Segurança — recursos como criptografia AES, autenticação mútua, suporte à integridade e à privacidade de dados, para citar apenas alguns, tornam o protocolo Kerberos mais seguro que o seu equivalente NTLM.

  3. Desempenho potencialmente melhor — a autenticação Kerberos exige menos tráfego para os controladores de domínio em comparação ao NTLM (dependendo da verificação do PAC, consulte o artigo sobre o blog da equipe de suporte para especificações abertas da Microsoft: entendendo a validação do PAC do Microsoft Kerberos). Se a verificação do PAC estiver desabilitada ou não for necessária, o serviço que autentica o cliente não precisará fazer uma chamada RPC ao controlador de domínio (consulte o artigo sobre atraso no processo de autenticação de usuário ao executar um programa de servidor de alto volume em um membro do domínio no Windows 2000 ou no Windows Server 2003). A autenticação Kerberos também exige menos tráfego entre o cliente e o servidor em comparação ao NTLM. Os clientes podem ser autenticados em servidores Web em duas solicitações/respostas, em contraste com o típico handshake de três etapas com o NTLM. No entanto, essa melhoria geralmente não é observada em redes de baixa latência em cada transação, mas normalmente pode ser observada em termos da produtividade geral do sistema. Lembre-se de que muitos fatores ambientais podem afetar o desempenho da autenticação e, portanto, antes de determinar se o desempenho de um dos métodos é melhor que o outro, você deve testar o desempenho da autenticação Kerberos e do NTLM no seu próprio ambiente.

Esta é uma lista incompleta das vantagens do uso do protocolo Kerberos. Há outras razões, como a autenticação mútua, a interoperabilidade entre plataformas e a confiança transitiva entre domínios, para citar apenas algumas. No entanto, na maioria dos casos, normalmente a delegação e a segurança são consideradas as principais razões para a adoção do protocolo Kerberos.

Delegação de Kerberos, delegação restrita e transição de protocolo

O protocolo Kerberos versão 5 na plataforma Windows dá suporte a dois tipos de delegação de identidade, delegação básica (irrestrita) e delegação restrita:

Tipo Vantagens Desvantagens

Delegação básica

  • Pode cruzar os limites de domínios em uma única floresta

  • Requer menos configuração que a delegação restrita.

  • Não dá suporte à transição de protocolo

  • Segura. Se o serviço front-end ficar comprometido, a identidade do cliente poderá ser delegada a qualquer serviço na floresta que aceite a autenticação Kerberos.

Delegação restrita

  • Pode fazer a transição do protocolo de autenticação de entrada não Kerberos para Kerberos (exemplo: NTLM para Kerberos, Declarações para Kerberos)

  • Mais segura. As identidades só podem ser delegadas para o serviço especificado.

  • Não pode cruzar limites de domínios

  • Requer configuração adicional

Os serviços com Kerberos habilitado podem delegar a identidade várias vezes através de diversos serviços e vários saltos. À medida que a identidade viaja de serviço para serviço, o método de delegação pode ser alterado de Básico para Restrito, mas não o inverso. Esse é um detalhe importante a ser entendido sobre o design: se um serviço back-end exigir a delegação Básica (por exemplo, para delegar através de um limite de domínio), todos os serviços que utilizarem o serviço back-end deverão usar a delegação básica. Se qualquer serviço front-end usar a delegação restrita, o serviço back-end não poderá trocar o token restrito por um token irrestrito para cruzar um limite de domínio.

A transição de protocolo permite que um serviço de autenticação com Kerberos habilitado (serviço front-end) converta uma identidade não Kerberos em uma identidade Kerberos que poderá ser delegada a outros serviços com Kerberos habilitado (serviço back-end). A transição de protocolo requer a delegação restrita de Kerberos e, assim, identidades com transição de protocolo não podem cruzar limites de domínio. Dependendo dos direitos de usuário do serviço front-end, o tíquete Kerberos retornado pela transição de protocolo poderá ser um token de identificação ou de representação. Para obter mais informações sobre a delegação restrita e a transição de protocolo, consulte os seguintes artigos:

Como prática recomendada geral, se a delegação Kerberos for necessária, a delegação restrita deverá ser usada, caso possível. Se a delegação entre limites do domínio for necessária, todos os serviços no caminho de delegação deverão usar a delegação básica.

Alterações na autenticação Kerberos no Windows 2008 R2 e no Windows 7

O Windows Server 2008 R2 e o Windows 7 apresentam novos recursos para a autenticação Kerberos. Para obter uma visão geral das alterações, consulte os artigos sobre alterações na autenticação Kerberos (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x416) e aprimoramentos do Kerberos (https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x416). Além disso, você deve familiarizar-se com a autenticação de modo kernel do IIS 7.0 (configurações da autenticação de modo kernel do IIS (Serviços de Informações da Internet) 7.0, (https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x416)), embora não haja suporte para ela em farms do SharePoint Server.

Alterações na configuração Kerberos nos Produtos do SharePoint 2010

A maioria dos conceitos básicos de configuração de autenticação Kerberos em Produtos do SharePoint 2010 não foi alterada. Você ainda precisa configurar nomes de entidades de serviço e definir configurações de delegação em contas de serviço e de computador. No entanto, há várias alterações das quais você precisa estar ciente:

  • Delegação Restrita — necessária para serviços que utilizam o Serviço de Tokens de Declarações para Tokens do Windows. A delegação restrita é necessária para permitir que a transição de protocolo converta tokens de declarações em tokens do Windows.

  • Aplicativos de Serviço — no Office SharePoint Server 2007, os serviços SSP exigiam SPNs especiais e alterações no Registro do servidor para habilitar a delegação. No Produtos do SharePoint 2010, os aplicativos de serviços usam a autenticação de declarações e o Serviço de Tokens de Declarações para Tokens do Windows e, portanto, essas alterações não são mais necessárias.

  • Windows Identity Foundation (WIF) — o C2WTS (Serviço de Tokens de Declarações para Tokens do Windows) do WIF é um serviço inédito utilizado pelo Produtos do SharePoint 2010 para converter tokens de declarações em tokens do Windows para cenários de delegação.

Considerações ao atualizar do Office SharePoint Server 2007

Se você está atualizando um farm do Office SharePoint Server 2007 para o SharePoint Server 2010, há vários itens a considerar ao longo do processo de atualização:

  • Se os aplicativos Web estiverem mudando de URL, atualize os Nomes de Entidade de Serviço de forma a refletir os nomes DNS.

  • Exclua os nomes de entidades de serviço do SSP, pois eles não são mais necessários no SharePoint Server 2010.

  • Inicie o Serviço de Tokens de Declarações para Tokens do Windows nos servidores que estão executando aplicativos de serviço que exigem delegação (por exemplo, Serviços do Excel, Serviço de Gráfico do Visio).

  • Configure a delegação restrita de Kerberos com "usar qualquer protocolo de autenticação" para permitir essa delegação com o C2WTS.

  • Verifique se a autenticação de modo Kernel está desabilitada no IIS.