Problemas conhecidos com a configuração Kerberos (SharePoint Server 2010)

  • Artigo

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Autenticação Kerberos e portas não padrão

Existe um problema conhecido em que alguns clientes Kerberos (.NET Framework, Internet Explorer 7 e 8, inclusive) não formam nomes de entidade de serviço corretamente quando tentam se autenticar em aplicativos Web habilitados para Kerberos que estão configurados em portas não padrão (portas diferentes da 80 e da 443). A raiz do problema está no fato de que o cliente não forma corretamente o SPN na solicitação TGS, ou seja, não o especifica com o número de porta (como visto em Sname da solicitação TGS).

Exemplo:

Se o aplicativo Web estiver sendo executado em http://intranet.contoso.com:1234, o cliente solicitará um tíquete para um serviço com um SPN igual a http/intranet.contoso.com, em vez de http/intranet.contoso.com:1234.

Detalhes sobre o problema podem ser encontrados nos seguintes artigos:

Para solucionar o problema, registre SPNs com e sem o número da porta. Exemplo:

  • http/intranet

  • http/intranet.contoso.com

  • http/intranet:12345

  • http/intranet.contoso.com:12345

É recomendável registrar a porta não padrão para garantir que, se o problema for resolvido em algum service pack ou hotfix futuro, os aplicativos que usam a solução alternativa ainda continuarão a funcionar.

Observe que essa solução alternativa não funcionará se as condições a seguir forem verdadeiras:

  • Existe mais de um aplicativo Web em execução em uma porta não padrão

  • Os aplicativos Web estão associados ao nome do host do servidor ou estão associados ao mesmo cabeçalho de host (em portas diferentes)

  • Os pools de aplicativos do IIS do aplicativo Web usam contas de serviço diferentes

Se essas condições forem verdadeiras e você seguir a recomendação da solução alternativa, SPNs duplicados serão registrados em diferentes contas de serviço, o que interromperá a autenticação Kerberos.

Se vários sites que compartilham um nome de host comum estiverem em execução em várias portas, e você usar identidades diferentes de pool de aplicativos do IIS para os aplicativos Web, não será possível usar a autenticação Kerberos em todos os sites. Um aplicativo pode usar Kerberos, mas os outros exigirão um protocolo de autenticação diferente. Para usar o Kerberos em todos os aplicativos nesse cenário, será necessário seguir uma destas ações:

  1. Executar todos os aplicativos Web em uma conta de serviço compartilhada

  2. Executar cada site com seu próprio cabeçalho de host

Autenticação Kerberos e CNAMEs DNS

Existe um problema conhecido com alguns clientes Kerberos (Internet Explorer 7 e 8, inclusive) que tentam se autenticar em serviços habilitados para Kerberos que estão configurados para resolução com o uso de CNAMEs DNS em vez de Registros A. A raiz do problema é o que o cliente não forma corretamente o SPN na solicitação TGS, ou seja, não o cria usando o nome do host (Registro A) no lugar do nome de alias (CNAME).

Exemplo:

Registro A: wfe01.contoso.com

CNAME: intranet.contoso.com (aliases wfe01.contoso.com)

Se o cliente tentar se autenticar em http://intranet.contoso.com, ele não formará corretamente o SPN e solicitará um tíquete Kerberos para http/wfe01.contoso.com, em vez de para http/intranet.contoso.com

Detalhes sobre o problema podem ser encontrados nos seguintes artigos:

https://support.microsoft.com/kb/911149/pt-br

https://support.microsoft.com/kb/938305/pt-br/pt-br

Para solucionar esse problema, configure serviços habilitados para Kerberos usando registros A DNS em vez de aliases CNAME. O hotfix mencionado no artigo da base de dados corrigirá esse problema para o Internet Explorer, mas não para o .NET Framework (que é usado pelo Microsoft Office SharePoint Server para comunicação com serviços Web).

Autenticação Kerberos e autenticação no modo kernel

Observação

A autenticação no modo kernel não tem suporte nos Produtos do SharePoint 2010 e é especificada para fins meramente informativos.

Começando pelo IIS 7.0, existe um novo recurso de autenticação chamado modo kernel. Quando um site do IIS é configurado para usar a autenticação no modo kernel, HTTP.sys faz a autenticação das solicitações do cliente, e não do processo de trabalho do pool de aplicativos. A execução de HTTP.sys no modo kernel melhora o desempenho, mas também introduz um pouco de complexidade quando se trata de configurar o Kerberos. Isso acontece porque HTTP.sys é executado com a identidade do computador, e não com a identidade do processo de trabalho. Quando HTTP.sys recebe um tíquete Kerberos, ele tenta, por padrão, descriptografar esse tíquete com a chave de criptografia do servidor (também conhecida como segredo), e não com a chave da identidade do processo de trabalho no qual ele está sendo executado.

Se um único servidor Web estiver configurado para usar a autenticação no modo kernel, o Kerberos funcionará sem configuração adicional ou sem SPNs adicionais, já que o servidor registrará automaticamente um SPN HOST quando for adicionado ao domínio. Se houver vários servidores Web com balanceamento de carga, a configuração da autenticação no modo kernel padrão não funcionará ou, pelo menos, falhará de forma intermitente, pois o cliente não tem como verificar se o tíquete de serviço que ele recebeu na solicitação TGS funcionará com o servidor que está efetuando a autenticação da solicitação.

Para solucionar esse problema, faça o seguinte:

Autenticação Kerberos e autenticação baseada em sessão

Talvez você perceba um aumento no tráfego de autenticação ao usar a autenticação Kerberos com o IIS 7.0 e versões posteriores. Isso pode ter relação com as configurações de autenticação do Windows no IIS, em particular:

AuthPersistNonNTLM

Atributo booliano opcional.

Especifica se o IIS efetua automaticamente uma nova autenticação em cada solicitação não NTLM (por exemplo, Kerberos), mesmo naquelas que fazem parte da mesma conexão. O valor True habilita várias autenticações para as mesmas conexões.

O padrão é False.

Observação

Uma configuração False significa que o cliente será autenticado somente uma vez na mesma conexão. O IIS armazenará em cache um token ou tíquete no servidor para uma sessão TCP que permanece estabelecida.

authPersistSingleRequest

Atributo booliano opcional.

Quando esse sinalizador é configurado como True, ele especifica que a autenticação persiste somente para uma única solicitação em uma conexão. O IIS redefine a autenticação ao final de cada solicitação e força uma nova autenticação na próxima solicitação da sessão.

O valor padrão é False.

Para obter instruções de como configurar a persistência de autenticação no IIS 7.0, consulte o artigo que explica uma possível lentidão de desempenho quando a autenticação integrada do Windows é usada junto com o protocolo de autenticação Kerberos no IIS 7.0 e o artigo sobre a implementação do controle de acesso.

Autenticação Kerberos e problemas com SPNs duplicados/ausentes

Ao configurar a autenticação Kerberos, é fácil configurar acidentalmente nomes de entidade de serviço duplicados, especialmente quando você usa SetSPN -A ou a ferramenta Editor ADSI (adsiedit.msc) para criar SPNs. A recomendação geral é usar SetSPN -S para criar SPNs, porque a opção -S verifica se existe algum SPN duplicado antes de criar o SPN especificado.

Se você suspeita da existência de SPNs duplicados no seu ambiente, use o comando SetSPN -X para consultar todos os SPNs duplicados no ambiente (somente Windows 2008 ou superior). Se algum SPN for retornado, investigue por que os SPNs foram registrados e exclua as duplicatas desnecessárias. Se houver dois serviços executando duas identidades diferentes e ambos usarem o mesmo SPN (problema de SPN duplicado), será necessário reconfigurar um deles para usar um SPN diferente ou compartilhar uma identidade de serviço comum.

Se você suspeita de que um SPN não tenha sido registrado, ou não tenha sido registrado no devido formato, poderá usar o SetSPN -Q <insert SPN> para consultar sobre a existência de um determinado SPN.

Tamanho máximo de token Kerberos

Em alguns ambientes, os usuários podem ser membros de vários grupos do Active Directory, o que pode aumentar o tamanho dos tíquetes Kerberos. Se os tíquetes aumentarem muito, a autenticação Kerberos poderá falhar. Para obter mais informações sobre como ajustar o tamanho máximo do token, consulte o artigo sobre a nova resolução de problemas com a autenticação Kerberos quando os usuários pertencem a vários grupos (https://support.microsoft.com/kb/327825/pt-br).

Observação

Lembre-se de que, se você ajustar o tamanho máximo do token além do valor máximo da configuração do Registro, poderá ver erros na autenticação Kerberos. Convém não exceder o decimal 65535, hexadecimal FFFF, para o tamanho máximo do token.

Hotfixes de autenticação Kerberos para Windows Server 2008 e Windows Vista

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).

Convém instalar um hotfix para autenticação Kerberos em todos os computadores que executam o Windows Server 2008 ou o Windows Vista no seu ambiente. Isso inclui todos os computadores que executam o SharePoint Server 2010, o SQL Server ou o Windows Server 2008 nos quais o SharePoint Server se autenticar usando a autenticação Kerberos. Siga as instruções na página de suporte para aplicar o hotfix caso você se depare com os sintomas documentados nesse caso de suporte.