Problemas com a autenticação Kerberos quando um usuário pertence a vários grupos

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

Número original do KB: 327825

Sintomas

Um usuário que pertence a um grande número de grupos de segurança tem problemas para autenticar. Ao autenticar, o usuário pode ver uma mensagem como HTTP 400 - Solicitação incorreta (cabeçalho da solicitação muito longo). O usuário também tem problemas para acessar recursos e as configurações de Diretiva 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 Bad Request (Request Header too long) para solicitações HTTP.

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, consulte a folha de fatos do ciclo de vida do Windows.

Motivo

O usuário não pode se autenticar porque o tíquete que o 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 Authentication Service Exchange, 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. O Kerberos armazena esse token na estrutura de dados do Certificado de Atributo de Privilégio (PAC) no TGT (Tíquete de Obtenção de Tíquete) do Kerberos. A partir do Windows Server 2012, o Kerberos também armazena o token na estrutura de dados de informações de declarações do Active Directory (Controle de Acesso Dinâmico) no tíquete Kerberos. Se o usuário for membro de um grande número de grupos e se houver muitas reivindicações para o usuário ou o dispositivo que está sendo usado, esses campos poderão ocupar muitos espaços no ticket.

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 Windows 8 e versões 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 armazenar as informações. O usuário não pode se autenticar e pode receber uma mensagem de memória insuficiente. Além disso, o Windows pode não ser capaz de aplicar as configurações de Política de Grupo para o usuário.

Resolução

Para resolver 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.

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

Para obter mais informações sobre como determinar um novo valor para MaxTokenSize, consulte a seção Calculando 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 do SQL Server passa o token do usuário para um banco de dados back-end do SQL Server. Nesse caso, você precisaria configurar a MaxTokenSize entrada do Registro em cada um dos seguintes computadores:

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

No Windows Server 2012 (e versões posteriores), o Windows pode registrar um evento (ID de Evento 31) se o tamanho do token ultrapassar um determinado limite. Para habilitar esse comportamento, você precisa definir a configuração de Política de Grupo Configuração do Computador\Modelos Administrativos\Sistema\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 usuário específico. Esse cálculo ajuda a determinar se você precisa alterar MaxTokenSize.

Tamanho do token = 1200 + 40d + 8s

Para Windows Server 2012 (e versões posteriores), essa 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.

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

Se você tiver um MaxTokenSize valor de 0x0000FFFF (64K), poderá armazenar em buffer aproximadamente 1600 SIDs de classe d ou aproximadamente 8000 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 relações de confiança, configure-as para filtrar SIDs. Essa configuração reduz o impacto do tamanho do tíquete Kerberos.

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

  • Há um novo esquema para compactar os SIDs no PAC. Para obter mais informações, consulte Compactação de SID de recurso do KDC. Esse recurso reduz o tamanho necessário para SIDs no ticket.
  • 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 arquivos do Windows Server 2012, você pode esperar a eliminação gradual de um número significativo de grupos que controlam o acesso a arquivos. Essa redução pode, por sua vez, reduzir o tamanho necessário no bilhete. Para obter mais informações, consulte Controle de acesso dinâmico: visão geral do cenário.

• Se você configurou o Kerberos para usar a delegação irrestrita, será necessário 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 irrestrita do Kerberos para desabilitada. Para obter mais informações, consulte Atualizações para delegação de TGT em relações de confiança de entrada no Windows Server.

  Como a compactação de SID de recurso é amplamente usada e a delegação irrestrita é 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 no Windows Server 2012 e versões 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, pois um usuário que tem muitas associações de grupo não pode se 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 ao usar a autenticação Kerberos ou a autenticação NTLM do Windows. Para obter mais informações, consulte O log 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 maiores que 48.000

  Para atenuar um vetor de ataque de negação de serviço, o Internet Information Server (IIS) 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% de 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 48000 bytes e o espaço do 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

  As versões anteriores deste artigo discutiram valores de até 100.000 bytes para MaxTokenSize. No entanto, descobrimos que as versões do SMS Administrator têm problemas quando o MaxTokenSize é de 100.000 bytes ou mais.

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