Configurando a autenticação Kerberos: configuração principal (SharePoint Server 2010)
Aplica-se a: SharePoint Server 2010
Tópico modificado em: 2017-01-18
No primeiro cenário, você irá configurar dois aplicativos Web do SharePoint Server 2010 de forma que eles usem o protocolo Kerberos para a autenticação de solicitações de cliente de entrada. Para fins de demonstração, um dos aplicativos Web será configurado para usar portas padrão (80/443), e o outro usará uma porta não padrão (5555). Esse cenário será a base de todos os cenários seguintes, que irão supor que as atividades abaixo foram concluídas.
Importante
É necessário configurar os aplicativos Web com a autenticação do Windows clássica usando a autenticação Kerberos para garantir que os cenários funcionem conforme esperado. A autenticação de Declarações do Windows pode ser usada em alguns cenários, mas talvez não gere os resultados detalhados nos cenários a seguir.
Observação
Se a instalação estiver sendo feita no Windows Server 2008, talvez seja necessário instalar o seguinte hotfix para a autenticação Kerberos:
Uma autenticação Kerberos falha com o código de erro 0X80090302 ou 0x8009030f em um computador que está executando o Windows Server 2008 ou Windows Vista quando o algoritmo AES é usado (https://support.microsoft.com/kb/969083/pt-br)
Neste cenário, você desempenha as seguintes ações:
Configurar dois aplicativos Web com zonas padrão que usam o protocolo Kerberos para autenticação
Criar dois conjuntos de sites de teste, um em cada aplicativo Web
Verificar a configuração do IIS do aplicativo Web
Verificar se os clientes podem se autenticar no aplicativo Web e garantir que o protocolo Kerberos esteja sendo usado para autenticação
Configurar a Web Part Visualizador RSS para exibir RSS feeds em um aplicativo local e em um remoto
Rastrear cada aplicativo Web e testar a pesquisa de conteúdo em cada conjunto de sites de teste
Lista de verificação para configuração
| Área de configuração | Descrição |
|---|---|
DNS |
Registrar um Registro DNS A para os aplicativos Web com IP virtual (VIP) e balanceamento de carga de rede (NLB) |
Active Directory |
Criar contas de serviço para o pool de aplicativos do IIS nos aplicativos Web Registrar SPNs (Nomes de Entidade de Serviço) para os aplicativos Web na conta de serviço criada para o pool de aplicativos do IIS do aplicativo Web Configurar a delegação restrita de Kerberos para contas de serviço |
SharePoint Web App |
Criar contas gerenciadas do SharePoint Server Criar o Aplicativo de Serviço de Pesquisa do SharePoint Criar os aplicativos Web do SharePoint |
IIS |
Validar se a autenticação Kerberos está Habilitada Verificar se a autenticação de modo Kernel está desabilitada Instalar certificados para SSL |
Cliente Windows 7 |
Verificar se as URLs do aplicativo Web estão na zona de intranet ou em uma zona configurada para autenticação automática com a autenticação do Windows integrada |
Configuração do firewall |
Abrir portas do firewall para permitir o tráfego HTTP de entrada em portas padrão e não padrão Verificar se os clientes podem se conectar a Portas Kerberos no Active Directory |
Testar a autenticação do navegador |
Verificar se a autenticação funciona corretamente no navegador Verificar as informações de logon no log de eventos do servidor Web Usar ferramentas de terceiros para confirmar se a autenticação Kerberos foi configurada corretamente |
Testar Índice de Pesquisa e Consulta do SharePoint Server |
Verificar o acesso do navegador dos servidores de indexação Carregar conteúdo de exemplo e executar um rastreamento Testar a pesquisa |
Testar a delegação WFE |
Configurar origens de RSS feed em todos os conjuntos de sites Adicionar Web Parts de exibição RSS à home page de cada conjunto de sites |
Instruções de configuração passo a passo
Configurar o DNS
Configure o DNS para os aplicativos Web no seu ambiente. Neste exemplo, temos dois aplicativos Web, http://portal e http://teams:5555, e ambos são resolvidos para o mesmo VIP de NLB (192.168.24.140/24)
Para obter informações gerais sobre como configurar o DNS, consulte o artigo sobre Gerenciamento de registros de DNS.
SharePoint Server Web Apps
http://portal — configure um novo Registro DNS A para o aplicativo Web de portal. Neste exemplo, temos um host "portal" configurado para ser resolvido para o VIP com balanceamento de carga.
.jpg "Imagem do registro DNS")
http://teams:5555 — configure um novo Registro DNS A para o aplicativo Web da equipe
.jpg "Imagem do registro DNS")
Observação
É importante garantir que as entradas de DNS sejam Registros A, e não aliases CNAME, para que a autenticação Kerberos funcione com êxito em ambientes que possuem mais de um aplicativo Web em execução com cabeçalhos de host e contas de serviço dedicadas separadas. Consulte Problemas conhecidos com a configuração Kerberos (SharePoint Server 2010) para obter uma explicação sobre o problema conhecido de usar CNAME com aplicativos Web habilitados para Kerberos.
Configurar o Active Directory
Em seguida, você irá configurar as contas do Active Directory para os aplicativos Web do seu ambiente. Como prática recomendada, você deve configurar cada aplicativo Web para ser executado no seu próprio pool de aplicativos do IIS com seu próprio contexto de segurança (identidade do pool de aplicativos).
Contas de Serviço do Aplicativo de Serviço do SharePoint
No nosso exemplo, temos dois aplicativos Web do SharePoint Server em execução em dois pools de aplicativos do IIS separados que são executados com suas próprias identidades de pool de aplicativos.
| Aplicativo Web (zona padrão) | Identidade do Pool de Aplicativos do IIS |
|---|---|
vmlab\svcPortal10App |
|
vmlab\ svcTeams10App |
Nomes de Entidade de Serviço (SPNs)
Para cada conta de serviço, configure um conjunto de nomes de entidade de serviço que sejam mapeados para nomes de host DNS atribuídos a cada aplicativo Web.
Use SetSPN, uma ferramenta de linha de comando do Windows Server 2008, para configurar um novo nome de entidade de serviço. Para obter uma explicação completa de como usar SetSPN, consulte o artigo sobre Setspn. Para saber mais sobre os aprimoramentos de SetSPN no Windows Server 2008, consulte o artigo sobre novos recursos de SETSPN.EXE no Windows Server 2008.
Todos os aplicativos Web do SharePoint Server, independentemente do número da porta, usam o seguinte formato de SPN:
HTTP/<nome do HOST DNS>
HTTP/<FQDN DNS>
Exemplo:
HTTP/portal
HTTP/portal.vmlab.local
Para aplicativos Web em execução em portas não padrão (portas diferentes de 80/443), registre SPNs adicionais com o número da porta:
HTTP/<Nome do Host DNS>:<porta>
HTTP/<FQDN DNS>:<porta>
Exemplo:
HTTP/teams:5555
HTTP/teams.vmlab.local:5555
Observação
Consulte o apêndice para obter uma explicação de por que é recomendável configurar SPNs com e sem número de porta para serviços HTTP em execução em portas não padrão (80, 443). Tecnicamente, a maneira correta de fazer referência a um serviço HTTP executado em uma porta não padrão é incluir o número da porta no SPN, mas, por causa de problemas conhecidos descritos no apêndice, também precisamos configurar SPNs sem a porta. Observe que ter SPNs sem porta para o aplicativo Web teams não significa que os serviços serão acessados com o uso das portas padrão (80, 443) no nosso exemplo.
No nosso exemplo, configuramos os nomes de entidade de serviço a seguir para as duas contas criadas na etapa anterior:
| Host DNS | Identidade do Pool de Aplicativos do IIS | Nomes de Entidade de Serviço |
|---|---|---|
Portal.vmlab.local |
vmlab\svcPortal10App |
HTTP/portal HTTP/portal.vmlab.local |
Teams.vmlab.local |
vmlab\ svcTeams10App |
HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Para criar os nomes de entidade de serviço, foram executados os seguintes comandos:
SetSPN -S HTTP/Portal vmlab\svcportal10App
SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App
SetSPN -S HTTP/Teams vmlab\svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App
SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App
Importante
Não configure nomes de entidade de serviço com HTTPS, mesmo que o aplicativo Web use SSL.
No nosso exemplo, usamos uma nova opção de linha de comando, -S, introduzida no Windows Server 2008 e que verifica a existência do SPN antes da sua criação na conta. Se o SPN já existir, o novo SPN não será criado, e você verá uma mensagem de erro.
Se forem encontrados SPNs duplicados, será necessário resolver o problema usando um nome DNS diferente para o aplicativo Web, o que implica alterar o SPN, ou removendo o SPN existente da conta em que ele foi descoberto.
Importante
Antes de excluir um SPN existente, verifique se ele não é mais necessário. Caso contrário você poderá interromper a autenticação Kerberos para outro aplicativo no seu ambiente.
Nomes de Entidade de Serviço e SSL
É comum confundir Nomes de Entidade de Serviço com URLs para aplicativos Web http, pois a sintaxe dos formatos de SPN e URI são muito semelhantes. Porém, é importante compreender que eles são duas coisas bastante separadas e exclusivas. Nomes de entidade de serviço Kerberos são usados para identificar um serviço e, quando esse serviço for um aplicativo http, seu esquema será "HTTP", independentemente de ele ser acessado com SSL ou não. Isso significa que, mesmo acessando o aplicativo Web com o uso de "https://aplicativo", você não precisa, nem deve, configurar um nome de entidade de serviço com HTTPS, por exemplo "HTTPS/aplicativo".
Configurar a delegação restrita de Kerberos para computadores e contas de serviço
Dependendo do cenário, uma parte da funcionalidade do SharePoint Server 2010 pode exigir a delegação restrita para funcionar corretamente. Por exemplo, se a Web Part Visualizador RSS for configurada para mostrar um RSS feed de uma origem autenticada, ela exigirá delegação para consumir o feed de origem. Em outras situações, pode ser necessário configurar a delegação restrita para permitir que aplicativos de serviço (como os Serviços do Excel) deleguem a identidade do cliente a sistemas de back-end.
Neste cenário, configuramos a delegação restrita de Kerberos para permitir que a Web Part Visualizador RSS leia um RSS feed local protegido e um RSS feed remoto de um aplicativo Web remoto. Em cenários posteriores, vamos configurar a delegação restrita de Kerberos para outros aplicativos de serviço do SharePoint Server 2010.
O diagrama a seguir descreve conceitualmente o que será configurado neste cenário:
.jpg "Diagrama de cenário")
Temos dois aplicativos Web, cada um com o seu próprio conjunto de sites contendo uma página de site que hospeda duas Web Parts Visualizador RSS. Cada aplicativo Web tem uma única zona padrão configurada para usar a autenticação Kerberos e, portanto, todos os feeds provenientes desses sites exigirão autenticação. Em cada site, um visualizador RSS será configurado para ler um RSS feed local de uma lista, e o outro será configurado para ler um feed de autenticação no site remoto.
Para realizar isso, a delegação restrita de Kerberos será configurada para permitir a delegação entre as contas de serviço do pool de aplicativos do IIS. O diagrama a seguir descreve conceitualmente os caminhos necessários para a delegação restrita:
.jpg "Diagrama de delegação de pool de aplicativos")
Lembre-se de que identificamos o aplicativo Web com base no nome do serviço usando o SPN (Nome de Entidade de Serviço) atribuído à identidade do pool de aplicativos do IIS. As contas de serviço que processam solicitações devem ter permissão para delegar a identidade de cliente aos serviços designados. Ao todo, temos os seguintes caminhos de delegação restrita para configurar:
| Tipo de Entidade de Segurança | Nome da Entidade de Segurança | Delegada ao Serviço |
|---|---|---|
Usuário |
svcPortal10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Usuário |
svcTeams10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Observação
Pode parecer redundante configurar a delegação de um serviço para ele mesmo, como no caso da delegação da conta de serviço de portal para o aplicativo de serviço de portal, mas isso é necessário em cenários em que existem vários servidores executando o serviço. Essa configuração deve ser usada no cenário em que um servidor talvez precise delegar para outro servidor que executa o mesmo serviço, como no caso de um WFE processando uma solicitação com um visualizador RSS que utiliza o aplicativo Web local como fonte de dados. Dependendo da topologia e da configuração do farm, existe a possibilidade de que a solicitação RSS seja fornecida por um servidor diferente, o que exigiria que a delegação funcionasse corretamente.
Para configurar a delegação, você pode usar o snap-in Usuários e Computadores do Active Directory. Clique com o botão direito do mouse em cada conta de serviço e abra a caixa de diálogo de propriedades. Nessa caixa de diálogo, você verá uma guia para delegação (observe que essa guia só aparecerá se o objeto tiver um SPN atribuído; computadores possuem um SPN por padrão). Na guia de delegação, selecione Confiar neste usuário para delegação apenas aos serviços especificados e depois selecione Usar qualquer protocolo de autenticação.
Clique no botão Adicionar para adicionar os serviços aos quais o usuário (a conta de serviço) poderá delegar. Para selecionar um SPN, procure o objeto ao qual o SPN está aplicado. No nosso exemplo, estamos tentando delegar a um serviço HTTP, o que significa que precisamos procurar a conta de serviço do pool de aplicativos do ISS à qual o SPN foi atribuído na etapa anterior.
Na caixa de diálogo Selecionar Usuários ou Computadores, clique em Usuários e Computadores, procure as contas de serviço do pool de aplicativos do IIS (no nosso exemplo, vmlab\svcPortal10App e vmlab\svcTeams10App) e clique em OK.
Será solicitado que você selecione os serviços atribuídos aos objetos com base no nome da entidade de serviço.
Na caixa de diálogo Adicionar Serviços, clique em Selecionar Tudo e depois em OK. Observe que, ao retornar para a caixa de diálogo de delegação, você não verá todos os SPNs selecionados. Para ver todos os SPNs, marque a caixa de seleção Expandidos no canto inferior esquerdo.
Execute estas etapas para cada conta de serviço no seu ambiente que exige delegação. Nosso exemplo utiliza a lista de contas de serviço.
Configurar o SharePoint Server
Após a configuração do Active Directory e do DNS, é hora de criar o aplicativo Web no seu Farm do SharePoint Server 2010. Este documento supõe que a instalação do SharePoint Server já esteja concluída e que a topologia do farm e a infraestrutura de suporte (por exemplo, o balanceamento de carga) estejam configuradas. Para obter mais informações sobre como instalar e configurar seu farm do SharePoint, consulte o artigo sobre implantação para o SharePoint Server 2010.
Configurar contas de serviço gerenciadas
Antes de criar seus aplicativos Web, configure as contas de serviço criadas nas etapas anteriores como contas de serviço gerenciadas no SharePoint Server. Fazer isso antecipadamente permitirá que você ignore essa etapa ao criar os aplicativos Web propriamente ditos.
Para configurar uma conta gerenciada
Na Administração Central do SharePoint, clique emSegurança.
Em Segurança Geral, clique em Configurar contas gerenciadas:
Clique em Registrar Conta Gerenciada e crie uma conta gerenciada para cada conta de serviço. Neste exemplo, criaremos cinco contas de serviço gerenciadas:
Conta Objetivo VMLAB\svcSP10Search
Conta do Serviço de Pesquisa do SharePoint
VMLAB\svcSearchAdmin
Conta do Serviço de Administração de Pesquisa do SharePoint
VMLAB\svcSearchQuery
Conta do Serviço de Consulta do SharePoint
VMLAB\svcPortal10App
Conta do Pool de Aplicativos do IIS do aplicativo Web Portal
VMLAB\svcTeams10App
Conta do Pool de Aplicativos do IIS do aplicativo Web Teams
Observação
Contas gerenciadas no SharePoint Server 2010 não são iguais a contas de serviço gerenciadas no Active Directory do Windows Server 2008 R2.
Criar o Aplicativo de Serviço de Pesquisa do SharePoint Server
Neste exemplo, vamos configurar o Aplicativo de Serviço de Pesquisa do SharePoint Server para garantir que o aplicativo Web recém-criado possa ser rastreado e pesquisado com êxito. Crie um novo Aplicativo Web de Pesquisa do SharePoint Server e coloque os Serviços de Pesquisa, Consulta e Administração no servidor de aplicativos, que é vmSP10App01 no nosso exemplo. Para obter uma explicação detalhada sobre como configurar o Aplicativo de Serviço de Pesquisa, consulte o artigo com instruções passo a passo para provisionar o Aplicativo de Serviço de Pesquisa.
Observação
O posicionamento de todos os Serviços de Pesquisa em um único servidor de aplicativos é feito meramente para fins de demonstração. Uma discussão completa sobre práticas recomendadas e opções de Topologia de Pesquisa do SharePoint Server 2010 está fora do escopo deste documento.
Criar o aplicativo Web
Navegue até a Administração Central e acesse Gerenciar Aplicativos Web na seção Gerenciamento de Aplicativos. Na barra de ferramentas, selecione Novo e crie seu aplicativo Web. Verifique se as configurações a seguir estão definidas:
Selecione Autenticação de Modo Clássico.
Configure a porta e o cabeçalho do host para cada aplicativo Web.
Selecione Negociar como Provedor de Autenticação.
No pool de aplicativos, selecione Criar novo pool de aplicativos e escolha a conta gerenciada criada na etapa anterior.
Neste exemplo, dois aplicativos Web foram criados com as seguintes configurações:
| Configuração | http://Aplicativo Web Portal | http://Aplicativo Web Teams |
|---|---|---|
Autenticação |
Modo Clássico |
Modo Clássico |
Site do IIS |
Nome: SharePoint – Portal – 80 Porta: 80 Cabeçalho do Host: Portal |
Nome: SharePoint – Teams – 5555 Porta: 80 Cabeçalho do Host: Teams |
Configuração de Segurança |
Provedor de Autenticação: Negociar Permitir Anônimo: Não Usar SSL: Não |
Provedor de Autenticação: Negociar Permitir Anônimo: Não Usar SSL: Não |
URL Pública |
http://Portal:80 |
http://Teams:5555 |
Pool de Aplicativos |
Nome: SharePoint – Portal80 Conta de Segurança: vmlab\svcPortal10App |
Nome: SharePoint – Teams5555 Conta de Segurança: vmlab\svcTeams10App |
Ao criar o novo aplicativo Web, você também cria uma nova zona, a zona padrão, configurada para usar o provedor de autenticação do Windows. Para ver o provedor e suas configurações para a zona no gerenciamento de aplicativos Web, primeiro selecione o aplicativo Web e depois clique em Provedores de Autenticação na barra de ferramentas. A caixa de diálogo de provedores de autenticação lista todas as zonas do aplicativo Web selecionado, juntamente com o provedor de autenticação de cada zona. Ao selecionar a zona, você verá as opções de autenticação correspondentes.
Se você tiver definido incorretamente as configurações do Windows e tiver selecionado NTLM quando o aplicativo Web foi criado, poderá usar a caixa de diálogo Editar Autenticação da zona para substituir NTLM por Negociar. Se o modo clássico não tiver sido selecionado como o modo de autenticação, você precisará ou criar uma nova zona estendendo o aplicativo Web para um novo site do IIS, ou excluir e recriar o aplicativo Web.
Criar conjuntos de sites
Para testar se a autenticação está funcionando corretamente, será necessário criar pelo menos um conjunto de sites em cada aplicativo Web. Como o processo de criação e configuração do conjunto de sites não afetará a funcionalidade Kerberos, siga as orientações existentes sobre como criar um conjunto de sites no artigo que explica como criar um conjunto de sites (SharePoint Foundation 2010).
Para este exemplo, dois conjuntos de sites foram configurados:
| Aplicativo Web | Caminho do Conjunto de Sites | Modelo do Conjunto de Sites |
|---|---|---|
http://portal |
/ |
Portal de Publicação |
http://teams:5555 |
/ |
Site de Equipe |
Criar mapeamentos alternativos de acesso
O aplicativo Web de portal será configurado para usar HTTP e HTTPS, para demonstrar como a delegação funciona com serviços protegidos por SSL. Para configurar o SSL, o aplicativo Web de portal necessitará de um segundo AAM (mapeamento alternativo de acesso) do SharePoint Server para o ponto de extremidade HTTPS.
Para configurar mapeamentos alternativos de acesso
Na Administração Central, clique em Gerenciamento de Aplicativos.
Em Aplicativos Web, clique em Configurar mapeamentos alternativos de acesso.
Na caixa suspensa Selecionar Conjunto de Mapeamentos Alternativos de Acesso, escolha Alterar Conjunto de Mapeamentos Alternativos de Acesso.
Selecione o aplicativo Web de portal.
Clique em Editar Urls Públicas na barra de ferramentas superior.
Em uma zona livre, adicione a URL https para o aplicativo Web. Essa URL será o nome do certificado SSL que você criará nas próximas etapas.
Clique em Salvar.
Você verá a URL HTTPS na lista de zonas para o aplicativo Web.
Configuração do IIS
Instalar certificados SSL
Será preciso configurar um certificado SSL em cada instância do SharePoint Server que hospeda o serviço de aplicativo Web para todos os aplicativos Web que usam SSL. Novamente, o tópico sobre como configurar um certificado SSL e a confiança de certificados está fora do escopo deste documento. Consulte a seção Configuração SSL neste documento para ver referências a materiais sobre a configuração de certificados SSL no IIS.
Verificar se a autenticação Kerberos está habilitada
Para verificar se a autenticação Kerberos está habilitada no site
Abra o gerenciador do IIS.
Selecione o site do IIS a ser verificado.
Em Exibição de Recursos, no IIS, clique duas vezes em Autenticação.
Selecione a opção Autenticação do Windows, que deve estar habilitada.
No lado direto, em Ações, selecione Provedores. Verifique se Negociar está no topo da lista.
Verificar se a autenticação de modo Kernel está desabilitada
A autenticação de modo Kernel não tem suporte no SharePoint Server 2010. Por padrão, todos os Aplicativos Web do SharePoint Server devem ter a Autenticação de Modo Kernel desabilitada em seus sites do IIS correspondentes. Mesmo em situações nas quais o aplicativo Web foi configurado em um site do IIS existente, o SharePoint Server desabilita a autenticação de modo Kernel, já que provisiona um novo aplicativo Web no site do IIS existente.
Para verificar se a autenticação de modo kernel está desabilitada
Abra o gerenciador do IIS.
Selecione o site do IIS a ser verificado.
Em Exibição de Recursos, no IIS, clique duas vezes em Autenticação.
Selecione a opção Autenticação do Windows, que deve estar habilitada.
Clique em Configurações Avançadas.
Verifique se as opções de Autenticação EAP e de Modo Kernel estão desabilitadas.
Configurar o firewall
Antes de testar a autenticação, verifique se os clientes podem acessar os aplicativos Web do SharePoint Server nas portas HTTP configuradas. Além disso, verifique se esses clientes podem se autenticar no Active Directory e solicitar tíquetes Kerberos do KDC nas portas Kerberos padrão.
Abrir portas do firewall para permitir o tráfego HTTP de entrada em portas padrão e não padrão
Normalmente, você precisa configurar o firewall em cada servidor Web front-end para permitir solicitações nas portas TCP 80 e TCP 443. Abra o Firewall do Windows com Segurança Avançada e navegue até as seguintes Regras de Entrada:
Serviços World Wide Web (Tráfego de Entrada HTTP)
Serviços World Wide Web (Tráfego de Entrada HTTPS)
Verifique se as portas apropriadas estão abertas no seu ambiente. No nosso exemplo, acessamos o SharePoint Server via HTTP (porta 80) e, portanto, esta regra foi habilitada.
Além disso, temos que abrir a porta não padrão usada no nosso exemplo (TCP 5555). Se você tiver sites em execução em portas não padrão, também precisará configurar regras personalizadas para permitir o tráfego HTTP nessas portas.
Verificar se os clientes conseguem se conectar a portas Kerberos na função Active Directory
Para usar a autenticação Kerberos, os clientes terão de solicitar TGT (tíquetes de concessão de tíquete) e ST (tíquetes de serviço) no KDC (Centro de Distribuição de Chaves) através da porta UDP ou TCP 88. Por padrão, quando você instala a Função Active Directory no Windows Server 2008 ou posterior, ela irá configurar as seguintes regras de entrada para permitir essa comunicação:
Centro de Distribuição de Chaves Kerberos – PCR (Entrada de TCP)
Centro de Distribuição de Chaves Kerberos – PCR (Entrada de UDP)
Centro de Distribuição de Chaves Kerberos (Entrada de TCP)
Centro de Distribuição de Chaves Kerberos (Entrada de UDP)
No seu ambiente, verifique se essas regras estão habilitadas e se os clientes podem se conectar ao KDC (controlador de domínio) na porta 88.
Testar a autenticação no navegador
Depois de configurar o Active Directory, o DNS e o SharePoint Server, teste se a autenticação Kerberos está configurada corretamente navegando até os seus aplicativos Web. Durante o teste no navegador, verifique se as seguintes condições foram atendidas:
O usuário de teste está conectado a um computador com Windows XP, Vista ou Windows 7 associado a um domínio em que o SharePoint está instalado ou está conectado a um domínio de confiança para o domínio do SharePoint Server.
O usuário de teste está usando o Internet Explorer 7.0 ou posterior (o Internet Explorer 6.0 não tem mais suporte no SharePoint Server 2010; consulte o artigo sobre planejamento do suporte para navegadores (SharePoint Server 2010)).
A autenticação integrada do Windows está habilitada no navegador. Em Opções da Internet, na guia Avançado, verifique se a opção Habilitar a Autenticação Integrada do Windows* está habilitada na seção Segurança:
A intranet local está configurada para fazer o logon automático dos clientes. Em Opções da Internet do Explorer, na guia Segurança, selecione Intranet Local e clique no botão Nível personalizado. Role para baixo e verifique se a opção Logon automático somente na zona da intranet está selecionada.
Observação
É possível configurar o logon automático em outras zonas, mas o tópico sobre práticas recomendadas de zonas de segurança do IE está fora do escopo deste documento. Para esta demonstração, a zona da intranet será usada para todos os testes.
Verifique se a opção Detectar automaticamente a rede intranet está selecionada em Opções da Internet->Segurança->Zona da Intranet->Sites.
Se você estiver usando nomes de domínio totalmente qualificados para acessar os aplicativos Web do SharePoint, verifique se os FQDNs estão incluídos na zona da intranet, explicitamente ou por inclusão de caractere curinga (por exemplo, "*.vmlab.local").
A maneira mais fácil de determinar se a autenticação Kerberos está sendo usada é fazendo logon em uma estação de trabalho de teste e navegando até o site em questão. Se não forem solicitadas as credenciais do usuário e se o site for renderizado corretamente, será possível concluir que a autenticação Integrada do Windows está funcionando. A próxima etapa será determinar se o protocolo de negociação foi usado para negociar a autenticação Kerberos como o provedor de autenticação para a solicitação. As permissões podem ser configuradas das seguintes maneiras:
Logs de segurança do servidor Web front-end
Se a autenticação Kerberos estiver funcionando corretamente, você verá eventos de Logon nos logs de eventos de segurança dos servidores Web front-end com a ID do evento = 4624. Nas informações gerais desses eventos, você verá a ID de segurança registrada no computador e o Processo de Logon usado, que deve ser Kerberos.
KList
KList é um utilitário de linha de comando incluído na instalação padrão do Windows Server 2008 e do Windows Server 2008 R2 que pode ser usado para listar e limpar tíquetes Kerberos em um determinado computador. Para executar KLIST, abra um prompt de comando no Windows Server 2008 e digite Klist.
Se quiser limpar o cache de tíquetes, execute Klist com o parâmetro opcional purge: Klist purge
KerbTray
KerbTray é um utilitário gratuito incluído no Windows Server 2000 Resource Kit Tool e que pode ser instalado no computador cliente para a visualização do cache de tíquetes Kerberos. Baixe e instale esse utilitário em Windows 2000 Resource Kit Tool: Kerbtray.exe. Depois de instalá-lo, execute estas ações:
Navegue até os sites que usam a Autenticação Kerberos.
Execute KerbTray.exe.
Exiba o cache de tíquetes Kerberos clicando com o botão direito do mouse no ícone do KerbTray localizado na bandeja do sistema e selecionando Listar Tíquetes.
Valide se os tíquetes de serviço para os aplicativos Web que você autenticou estão na lista de tíquetes armazenados no cache. No nosso exemplo, navegamos até os sites a seguir, que possuem os seguintes SPNs registrados:
URL do Site SPN http://portal
HTTP/Portal.vmlab.local
http://teams:5555
HTTP/Teams.vmlab.local
Fiddler
Fiddler é um analisador de tráfego HTTP gratuito que pode ser baixado neste local: http://www.fiddler2.com/fiddler2/. Nele, você verá o cliente e o servidor negociarem a autenticação Kerberos e poderá ver o cliente enviar os Tíquetes de Serviço Kerberos para o servidor nos cabeçalhos HTTP de cada solicitação. Para validar se a autenticação Kerberos está funcionando corretamente usando o Fiddler, execute estas ações:
Baixe e instale o Fiddler (www.fiddlertool.com) no computador cliente.
Faça logoff do desktop e repita o logon para liberar qualquer conexão em cache com o servidor Web e forçar o navegador a negociar a autenticação Kerberos e a executar o handshake de autenticação.
Inicie o Fiddler.
Abra o Internet Explorer e navegue até o aplicativo Web (http://portal no nosso exemplo).
Você verá as solicitações e respostas ao servidor Web front-end do SharePoint Server no Fiddler.
O primeiro HTTP 401 é a tentativa do navegador de fazer uma solicitação GET sem autenticação. Em resposta, o servidor envia de volta um "HTTP 401 – não autorizado" e, nessa resposta, indica quais são os métodos de autenticação com suporte. Na próxima solicitação, o cliente reenvia a solicitação anterior, mas desta vez envia o tíquete de serviço do aplicativo Web nos cabeçalhos da solicitação. Se for autenticado com êxito, o servidor enviará de volta o recurso solicitado.
NetMon 3.4
NetMon 3.4 é um analisador de pacotes de rede gratuito da Microsoft que pode ser baixado do Centro de Download da Microsoft: Microsoft Network Monitor 3.4.
No NetMon, você vê todas as solicitações e respostas TCP para o KDC e os servidores Web do SharePoint Server, o que possibilita uma visão completa do tráfego que compõe uma solicitação de autenticação. Para validar se a autenticação Kerberos está funcionando com o uso de netmon, execute estas ações:
Baixe e instale o NetMon 3.4 (Microsoft Network Monitor 3.4).
Faça logoff do cliente e repita o logon para liberar o cache de tíquetes Kerberos. Outra opção é usar KerbTray para limpar o cache de tíquetes, clicando com o botão direito do mouse em KerbTray e selecionando Limpar Tíquetes.
Inicie o NetMon no modo de administrador. Clique com o botão direito do mouse no atalho do NetMon e selecione Executar como Administrador.
Inicie uma nova captura nas interfaces que se conectam ao controlador do Active Directory no seu ambiente e aos servidores Web front-end.
Abra o Internet Explorer e navegue até o aplicativo Web.
Após a renderização do site, pare a captura e adicione um filtro de exibição para mostrar os quadros da autenticação Kerberos e do tráfego HTTP.
Na janela de quadros, você verá os tráfegos HTTP e KerberosV5.
Testar a autenticação Kerberos via SSL
Para demonstrar claramente os SPNs solicitados quando um cliente acessa um recurso protegido por SSL, você pode usar uma ferramenta como o netmon para capturar o tráfego entre o cliente e o servidor e examinar as solicitações de tíquete do serviço Kerberos.
Faça logoff e repita o logon no computador cliente, ou limpe todos os tíquetes Kerberos armazenados em cache usando KerbTray.
Inicie uma nova captura do NetMon no computador cliente. Não se esqueça de iniciar o NetMon com permissões de administrador.
Navegue até o aplicativo Web usando SSL (neste exemplo, https://portal).
Pare a captura do NetMon e examine o tráfego KerberosV5. Para obter instruções sobre como filtrar a exibição da captura, consulte a seção NetMon 3.4 deste artigo.
Procure a solicitação TGS enviada pelo cliente. Nessa solicitação, você verá o SPN solicitado no parâmetro "Sname".
Observe que "Sname" é HTTP/portal.vmlab.local, e não HTTPS/portal.vmlab.local.
Testar a Consulta e o Índice de Pesquisa do SharePoint Server
Verificar o acesso ao navegador a partir dos servidores de indexação
Antes de executar um rastreamento, verifique se o servidor de indexação pode acessar os aplicativos Web e se autenticar com êxito. Faça logon no servidor de indexação e abra os conjuntos de sites de teste no navegador. Se os sites forem renderizados com êxito e nenhuma caixa de diálogo de autenticação aparecer, prossiga para a próxima etapa. Se ocorrerem problemas durante o acesso aos sites nos navegadores, volte para as etapas anteriores para garantir que todas as ações de configuração tenham sido executadas corretamente.
Carregar o conteúdo de exemplo e executar um rastreamento
Em cada conjunto de sites, carregue um documento de "propagação" (um documento que seja facilmente identificável na pesquisa) em uma biblioteca de documentos no conjunto de sites. Por exemplo, crie um documento de texto contendo as palavras "alfa, beta, delta" e salve-o na biblioteca de documentos de cada conjunto de sites.
Em seguida, navegue até a Administração Central do SharePoint e inicie um rastreamento completo na fonte de conteúdo Sites Locais do SharePoint (que deve conter os dois conjuntos de sites de teste por padrão).
Testar a pesquisa
Se a indexação for concluída com êxito, você verá itens pesquisáveis no seu índice e nenhum erro no log de rastreamento.
Observação
Se tiver configurado o UPA (Aplicativo de Perfil de Usuário) e estiver executando um rastreamento no repositório de perfis, configure as permissões adequadas no UPA para permitir que a conta de acesso ao conteúdo acesse dados de perfil. Se as permissões do UPA não tiverem sido configuradas, você visualizará erros nos logs de rastreamento, indicando que o rastreador não conseguiu acessar o serviço de perfil porque recebeu um HTTP 401 ao tentar acessar o serviço. O 401 retornado não se deve ao Kerberos, mas sim ao fato que a conta de acesso ao conteúdo não tem permissões para a leitura dos dados de perfil.
Em seguida, navegue até cada conjunto de sites e procure o documento de propagação. A consulta de pesquisa de cada conjunto de sites deve retornar esse documento de propagação carregado.
Testar a delegação no front-end da Web
Como última etapa deste cenário, use a Web Part Visualizador RSS em todos os conjuntos de sites para garantir que a delegação esteja funcionando local e remotamente.
Configurar origens de RSS feed em cada conjunto de sites
Para o aplicativo de portal, você precisa habilitar RSS feeds no Conjunto de Sites. Para ativar RSS feeds, siga as instruções no artigo sobre como gerenciar RSS feeds, no site Office.com.
Depois de habilitar os RSS feeds, crie uma nova lista personalizada e adicione um item de lista para fins de teste. Navegue até o menu da barra de ferramentas Lista e clique em RSS Feed para exibir o RSS feed. Copie a URL do feed para usá-la nas próximas etapas.
Execute esta etapa para cada conjunto de sites.
Adicionar Web Parts de exibição de RSS à home page de cada conjunto de sites
No aplicativo de portal, será necessário habilitar a função de conjunto de sites Recursos do SharePoint Enterprise para usar a Web Part Visualizador RSS. Feito isso, adicione duas Web Parts Visualizador RSS à home page. Para a primeira Web Part, configure a URL do feed de forma que ela aponte para o RSS feed local criado na etapa anterior. Para a segunda Web Part, configure a URL do feed de forma que ela aponte para a URL do feed remoto. Quando terminar, você verá ambas as Web Parts renderizando conteúdo dos RSS feeds local e remoto com êxito.