Inchaço do token Kerberos MaxTokenSize: corrigir grupos com segurança

O que é o inchaço do token Kerberos?

O diagnóstico de inchaço do token Kerberos e MaxTokenSize começa com uma distinção: o número de pessoas num grupo é diferente do número de SIDs de grupos transportados para uma pessoa. A proliferação de grupos pode tornar-se um problema de disponibilidade da autenticação, mas uma constatação de grupo grande, por si só, não o diagnostica. Uma investigação útil relaciona a identidade afetada, o serviço que falha, o contexto de autorização e os limites ao longo do caminho de autenticação desse serviço.

Uma limpeza de emergência introduz um segundo problema. Remover associações a grupos até uma aplicação voltar a funcionar altera o acesso sem estabelecer que permissões ou restrições foram removidas. Algumas remoções reduzem privilégios desnecessários; outras interrompem trabalho necessário. Uma remoção também pode enfraquecer um controlo se a associação ao grupo fornecia uma restrição. O resultado de segurança depende do papel real do grupo, e não de a lista de membros ter ficado mais curta.

Este guia trata o aninhamento circular e as alterações a grupos incorporados como sinais a rever durante essa investigação. Não apresenta uma indisponibilidade observada nem um incidente de segurança medido. O objetivo é uma correção que restabeleça o fluxo de trabalho afetado, preservando os acessos aprovados e as negações de acesso aprovadas.

Como funciona: PAC, MaxTokenSize e limites separados

O TGT Kerberos transporta dados de autorização no seu Privilege Attribute Certificate (PAC): SIDs do utilizador, dos grupos e de sIDHistory. As claims e a compressão de SIDs também afetam as necessidades de espaço. Os bytes resultantes são o que importa; a contagem de membros diretos é uma medição diferente. A Microsoft KB327825 explica este mecanismo.

A KB837361 documenta a definição de registo MaxTokenSize:

A secção de problemas conhecidos da KB327825 identifica separadamente um limite LSA de 1 010 SIDs de grupos no token de acesso, que afeta Kerberos ou NTLM. Aumentar MaxTokenSize não elimina este limite separado. KB327825, problemas conhecidos.

A KB938118 indica 65 535 bytes como valor máximo permitido, mas desaconselha valores superiores a 48 000 porque a codificação HTTP Base64 expande os dados de autenticação. Trate o máximo permitido e uma definição operacional adequada como decisões separadas. Aumentar um valor de registo não elimina todas as restrições a jusante.

O aninhamento circular é um problema de grafos

Suponha que o Grupo A contém o Grupo B e que o Grupo B contém o Grupo A. Uma travessia personalizada que revisita nós sem os controlar pode entrar num ciclo ou contar visitas repetidas. É uma consequência algorítmica, não uma afirmação sobre comportamento observado do KDC ou do PowerShell. Regressar ao mesmo grupo não cria um novo SID único a cada visita.

Preserve as arestas diretas entre grupos ao investigar um ciclo. Uma componente fortemente conexa (SCC) identifica um conjunto de grupos que se podem alcançar mutuamente; a topologia ajuda o revisor a escolher a relação a remover. Uma constatação de ciclo não estabelece que o PAC de um utilizador excede MaxTokenSize. O ciclo e as associações efetivas excessivas podem coexistir, mas precisam de evidências separadas.

Aninhamento perigoso de grupos no Active Directory explica como a herança oculta cria um caminho para Tier 0 e por que motivo a remediação deve identificar a aresta de grupo que concede esse privilégio. Aplique essa revisão de caminhos ao simplificar associações, para que uma correção de disponibilidade também preserve o limite de privilégios pretendido.

Sintomas por serviço e o cenário de alteração de emergência

A Microsoft documenta HTTP 400 com um cabeçalho de pedido demasiado grande, falhas de acesso a recursos e problemas de atualização da Política de Grupo do utilizador. O seu exemplo de cliente/IIS/SQL torna as máquinas participantes relevantes para o diagnóstico. KB327825, sintomas e resolução.

Use a tabela seguinte como plano de investigação. São perguntas a testar, não assinaturas de erro adicionais nem evidências de que Kerberos falha aleatoriamente.

Se o mesmo utilizador tem sucesso num serviço e falha noutro, preserve ambos os casos. Compare os seus caminhos reais antes de alterar grupos. O caso bem-sucedido é uma evidência de diagnóstico útil, mas não identifica o limite aplicável ao caso que falha. Evite substituir essa comparação por uma afirmação genérica de inchaço intermitente do token.

Como remover um grupo pode remover uma restrição

Considere um exemplo condicional numa estação de trabalho Windows 10/11 abrangida pela documentação da Microsoft sobre Deny access to this computer from the network. Um grupo de segurança dedicado transporta SeDenyNetworkLogonRight. A definição está em Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. A Microsoft documenta que este Deny tem precedência sobre o Allow correspondente de acesso pela rede e que as alterações de atribuição se aplicam no início de sessão seguinte.

Agora suponha que um operador remove o utilizador desse grupo apenas para reduzir associações. Se este era o único caminho do utilizador para Deny e um Allow permanece, o contexto de autorização seguinte perde essa restrição. É uma inferência condicional a partir do comportamento documentado da política, não um relato de incidente. Não prova que todas as partilhas ou ficheiros passam a estar acessíveis: outras ACLs e negações ainda têm de ser verificadas. Verifique a aplicabilidade antes de estender este exemplo de estação de trabalho a outros sistemas.

A documentação da Microsoft sobre grupos de segurança explica que os grupos podem transportar direitos de utilizador e permissões sobre recursos. Antes de remover uma aresta ou um membro, registe ambos os papéis. O nome de um grupo, por si só, é insuficiente para decidir se a remoção reduz privilégios, interrompe acesso necessário ou elimina uma restrição.

Desvio do acesso privilegiado no Active Directory explica como exceções temporárias sem responsáveis, prazo de validade e revalidação podem recriar direitos através de grupos e ACLs. Use a mesma disciplina de referência para correções urgentes, especialmente quando um fluxo de trabalho que falha provoca uma concessão compensatória de acesso.

Deteção: recolher associações, caminhos e contexto de aviso

Passo 1: criar um registo para cada serviço afetado

Registe o utilizador, as versões do cliente e do servidor, o serviço/SPN, o MaxTokenSize efetivo de cada participante, a população de grupos/SIDs, sIDHistory, as claims ou o contexto de delegação, a falha exata e qualquer aviso relevante. Preserve as evidências antes de editar. Distinga uma falha observada de uma estimativa, de uma constatação sobre a postura do diretório e de um novo teste bem-sucedido.

O ID de evento 31 pode avisar sobre um limiar configurado para tickets grandes no Windows Server 2012 e posteriores. Ative-o através de Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets. Não é prova de que MaxTokenSize foi excedido; correlacione-o com o serviço que falha. KB327825, resolução.

Registe o limiar real de aviso e se essa política está ativada. A passagem da fonte não fornece um limiar numérico universal. A ausência do aviso não é um resultado que ilibe a conta.

Passo 2: inventariar os grupos do principal

O seguinte é o Exemplo 2 de Get-ADPrincipalGroupMembership, reproduzido como comando documentado. Estes comandos não foram executados num ambiente AD para este artigo; substitua a identidade de exemplo por uma conta resolvida no seu âmbito.

Get-ADPrincipalGroupMembership -Identity Administrator

O cmdlet exige um catálogo global. A Microsoft documenta ResourceContextServer para pesquisar grupos locais noutro domínio. Verifique o contexto do recurso em vez de assumir que o domínio da conta conta toda a história do serviço. Os objetos de grupo devolvidos apoiam um inventário; não são uma medição dos bytes do ticket.

Passo 3: preservar as arestas diretas antes de achatar os resultados

Esta consulta de membros diretos utiliza os parâmetros documentados de Get-ADGroupMember:

Get-ADGroupMember -Identity "Enterprise Admins"

Para comparação, o Exemplo 4 da Microsoft inclui membros alcançados através de grupos subordinados:

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive

A Microsoft descreve a saída recursiva como os membros terminais da hierarquia. Preserve as relações diretas separadamente para explicar um caminho ou ciclo. Uma saída achatada não explica, por si só, que relação fornece um direito. A documentação também identifica uma limitação para membros noutra floresta sem Active Directory Web Service.

Para uma vista direcionada de SIDs transitivos, a Microsoft documenta o atributo calculado tokenGroups (atributo Token-Groups), obtido com uma consulta LDAP de âmbito BASE sobre o principal e com um catálogo global disponível. É dispendioso para os controladores de domínio. Comece pelas contas afetadas em vez de consultas abrangentes repetidas. A população de SIDs é uma evidência útil, mas continua a não ser um contador de bytes do PAC.

Remediação: simplificar grupos sem perder controlos aprovados (Remediation)

Passo 1: estabelecer a referência e a reversão

Guarde as associações diretas, as arestas entre grupos e a população transitiva das contas afetadas. Registe os responsáveis pelos grupos, os usos de recursos, os direitos de utilizador, as restrições aprovadas, as definições de buffer e as aplicações afetadas. Documente a alteração pretendida e uma reversão antes de remover associações. Os comandos anteriores, só de leitura, apoiam este inventário; não autorizam uma eliminação.

Reveja os grupos incorporados face a uma referência organizacional mantida. A Microsoft documenta funções legítimas para grupos como Event Log Readers mesmo quando a sua lista de membros predefinida está vazia. Um novo membro pode ser intencional. Sem uma referência mantida, reveja a justificação do responsável em vez de tratar a adição em si como maliciosa.

Passo 2: remover dependências desnecessárias e quebrar ciclos incorretos

Identifique a aresta precisa que cria um ciclo ou uma dependência obsoleta. Confirme os seus usos com o responsável, remova apenas a relação aprovada e preserve as permissões e negações necessárias. Achatar significa simplificar a arquitetura de grupos; não significa atribuir cada utilizador diretamente a todas as ACLs de recursos.

Separe os papéis de negócio dos grupos de recursos e atribua a ambos responsáveis e datas de revisão. Verifique se o novo desenho reduz realmente as associações efetivas desnecessárias. Reorganizar nomes de grupos ou aninhamentos sem reduzir a população relevante de SIDs não estabelece que o contexto de autenticação ficou mais pequeno.

Passo 3: usar MaxTokenSize como medida temporária de âmbito limitado

Se a investigação demonstrar um limite de buffer, considere uma alteração controlada da configuração a par da limpeza estrutural. A KB938118 documenta a política em Computer Configuration\Policies\Administrative Templates\System\Kerberos, denominada Set maximum Kerberos SSPI context token buffer size. Especifica a ativação da política e a introdução de 48000. Para o procedimento de preferências de registo, escolha REG_DWORD e entrada decimal.

Compare primeiro esse valor com a configuração efetiva. Definir 48 000 numa máquina que já utiliza 48 000 não aumenta a capacidade. Siga os requisitos de reinício documentados após a aplicação, preserve uma reversão e reveja as restrições HTTP. Não trate 65 535 como a recomendação predefinida nem assuma que uma alteração apenas no controlador de domínio resolve um caminho com vários participantes.

Passo 4: testar os acessos necessários e as negações necessárias

Volte a ligar as contas piloto e repita o teste de cada serviço afetado. Verifique as ações de negócio aprovadas, as restrições que devem permanecer e quaisquer concessões compensatórias introduzidas durante a indisponibilidade. Compare as associações e as arestas diretas antes e depois. Volte a observar a falha real e o contexto de aviso.

Uma constatação de tamanho ou de ciclo eliminada é uma evidência útil de postura, mas não é um teste completo de aceitação do serviço. Encerre a correção quando o fluxo de trabalho afetado e o modelo de acesso corresponderem ao objetivo documentado. Preserve as exceções com responsáveis e datas de revisão para que alterações posteriores possam ser verificadas face à mesma referência.

Como a EtcSec deteta esta condição

O etc-collector da EtcSec fornece seis verificações relevantes da postura do diretório. Os seus predicados exatos são apresentados abaixo. As quatro verificações de tamanho contam membros diretos, não o tamanho do token. Nenhuma das seis verificações conta os SIDs transitivos de grupos de um utilizador, mede bytes do PAC, lê MaxTokenSize ou prova uma falha de autenticação.

O sufixo CRITICAL corresponde à gravidade real High, e HIGH corresponde à gravidade real Medium. Estes limiares de membros diretos são políticas do collector, não limites de autenticação da Microsoft. Os predicados de tamanho não têm um filtro explícito entre grupos de segurança e de distribuição.

As suas populações sobrepõem-se: GROUP_EXCESSIVE_MEMBERS abrange tanto a população de 101–500 como a de >500; OVERSIZED_GROUP_HIGH é um subconjunto de OVERSIZED_GROUP. Não some as contagens como grupos distintos nem descreva quatro riscos de inchaço do token provados independentemente. Mostrar apenas os cinco maiores grupos nos detalhes de membros excessivos não limita a contagem total de constatações.

A verificação circular conta os grupos envolvidos, não ciclos nem utilizadores com falhas. O seu grafo retém apenas grupos conhecidos que foram recolhidos e normaliza os nomes distintos. Um ciclo que passe por um domínio não recolhido pode não ser detetado. O resultado localiza relações a rever, não a causa de uma falha Kerberos.

O que a referência dos grupos incorporados significa realmente

BUILTIN_MODIFIED utiliza pesquisas exatas de sAMAccountName em inglês. As suas listas não vazias aceitam Administrator, Domain Admins e Enterprise Admins para Administrators; Domain Users, Authenticated Users e INTERACTIVE para Users; e Guest e Domain Guests para Guests.

As suas nove listas vazias abrangem Remote Desktop Users, Network Configuration Operators, Performance Monitor Users, Performance Log Users, Distributed COM Users, IIS_IUSRS, Cryptographic Operators, Event Log Readers e Certificate Service DCOM Access. Um CN extraído num destes grupos pode ativar a verificação mesmo quando a adição apoia trabalho legítimo.

A comparação aceita uma igualdade sem distinção entre maiúsculas e minúsculas ou uma correspondência de subcadeia com um nome esperado. Ignora DNs de membros sem um CN extraído e não verifica o SID nem o contentor do grupo. Nomes localizados, renomeações, grupos homónimos e CNs que contêm um nome esperado limitam a interpretação. Não deteta membros esperados em falta, não inspeciona alterações a ACLs nem compara o histórico de alterações de uma organização.

Use esta constatação para pedir um responsável, uma justificação e uma comparação com a referência local. A resposta correta é uma decisão revista sobre os membros, não uma purga automática. Combine as seis constatações com as evidências dos serviços recolhidas acima para decidir o que alterar e como validar.