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

Este artigo resolve um problema em que o registro em log em uma conta de usuário que é membro de mais de 1.010 grupos falha.

Aplica-se a: Windows Server 2008 R2 Service Pack 1
Número de KB original: 328889

Sintomas

Quando um usuário tenta fazer logon em um computador usando uma conta de computador local ou uma conta de usuário de domínio, a solicitação de logon pode falhar. E você recebe a seguinte mensagem de erro:

Mensagem de logon: o sistema não pode fazer logon devido ao seguinte erro: durante uma tentativa de logon, o contexto de segurança do usuário acumulou muitas IDs de segurança. Tente novamente ou consulte o administrador do sistema.

O problema ocorre quando o usuário de logon é um membro explícito ou transitivo de cerca de 1.010 ou mais grupos de segurança.

Aplicativos e a ID do log de eventos de segurança 4625 podem exibir este código de erro:

0xc000015a

O erro é STATUS_TOO_MANY_CONTEXT_IDS.

Motivo

Quando um usuário faz logon em um computador, a LSA (Autoridade de Segurança Local, parte do Subsistema da Autoridade de Segurança Local) gera um token de acesso. O token representa o contexto de segurança do usuário. O token de acesso consiste em SID (identificadores de segurança exclusivos) para cada grupo do qual o usuário é membro. Esses SIDs incluem grupos transitivos e valores SID do SIDHistory do usuário e das contas de grupo.

A matriz que contém os SIDs das associações de grupo do usuário no token de acesso não pode conter mais de 1.024 SIDs. O LSA não pode remover nenhum SID do token. Portanto, se houver mais SIDs, o LSA não criará o token de acesso e o usuário não poderá fazer logon.

Quando a lista de SIDs é criada, a LSA também insere vários SIDs genéricos e conhecidos, além dos SIDs para associações de grupo do usuário (avaliados transitivamente). Portanto, se um usuário for membro de mais de 1.010 grupos de segurança personalizados, o número total de SIDs poderá exceder o limite de 1.024 SID.

A lista de SIDs personalizados incluirá:

• Os SIDs primários do usuário/computador e os grupos de segurança dos quais a conta é membro.
• Os SIDs no atributo SIDHistory dos grupos no escopo do logon.

Como o atributo SIDHistory pode conter vários valores, o limite de 1.024 SIDs pode ser atingido rapidamente se as contas forem migradas várias vezes. O número de SIDs no Token de Acesso será menor do que o número total de grupos dos quais o usuário é membro na seguinte situação:

• O usuário é de um domínio confiável em que SIDHistory e SIDs são filtrados.
• O usuário é de um domínio confiável em uma confiança em que os SIDs estão em quarentena. Em seguida, apenas SIDs do mesmo domínio que os do usuário estão incluídos.
• Somente os SIDs do Grupo Local de Domínio do domínio do recurso estão incluídos.
• Somente os SIDs de Grupo Local do Servidor do servidor de recursos estão incluídos.

Devido a essas diferenças, é possível que o usuário possa fazer logon em um computador em um domínio, mas não em um computador em outro domínio. O usuário também pode ser capaz de fazer logon em um servidor em um domínio, mas não em outro servidor no mesmo domínio.

Você pode descobrir sobre as associações de grupo de domínio de um usuário afetado com o NTDSUTIL. Ele tem uma ferramenta de Avaliação de Associação de Grupo que também funciona entre limites de florestas. A ferramenta também funciona para os seguintes usuários:

• usuários que estão bem acima do limite de 1.024 SIDs
• usuários que estão em tantos grupos que Kerberos falha na recuperação de tíquetes mesmo com 65.535 bytes do buffer

Siga estas etapas:

1. Abra um prompt de comando em um computador que tenha Ferramentas de Gerenciamento do AD (Controlador de Domínio ou um computador com RSAT).

2. Alterne para a gro mem eva ferramenta e, em seguida, obtenha os comandos disponíveis como a seguinte captura de tela:

   

3. Conecte-se aos DCs necessários para a avaliação:

   • Definir a conta DC %s – DC do domínio do usuário
   • Definir o Catálogo Global %s – GC da floresta do usuário
   • Definir o recurso DC %s – DC do domínio do recurso
   • Defina credenciais conforme necessário ou logs verbosos quando os resultados parecerem incorretos ou a coleção falhar.

4. Execute a avaliação da seguinte maneira (como para Administração em contoso.com):

   Run contoso.com Admin

5. A execução coletará os detalhes do usuário nas etapas 1-2, detalhes do grupo de domínio de recursos na etapa 3 e, em seguida, compilará o relatório nas etapas 4 e 5.

6. Os resultados serão armazenados em um arquivo TSV no diretório atual como a seguinte captura de tela:

   

Confira o seguinte guia para ler um arquivo TSV:

• Tipo SID: Informa se é o SID primário do Grupo/Usuário ou SIDHistory.
• Contagem de histórico do SID: quantos SIDs do SIDHistory essa conta apresenta?
• Contagem de membros de nível: quantos SIDs essa entrada adiciona à coleção em um único nível (membro das entradas)?
• Contagem total de membros: quantos SIDs essa entrada adiciona à coleção no total?
• Proprietário do grupo: para ambientes que delegaram o gerenciamento de grupo, você pode obter dicas de como está usando muitos grupos para atacar o logon do usuário.
• Tipo de grupo: tipo de sid. WellKnown, SID de usuário, grupos de segurança globais e universais estariam em todos os tokens criados para esse usuário. O grupo de segurança local de domínio só estaria neste domínio de recursos. Pode ser importante quando um usuário tem problemas de logon apenas em um determinado domínio de recurso.
• Membro WhenChanged (UTC): última alteração na associação do grupo. Ele pode ajudar a correlacionar-se com a hora em que os usuários relataram problemas de logon pela primeira vez.

Dicas para localizar grupos a serem direcionados para uma alteração:

• Grupos que têm SIDHistory têm uma boa vantagem ajudando a reduzir a contagem de SID.

• Grupos que introduzem muitos outros grupos por meio do aninhamento têm uma grande vantagem para reduzir a contagem de SID.

• Procure pistas no nome do grupo para determinar se o grupo pode não ser usado por mais tempo. Por exemplo, tínhamos um cliente que tem um grupo por aplicativo em sua solução de implantação de software. E encontramos grupos que continham office2000 ou access2000.

• Passe o relatório da lista de grupos para seus administradores de serviço e aplicativo. Identifique grupos que não são mais necessários, talvez apenas para esse usuário nesta unidade de negócios ou departamento.

Limitações:

• A ferramenta não inclui alguns tipos de SIDs especiais/WellKnown listados abaixo neste artigo. Portanto, lembre-se de que um usuário precisa limpar vários SIDs de 1.024 no relatório antes que ele possa fazer logon com êxito.

• A ferramenta também não abrange grupos locais de servidor. Se você tiver problemas apenas em determinados servidores de um domínio de recursos, talvez o usuário ou alguns de seu grupo sejam membros de grupos de servidores locais.

Para obter uma lista de grupos locais de servidores e seus membros:

Net localgroup | findstr * > %computername%-grouplist.txt

Para obter uma lista de membros de um domínio:

Md server-groups

For /f "delims=*" %d in (%computername%-grouplist.txt) do Net localgroup %d | findstr \ > server-groups\%d-domain-memberlist.txt**

Misture e corresponda aos grupos relatados lá com o relatório de usuário do NTDSUTIL.

Resolução

Para corrigir esse problema, use um dos métodos a seguir, conforme apropriado para sua situação.

Método 1

Essa resolução se aplica à seguinte situação:

• O usuário que encontra o erro de logon não é um administrador.
• Os administradores podem fazer logon com êxito no computador ou no domínio.

Essa resolução deve ser executada por um administrador que tenha permissões para alterar as associações de grupo do usuário. O administrador deve alterar as associações de grupo do usuário para garantir que o usuário não seja mais membro de mais de cerca de 1.010 grupos de segurança. Considere as associações de grupo transitivo e as associações de grupo local.

As opções para reduzir o número de SIDs no token de usuário incluem o seguinte. A coleta de dados do NTDSUTIL deve ajudá-lo a ver quais grupos estão no escopo para alteração ou remoção:

• Remova o usuário de um número suficiente de grupos de segurança.

• Converter grupos de segurança não utilizados em grupos de distribuição. Os grupos de distribuição não contam com o limite do token de acesso. Os grupos de distribuição podem ser convertidos de volta em grupos de segurança quando um grupo convertido é necessário.

• Determine se as entidades de segurança estão confiando no histórico do SID para acesso aos recursos. Caso contrário, remova o atributo SIDHistory dessas contas. Você pode recuperar o valor do atributo por meio de uma restauração autoritativa.

Método 2

A resolução se aplica à situação em que a conta de administrador não pode fazer logon no computador.

Quando o usuário cujo logon falha devido a muitas associações de grupo é membro do grupo Administradores, um administrador que tem as credenciais para a conta administrador (ou seja, uma conta que tem um identificador relativo conhecido [RID] de 500) deve reiniciar um controlador de domínio selecionando a opção de inicialização modo seguro (ou selecionando o Modo seguro com a opção inicialização de rede). No modo de segurança, o administrador deve fazer logon no controlador de domínio usando as credenciais da conta de administrador.

A Microsoft alterou o algoritmo de geração de token. O LSA pode criar um token de acesso para a conta administrador para que o administrador possa fazer logon independentemente de quantos grupos transitivos ou grupos intransitivos da qual a conta administrador é membro. Quando uma dessas opções de inicialização de modo seguro é usada, o token de acesso criado para a conta administrador inclui os SIDs de todos os grupos internos e todos os grupos do Domain Global dos quais a conta administrador é membro.

Esses grupos normalmente incluem:

• Todos (S-1-1-0)
• BUILTIN\Users (S-1-5-32-545)
• BUILTIN\Administradores (S-1-5-32-544)
• NT AUTHORITY\INTERACTIVE (S-1-5-4)
• NT AUTHORITY\Usuários Autenticados (S-1-5-11)
• LOCAL (S-1-2-0)
• Domain\Domain Users (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzz-512)
• BUILTIN\Pré-Windows 2000 Acesso Compatível(S-1-5-32-554) se Todos forem membros desse grupo
• NT AUTHORITY\This Organization (S-1-5-15) se o controlador de domínio estiver executando o Windows Server 2003

Depois que um administrador tiver se conectado selecionando uma das opções de inicialização do modo seguro e usando as credenciais da conta administrador, o administrador deve identificar e modificar a associação dos grupos de segurança que causaram a negação do serviço de logon.

Depois que essa alteração for feita, os usuários poderão fazer logon com êxito após um período igual à latência de replicação do domínio ter decorrido.

Método 3

Essa opção terá o maior apelo se você tiver muitos grupos criados para conceder acesso aos recursos usados em um conjunto específico de servidores e eles não forem relevantes para muitos outros servidores. O token de acesso dos usuários sempre contém os SIDs do usuário, grupos globais e universais. No entanto, ele contém apenas os SIDs de Domain-Local grupos do domínio em que os servidores de recursos estão. Portanto, de 600 grupos dos quais um usuário é membro, 400 estão ajudando a dar acesso aos recursos do servidor de arquivos em dois grupos de servidores e, em seguida, as seguintes ideias podem ser viáveis:

• Divida seus servidores em vários grupos por número de grupos de Domain-Local.
• Em vez de um domínio de recurso que tenha todos os grupos e servidores, tenha vários domínios em que apenas os grupos definidos que contêm os servidores necessários.
• Tenha um domínio separado para servidores com um pouco de necessidade de grupos locais de domínio. Um exemplo pode ser os servidores do Exchange, pois o Exchange tem uma forte preferência por grupos universais.

Mais informações

Os SIDs genéricos de uma conta geralmente incluem:

• Todos (S-1-1-0)
• BUILTIN\Users (S-1-5-32-545)
• BUILTIN\Administradores (S-1-5-32-544)
• NT AUTHORITY\Usuários Autenticados (S-1-5-11)
• Sid da Sessão de Logon (S-1-5-5-X-Y)
• BUILTIN\Pré-Windows 2000 Acesso Compatível(S-1-5-32-554) se o usuário for membro desse grupo (aninhado)

Exemplos de SIDs dependendo do tipo de sessão de logon:

• LOCAL (S-1-2-0)
• LOGON DO CONSOLE (S-1-2-1)
• NT AUTHORITY\NETWORK (S-1-5-2)
• NT AUTHORITY\SERVICE (S-1-5-6)
• NT AUTHORITY\INTERACTIVE (S-1-5-4)
• NT AUTHORITY\TERMINAL SERVER USER (S-1-5-13)
• NT AUTHORITY\BATCH (S-1-5-3)

SIDs para grupos primários usados com frequência:

• Domain\Domain Computers (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzz-515)
• Domain\Domain Users (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzz-512)

SIDs que documentam como a Sessão de Logon foi verificada, um dos seguintes valores:

• Identidade afirmada pela autoridade de autenticação (S-1-18-1)
• Identidade afirmada pelo serviço (S-1-18-2)

SIDs que fornecem detalhes sobre contexto de token e detalhes de declaração, mais de um possível:

• Declarações de dispositivo que estão sendo usadas (S-1-5-21-0-0-0-496)
• Declarações de usuário que estão sendo usadas (S-1-5-21-0-0-0-497)
• Este certificado de organização (S-1-5-65-1)
• O token foi criado com a ajuda de uma identidade verificada PKI (S-1-18-4)
• O token foi criado usando a abordagem MFA (S-1-18-5)
• O Credential Guard foi usado (S-1-18-6)

SIDs que descrevem o nível de consistência do token, os exemplos mais comuns:

• Nível Médio Obrigatório (S-1-16-8192)
• Alto nível obrigatório (S-1-16-12288)

O token de acesso inclui um SID relativo à origem do usuário/computador, um dos seguintes valores:

• NT AUTHORITY\OTHER_ORGANIZATION (S-1-5-1000)
• NT AUTHORITY\This Organization (S-1-5-15) se a conta for da mesma floresta que o computador.

O exemplo a seguir ilustra quais grupos de segurança locais de domínio aparecerão no token do usuário quando o usuário fizer logon em um computador em um domínio.

Neste exemplo, suponha que Joe pertence ao Domínio A e seja membro de um grupo local de domínio Domínio A\Usuários de Chicago. Joe também é membro de um grupo local de domínio Domínio B\Usuários de Chicago . Quando Joe faz logon em um computador que pertence ao Domínio A (por exemplo, Domínio A\Workstation1), um token é gerado para Joe no computador e o token contém, além de todas as associações de grupo universais e globais, o SID for Domain A\Chicago Users. Ele não conterá o SID para Usuários do Domínio B\Chicago porque o computador no qual Joe se registrou (Domínio A\Workstation1) pertence ao Domínio A.

Da mesma forma, quando Joe faz logon em um computador que pertence ao Domínio B (por exemplo, Domínio B\Workstation1), um token é gerado para Joe no computador, e o token contém, além de todas as associações de grupo universais e globais, o SID para Usuários do Domínio B\Chicago; ele não conterá o SID para Usuários do Domínio A\Chicago porque o computador no qual Joe se registrou (Domínio B\Workstation1) pertence ao Domínio B.

No entanto, quando Joe faz logon em um computador que pertence ao Domínio C (por exemplo, Domínio C\Workstation1), um token é gerado para Joe no computador de logon que contém todas as associações de grupo universais e globais para a conta de usuário de Joe. Nem o SID for Domain A\Chicago Users nem o SID for Domain B\Chicago Users aparecem no token porque os grupos locais de domínio dos quais Joe é membro estão em um domínio diferente do computador em que Joe se conectou (Domínio C\Workstation1). Por outro lado, se Joe fosse membro de algum grupo local de domínio que pertence ao Domínio C (por exemplo, Usuários do Domínio C\Chicago), o token gerado para Joe no computador conteria, além de todas as associações de grupo universais e globais, o SID para Usuários do Domínio C\Chicago.

Referências

• SIDs conhecidos

• Estruturas SID bem conhecidas

• avaliação de associação de grupo