Você está offline; aguardando reconexão
Entrar

Fazer logon em uma conta de usuário que seja membro de mais de 1010 grupos pode falhar em um computador baseado no Windows Server

O suporte para o Windows Server 2003 termina em 14 de julho de 2015.

A Microsoft terminou o suporte para o Windows Server 2003 em 14 de julho de 2015. Esta alteração afetou as suas atualizações de software e opções de segurança. Saiba o que isto significa para você e como permanecer protegido.

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

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 poderá falhar e você recebe a seguinte mensagem de erro:
Mensagem de logon: A 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 identificações 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 aproximadamente 1010 ou mais grupos de segurança.
Causa
Quando um usuário faz logon em um computador, a autoridade de segurança Local (LSA, parte do subsistema de autoridade de segurança Local) gera um token de acesso que representa o contexto de segurança do usuário. O token de acesso consiste em identificadores de segurança exclusivo (SID) para cada grupo que o usuário é membro. Esses SIDs incluir grupos transitivos e valores de SID do histórico SID do usuário e as contas de grupo.

A matriz que contém os SIDs de membros de grupo do usuário no token de acesso pode conter no máximo 1024 SIDs. A LSA não pode soltar qualquer SID do token. Assim, se houver mais SIDs, a LSA não consegue criar o token de acesso e o usuário não poderão fazer logon.

Quando a lista de SIDs é construída, a LSA também insere várias SIDs genérica, conhecida além de SIDs para membros do grupo do usuário (avaliada temporariamente). Assim, se um usuário for membro de mais de cerca de 1,010 grupos de segurança personalizados, o número total de SIDs pode exceder o limite de SID 1.024.

Importante
  • Tokens para o administrador e as contas de administrador não estão sujeitas ao limite de.
  • O número exato de SIDs personalizados varia de acordo com o tipo de logon (por exemplo, interativo, serviço de rede) e a versão do sistema operacional do controlador de domínio e computador que cria o token.
  • Usando Kerberos ou NTLM como o protocolo de autenticação não possui limite de token de acesso.
  • O cliente Kerberos configuração "MaxTokenSize" é discutido em KB 327825. "Símbolo" no contexto de Kerberos refere-se ao buffer pelos bilhetes recebida por um host Windows Kerberos. Dependendo do tamanho do tíquete, o tipo de SIDs e se a compactação de SID está habilitada, o buffer pode conter menos ou muitos SIDs mais do que caberia no token de acesso.
A lista de SIDs personalizado inclui o seguinte:
  • Os SIDs de computador/usuário e os grupos de segurança principal a conta é membro de.
  • Os SIDs no atributo SIDHistory dos grupos no escopo do logon.
Como o atributo SIDHistory pode conter vários valores, o limite de 1024 SIDs pode ser alcançado muito rapidamente se contas são migradas várias vezes. O número de SIDs no símbolo de acesso será beless que o número total de grupos que o usuário é um membro nas seguintes situações:
  • É o usuário de um domínio confiável, onde SIDHistory e os SIDs são filtrados.
  • É o usuário de um domínio confiável em uma relação de confiança em que os SIDs são colocados em quarentena. Em seguida, apenas os SIDs do mesmo domínio do usuário estão incluídos.
  • Apenas o grupo SIDs locais do domínio do recurso estão incluídos.
  • Somente o servidor grupo SIDs locais do servidor de recursos estão incluídos.
Devido a essas diferenças, é possível que o usuário pode fazer logon em um computador em um domínio, mas não a um computador em outro domínio. O usuário também pode ser capaz de se conectar a um servidor em um domínio, mas não para outro servidor no mesmo domínio.
Resolução
Para corrigir esse problema, use um dos seguintes métodos, conforme apropriado para sua situação.

Método 1

Essa resolução se aplica à situação em que o usuário que encontrou o erro de logon não é um administrador, e os administradores podem fazer logon no computador ou no domínio.

Essa resolução deve ser executada por um administrador que tem permissões para alterar as associações de grupo que o usuário afetado é membro. O administrador deve alterar associações de grupo do usuário para certificar-se de que o usuário não é mais um membro dos grupos de segurança mais de cerca de 1010 (considerando as participações em grupo transitiva e os membros do grupo local).

Opções para reduzir o número de SIDs no símbolo de usuário incluem o seguinte:
  • Remova o usuário de um número suficiente de grupos de segurança.
  • Converta grupos de segurança não utilizados para grupos de distribuição. Grupos de distribuição não contam com relação ao limite de token de acesso. Grupos de distribuição podem ser convertidos para grupos de segurança quando um grupo de convertida é necessário.
  • Determine se os objetos de segurança estão contando com History SID para acessar recursos. Caso contrário, remova o atributo SIDHistory essas contas. Você pode recuperar o valor do atributo por meio de uma restauração autoritativa.
Observação: Embora o número máximo de grupos de segurança que um usuário pode ser membro de 1024, como uma prática recomendada, restrinja o número para menos de 1010. Esse número torna-se de que essa geração de token sempre terá êxito porque ele fornece espaço para SIDs genéricos são inseridos por LSA.

Método 2

A resolução se aplica à situação na qual administrador conta não pode efetuar logon no computador.

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

A Microsoft alterou o algoritmo de geração de token para que a LSA pode criar um token de acesso para a conta de administrador para que o administrador pode fazer logon, independentemente de quantos grupos transitivos ou intransitivos grupos que a conta administrador é um membro do. Quando uma das seguintes opções de inicialização modo de segurança é usada, o token de acesso criado para a conta de administrador inclui os SIDs de todos os internos e todos os grupos globais do domínio que a conta administrador é um membro de.

Esses grupos geralmente incluem o seguinte:
  • Todos (S-1-1-0)
  • BUILTIN \ usuários (S-1-5-32-545)
  • BUILTIN\Administradores (S-1-5-32-544)
  • NT\INTERATIVO (S-1-5-4)
  • NT AUTHORITY\Authenticated Users (S-1-5-11)
  • LOCAL (S-1-2-0)
  • Domínio\Domain Users(S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-513)
  • DomínioAdministração de \Domain (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-512)
  • BUILTIN\Pre Windows 2000 compatível com Access(S-1-5-32-554) se todos é membro deste grupo
  • Organização de AUTHORITY\This NT (S-1-5-15) se o controlador de domínio estiver executando o Windows Server 2003
Observação: Se for usada a opção de inicialização Modo de segurança , a interface de usuário do snap-in Active Directory Users and Computers (UI) não está disponível. No Windows Server 2003, o administrador pode também fazer logon, selecionando a opção de inicializaçãoModo seguro com redes ; Nesse modo, o Active Directory Users and Computers snap-in UI está disponível.

Depois um administrador faz logon, selecionando uma das opções de inicialização modo de segurança e usando as credenciais da conta de administrador, o administrador deve identificar e modificar os membros dos grupos de segurança que causou a negação de serviço de logon.

Após essa alteração ser feita, os usuários poderão fazer logon com êxito depois de decorrido um período de tempo que é igual a latência de replicação do domínio.
Mais Informações
Os SIDs de uma conta genérica freqüentemente incluem o seguinte:
Todos (S-1-1-0)
BUILTIN \ usuários (S-1-5-32-545)
BUILTIN\Administradores (S-1-5-32-544)
NT AUTHORITY\Authenticated Users (S-1-5-11)
Sid de sessão de logon (S-1-5-5-X-Y)
Importante: A ferramenta "Whoami" é freqüentemente usada para verificar Tokens de acesso. Essa ferramenta não mostra a sessão de logon SID.

Exemplos de SIDs dependendo do tipo de sessão de logon:
LOCAL (S-1-2-0)
LOGON NO CONSOLE (S-1-2-1)
NT AUTHORITY (S-1-5-2)
AUTHORITY\SERVICE NT (S-1-5-6)
NT\INTERATIVO (S-1-5-4)
USUÁRIO DO SERVIDOR NT AUTHORITY\TERMINAL (S-1-5-13)
AUTHORITY\BATCH NT (S-1-5-3)
SIDs dos grupos primários usados com mais freqüência:
\Domain os computadores do domínio (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-515)
Usuários do domínio \Domain (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-513)
Administradores do domínio \Domain (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-512)
SIDs que documentam como a sessão de Logon foi verificada:
A autoridade de autenticação declarada identidade (S-1-18-1)
Serviço declarada identidade (S-1-18-2)
SIDs que descrevem o nível de consistência do token:
Nível obrigatório médio (S-1-16-8192)
Nível obrigatório alto (S-1-16-12288)
O token de acesso, opcionalmente, pode incluir as seguintes SIDs:
BUILTIN\Pre Windows 2000 compatível com Access(S-1-5-32-554) se todos é membro deste grupo
Organização do AUTHORITY\This NT (S-1-5-15) se a conta for da mesma floresta que o computador.
Observação:
  • Como você pode ver com a observação na entrada de SID "SID de sessão de Logon", não contar os SIDs na lista de resultados da ferramenta e assumir que estão completas para todos os computadores de destino e tipos de logon. Você deve considerar que uma conta está em perigo de execução para esse limite quando ele tem mais de 1000 SIDs. Não se esqueça de que, com o computador em que um símbolo é criado, servidor ou grupos locais da estação de trabalho também podem ser adicionados.
  • xxxxxxxx-yyyyyyyy-zzzzzzzzindicates os componentes de estação de trabalho ou domínio do SID.
O exemplo a seguir mostra qual segurança local de domínio grupos aparecerão no símbolo do usuário quando o usuário fizer logon em um computador em um domínio.

Neste exemplo, suponha que Joe pertence a um domínio e é um membro de um grupo local de domínio os usuários do domínio A\Chicago. Joe também é um membro de um grupo local de domínio os usuários do domínio B\Chicago. Quando Jorge faz logon em um computador que pertence a um domínio (por exemplo, A\Workstation1 de domínio), um token é gerado para José no computador e o token contém, além de todos os membros do grupo universal e global, o SID para usuários do domínio A\Chicago. Ela não conterá o SID de domínio B\Chicago usuários porque o computador onde Joe conectado (domínio A\Workstation1) pertence ao domínio A.

Da mesma forma, quando Jorge faz logon em um computador que pertence ao domínio B (por exemplo, o domínio B\Workstation1), um token é gerado para José no computador e o token contém, além de todos os membros do grupo universal e global, o SID do domínio B\Chicago usuários; ela não conterá o SID de domínio A\Chicago usuários porque o computador onde Joe conectado (domínio B\Workstation1) pertence ao domínio B.

No entanto, quando Jorge faz logon em um computador que pertence ao domínio C (por exemplo, o domínio C\Workstation1), um token é gerado para José no computador de logon que contém todos os membros do grupo universal e global para a conta de usuário de José. O SID de domínio A\Chicago usuários nem o SID para os usuários do domínio B\Chicago é exibido no token porque os grupos locais do domínio que Joe é um membro da estão em um domínio diferente do computador onde Joe conectado (domínio C\Workstation1). Por outro lado, se a 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 José no computador conteria, além de todos os membros do grupo universal e global, o SID para usuários do domínio C\Chicago.
Referências
SIDs conhecidos

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 328889 - Última Revisão: 12/15/2015 07:02:00 - Revisão: 3.0

  • Windows Server 2012 Datacenter
  • Windows Server 2012 Essentials
  • Windows Server 2012 Foundation
  • Windows Server 2012 Standard
  • Windows Server 2008 R2 Service Pack 1
  • Windows Server 2008 Service Pack 2
  • Windows Server 2008 Enterprise
  • Windows Server 2008 Standard
  • Windows Server 2008 Datacenter
  • Windows Server 2008 Standard without Hyper-V
  • Windows Server 2008 for Itanium-Based Systems
  • Windows Server 2008 Enterprise without Hyper-V
  • Windows Server 2008 Datacenter without Hyper-V
  • Microsoft Windows Server 2003 Service Pack 2
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • kbinfo kbexpertiseadvanced kbsurveynew kbmt KB328889 KbMtpt
Comentários