Problemas com a autenticação kerberos quando um usuário pertence a muitos grupos

Este artigo ajuda você a resolver os problemas de falha de autenticação kerberos quando um usuário pertence a muitos grupos.

Aplica-se ao: Windows 10 - todas as edições, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Número de KB original: 327825

Sintomas

Um usuário que pertence a um grande número de grupos de segurança tem problemas de autenticação. Ao autenticar, o usuário pode ver uma mensagem como HTTP 400 – Solicitação Incorreta (Cabeçalho de Solicitação por muito tempo). O usuário também tem problemas para acessar recursos e as configurações de Política de Grupo do usuário podem não ser atualizadas corretamente.

Para obter mais informações sobre o contexto do erro, consulte Respostas http 400 de solicitação inválida (Cabeçalho de Solicitação por muito tempo) às solicitações HTTP.

Observação

Em condições semelhantes, a autenticação do Windows NTLM funciona conforme o esperado. Você pode não ver o problema de autenticação kerberos, a menos que você analise o comportamento do Windows. No entanto, nesses cenários, o Windows pode não ser capaz de atualizar Política de Grupo configurações.

Esse comportamento ocorre em qualquer uma das versões do Windows com suporte no momento. Para obter informações sobre as versões atualmente com suporte do Windows, confira a planilha de fatos do ciclo de vida do Windows.

Motivo

O usuário não pode autenticar porque o tíquete que Kerberos cria para representar o usuário não é grande o suficiente para conter todas as associações de grupo do usuário.

Como parte do Exchange de Serviços de Autenticação, o Windows cria um token para representar o usuário para fins de autorização. Esse token (também chamado de contexto de autorização) inclui os SID (identificadores de segurança) do usuário e os SIDs de todos os grupos aos quais o usuário pertence. Ele também inclui todos os SIDs armazenados no atributo da conta de sIDHistory usuário. Kerberos armazena esse token na estrutura de dados pac (Certificado de Atributo privilege) no TGT (Kerberos Ticket-Getting Ticket). Começando com Windows Server 2012, Kerberos também armazena o token na estrutura de dados de informações de Declarações do Active Directory (Dynamic Controle de Acesso) no tíquete Kerberos. Se o usuário for membro de um grande número de grupos e se houver muitas declarações para o usuário ou o dispositivo que está sendo usado, esses campos poderão ocupar muitos espaços no tíquete.

O token tem um tamanho máximo fixo (MaxTokenSize). Protocolos de transporte, como rpc (chamada de procedimento remoto) e HTTP, dependem do MaxTokenSize valor quando alocam buffers para operações de autenticação. MaxTokenSize tem o seguinte valor padrão, dependendo da versão do Windows que cria o token:

• Windows Server 2008 R2 e versões anteriores e Windows 7 e versões anteriores: 12.000 bytes
• Windows Server 2012 e versões posteriores e versões Windows 8 e posteriores: 48.000 bytes

Geralmente, se o usuário pertencer a mais de 120 grupos universais, o valor padrão MaxTokenSize não criará um buffer grande o suficiente para manter as informações. O usuário não pode autenticar e pode receber uma mensagem fora da memória . Além disso, o Windows pode não ser capaz de aplicar Política de Grupo configurações para o usuário.

Observação

Outros fatores também afetam o número máximo de grupos. Por exemplo, SIDs para grupos globais e locais de domínio têm requisitos de espaço menores. Windows Server 2012 e versões posteriores adicionam informações de declaração ao tíquete Kerberos e também compactam SIDs de recursos. Ambos os recursos alteram os requisitos de espaço.

Resolução

Para resolve esse problema, atualize o registro em cada computador que participa do processo de autenticação Kerberos, incluindo os computadores cliente. Recomendamos que você atualize todos os seus sistemas baseados no Windows, especialmente se os usuários precisarem fazer logon em vários domínios ou florestas.

Importante

Sérios problemas poderão ocorrer caso você modifique o Registro incorretamente. Antes de modificá-lo, faça backup do registro para restauração, caso ocorram problemas.

Em cada um desses computadores, defina a entrada do MaxTokenSize registro como um valor maior. Você pode encontrar essa entrada na subchave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters . Os computadores precisam ser reiniciados depois que você fizer essa alteração.

Para obter mais informações sobre como determinar um novo valor para MaxTokenSize, consulte a seção Calcular o tamanho máximo do token deste artigo.

Por exemplo, considere um usuário que está usando um aplicativo Web que depende de um cliente SQL Server. Como parte do processo de autenticação, o cliente SQL Server passa o token do usuário para um banco de dados de SQL Server de back-end. Nesse caso, você precisará configurar a entrada do MaxTokenSize Registro em cada um dos seguintes computadores:

• O computador cliente que está executando o Explorer da Internet
• O servidor Web em execução que está executando o IIS
• O computador cliente SQL Server
• O computador de banco de dados SQL Server

Em Windows Server 2012 (e versões posteriores), o Windows poderá registrar um evento (ID do evento 31) se o tamanho do token passar de um determinado limite. Para habilitar esse comportamento, você precisa configurar a configuração de Política de Grupo Configuração do Computador\Modelos Administrativos\System\KDC\Aviso para tíquetes Kerberos grandes.

Calculando o tamanho máximo do token

Use a fórmula a seguir para calcular o tamanho do token que o Windows gera para um determinado usuário. Este cálculo ajuda você a determinar se você precisa alterar MaxTokenSize.

TokenSize = 1200 + 40d + 8s

Para Windows Server 2012 (e versões posteriores), esta fórmula define seus componentes da seguinte maneira:

• 1200. O valor de sobrecarga estimado para um tíquete Kerberos. Esse valor pode variar, dependendo de fatores como o comprimento do nome de domínio DNS e o comprimento do nome do cliente.
• d. A soma dos seguintes valores:
  • O número de associações em grupos universais que estão fora do domínio da conta do usuário.
  • O número de SIDs armazenados no atributo da sIDHistory conta. Esse valor conta associações de grupo e SIDs de usuário.
• s. A soma dos seguintes valores:
  • O número de associações em grupos universais que estão dentro do domínio da conta do usuário.
  • O número de associações em grupos locais de domínio.
  • O número de associações em grupos globais.

O Windows Server 2008 R2 e versões anteriores usam a mesma fórmula. No entanto, essas versões consideram que o número de associações de grupo local de domínio faz parte do valor d em vez do valor s .

Se você tiver um MaxTokenSize valor de 0x0000FFFF (64K), poderá fazer buffer de aproximadamente 1600 SIDs de classe D ou aproximadamente 8.000 SIDs de classe S. No entanto, vários outros fatores influenciam o valor que você pode usar com segurança para MaxTokenSize, incluindo o seguinte:

• Se você usar contas confiáveis para delegação , cada SID exigirá o dobro de espaço.

• Se você tiver várias confianças, configure os trusts para filtrar SIDs. Essa configuração reduz o impacto do tamanho do tíquete Kerberos.

• Se você estiver usando Windows Server 2012 ou uma versão posterior, os seguintes fatores também afetarão os requisitos de espaço sid:

  • Há um novo esquema para compactar os SIDs no PAC. Para obter mais informações, consulte Compactação SID do recurso KDC. Esse recurso reduz o tamanho necessário para SIDs no tíquete.
  • O Controle de Acesso dinâmico adiciona declarações do Active Directory ao tíquete, aumentando os requisitos de tamanho. No entanto, depois de implantar declarações com servidores de arquivo Windows Server 2012, você pode esperar eliminar gradualmente um número significativo de grupos que controlam o acesso ao arquivo. Essa redução, por sua vez, pode reduzir o tamanho necessário no tíquete. Para obter mais informações, consulte Controle de Acesso Dinâmico: Visão geral do cenário.

• Se você configurou Kerberos para usar delegação não treinada, você precisará dobrar o TokenSize valor da fórmula para obter uma estimativa válida de MaxTokenSize.

  Importante

  Em 2019, a Microsoft enviou atualizações para o Windows que alteraram a configuração padrão da delegação não treinada para Kerberos desabilitada. Para obter mais informações, consulte Atualizações à delegação do TGT entre os trusts de entrada no Windows Server.

  Como a compactação sid de recursos é amplamente usada e a delegação não treinada é preterida, MaxTokenSize de 48000 ou maior deve se tornar suficiente para todos os cenários.

Problemas conhecidos que afetam MaxTokenSize

Um MaxTokenSize valor de 48.000 bytes deve ser suficiente para a maioria das implementações. Esse é o valor padrão em versões Windows Server 2012 e posteriores. No entanto, se você decidir usar um valor maior, examine os problemas conhecidos nesta seção.

• Limite de tamanho de 1.010 SIDs de grupo para o token de acesso LSA

  Esse problema é semelhante em que um usuário que tem muitas associações de grupo não pode autenticar, mas os cálculos e as condições que regem o problema são diferentes. Por exemplo, o usuário pode encontrar esse problema usando a autenticação Kerberos ou a autenticação do Windows NTLM. Para obter mais informações, confira Fazer logon em uma conta de usuário que é membro de mais de 1.010 grupos pode falhar em um computador baseado no Windows Server.

• Problema conhecido ao usar valores de MaxTokenSize maior que 48.000

  Para atenuar um vetor de ataque de negação de serviço, o IIS (Servidor de Informações da Internet) usa um tamanho limitado de buffer de solicitação HTTP de 64 KB. Um tíquete Kerberos que faz parte de uma solicitação HTTP é codificado como Base64 (6 bits expandidos para 8 bits). Portanto, o tíquete Kerberos está usando 133% do seu tamanho original. Portanto, quando o tamanho máximo do buffer é de 64 KB no IIS, o tíquete Kerberos pode usar 48.000 bytes.

  Se você definir a entrada do MaxTokenSize registro como um valor maior que 48.000 bytes e o espaço de buffer for usado para SIDs, poderá ocorrer um erro do IIS. No entanto, se você definir a entrada do MaxTokenSize registro como 48.000 bytes e usar o espaço para SIDs e declarações, ocorrerá um erro Kerberos.

  Para obter mais informações sobre tamanhos de buffer do IIS, consulte Como limitar o tamanho do cabeçalho da transmissão HTTP que o IIS aceita de um cliente no Windows 2000.

• Problemas conhecidos ao usar valores de MaxTokenSize maiores que 65.535

  Versões anteriores deste artigo discutiam valores de até 100.000 bytes para MaxTokenSize. No entanto, descobrimos que as versões do Administrador de SMS têm problemas quando o MaxTokenSize é 100.000 bytes ou maior.

  Também identificamos que o protocolo IKE IPSEC não permite que um BLOB de segurança se torne maior que 66.536 bytes, e também falha MaxTokenSize quando é definido como um valor maior.