Existe algum impacto no desempenho da atribuição direta de grupos universais do AD?

Question

Estou implementando uma ferramenta que protege certos recursos compartilhados na floresta do AD (principalmente compartilhamentos de arquivos). Por alguns critérios, uma lista de usuários de diferentes domínios é gerada, esses usuários são adicionados a um grupo universal (porque eu preciso reunir usuários de diferentes domínios em um único grupo) e esse grupo universal é adicionado a um recurso compartilhado ACL. / p>

A floresta tem aproximadamente 10 mil usuários, acho que meus grupos universais terão até 2000 usuários em cada. E pode haver vários milhares desses grupos.

Tudo parece ser bom e funciona no ambiente de teste.

O problema é que há um artigo do MS sobre práticas recomendadas de grupos: link

Quase o mesmo está escrito aqui: link

Na seção "Práticas recomendadas para controlar o acesso a recursos compartilhados em vários domínios" ele lê que eu deveria criar grupos locais de domínio e aninhar grupos globais / universais nele. Eu entendo que há um benefício administrativo, mais fácil gerenciamento, visibilidade, etc

Mas estou fazendo tudo de forma automatizada e minha ferramenta vai observar a segurança certa por si só.

Alguns consultores de TI tentam me persuadir de que não seguir a melhor prática também pode resultar em um desempenho ruim.

Então, basicamente, a pergunta é: Pode haver um impacto de desempenho (significa tempo necessário para logon, proteger um diretório, etc) se eu adicionar grupos universais diretamente no recurso compartilhado em vez de aninhar o grupo universal em um grupo local de domínio ?

Obrigado antecipadamente.

ATUALIZAÇÃO:

Existe também uma restrição em relação aos grupos de aninhamento. ( link ) Existe um limite de 1015 grupos de usuários. Então, no caso de aninhamento de grupos universais em grupos locais de domínio, recebo um limite de ~ 500, o que parece ser uma restrição dolorosa.

UPDATE2: Quanto à minha topologia de floresta. Eu tenho 6 domínios, agrupados em 2 árvores. (A árvore consiste em um domínio raiz e dois domínios filhos)

    

Answer 1

Aqui está a declaração da Microsoft sobre os Grupos Universais. Especialmente a parte em negrito refere-se a você:

Universal groups can be used anywhere in the same Windows forest. They are only available in a Native-mode enterprise. Universal groups may be an easier approach for some administrators because there are no intrinsic limitations on their use. Users can be directly assigned to Universal groups, they can be nested, and they can be used directly with access-control lists to denote access permissions in any domain in the enterprise.

Universal groups are stored in the global catalog (GC); this means that all changes made to these groups engender replication to all global catalog servers in the entire enterprise. Changes to universal groups must therefore be made only after a careful examination of the benefits of universal groups as compared to the cost of the increased global catalog replication load. If an organization has but a single, well-connected LAN, no performance degradation should be experienced, while widely dispersed sites might experience a significant impact. Typically, organizations using WANs should use Universal groups only for relatively static groups in which memberships change rarely.

O impacto no desempenho deve ser mínimo em um ambiente bem conectado, onde todos tenham acesso a catálogos globais.

O impacto no desempenho aumentará o tempo para fazer login e aumentará o tempo para avaliar ACLs em recursos se um catálogo global não puder ser alcançado ou se seus sites & As sub-redes são configuradas incorretamente para que você se comunique com servidores de catálogo global fora do seu próprio site. Além disso, haverá aumento da carga de replicação de catálogo global.

No entanto, sou obrigado a informar mais uma vez que o que você está fazendo é contra práticas recomendadas comumente aceitas.

Esta parte do que você disse: "... e minha ferramenta vai procurar a segurança certa por si só." Isso também me assusta.

Por isso, estou do lado de seus consultores de TI e acho que eles estão fazendo seu trabalho tentando persuadi-lo a seguir as práticas recomendadas geralmente aceitas em termos de design do AD.

Mas há a resposta para sua pergunta, independentemente disso.

    

Answer 2

No caminho de volta, um cenário de desempenho potencial era que a replicação de membros do grupo costumava ser muito pior antes do Windows Server 2003 e ainda pode ter um desempenho ruim com grupos antigos com membros herdados criados antes do Windows Server 2003.

Antes do Windows Server 2003, sempre que uma associação do grupo Global / Universal era alterada, o atributo do membro do grupo inteiro era replicado. Isso teve sérias implicações de desempenho de replicação em diretórios grandes e distribuídos, especialmente com grupos universais com muitos membros. Portanto, em grandes diretórios de vários domínios, era prática comum ter grupos de segurança globais em cada domínio adicionado a um grupo Universal. Isso teve o efeito de particionar a replicação de membros no próprio domínio.

O Windows Server 2003 introduziu a Replicação de Valor Vinculado (LVR, Linked Value Replication). Isso corrigiu muitos desses problemas para grupos recém-criados e grupos cujos membros legados foram convertidos, porque somente os "valores vinculados" (membros) individuais são replicados quando ocorre uma alteração (adicionar / remover membro).

Outra questão potencial foi o número total de membros. Se você tem mais usuários, digamos 50.000 e 40.000 precisam estar em um grupo de segurança, era uma prática comum limitar o número de membros por grupo a menos de 5.000, pois esse é o número máximo de itens que podem ser confirmado com segurança em uma única transação do Active Directory, atômica. No entanto, com um grupo LVR, as atualizações em um grupo com associações grandes não exigem mais o envio de toda a associação, de modo que normalmente isso não é mais um problema, contanto que você mesmo não realize muitas atualizações (adiciona / remove) em um grupo. transação única.

Dito isso, ainda é uma boa prática para grandes grupos em florestas com vários domínios ter grupos de segurança específicos do domínio que sejam adicionados como membros a um único grupo de segurança Universal, que reside tipicamente em um domínio de recurso. Se você usa esse grupo Universal para ACL, um recurso ou adiciona o grupo universal a um grupo local de domínio é com você. Na prática, não vi muitos problemas com o uso de grupos universais, desempenho ou outros. Observe que o acesso a um Catálogo Global raramente deve ser um problema, pois a Microsoft há muito recomenda que todos os controladores de domínio sejam Catálogos Globais. Não é incomum encontrar diretórios grandes criados antes dos grupos de Domínios Locais estarem por aí, mas que não converteram nenhum de seus grupos ou sua estratégia para usar grupos de Domínios Locais.

Alguns motivos Os grupos locais de domínio são recomendados pela Microsoft porque oferecem a maior flexibilidade nos tipos de membros que podem ser adicionados ao grupo e o nível de controle discricionário dos administradores de domínio. Ele também fornece um meio para minimizar a replicação de membros do grupo:

Replicação de catálogo global link

"Grupos com escopo universal, e seus membros, são listados exclusivamente no catálogo global. Grupos com escopo global ou local de domínio também são listados no catálogo global, mas seus membros não são . reduz o tamanho do catálogo global e o tráfego de replicação associado a manter o catálogo global atualizado.Você pode melhorar o desempenho da rede usando grupos com escopo local global ou de domínio para objetos de diretório que serão alterados com freqüência. "

Você também nunca deve usar grupos de Domínio Local para objetos da ACL no Active Directory:

"Quando um usuário se conecta a um catálogo global e tenta acessar um objeto, uma verificação de acesso é executada com base no token do usuário e na DACL do objeto. Todas as permissões especificadas na DACL do objeto para grupos locais de domínio que não são do domínio no qual o controlador de domínio que hospeda o catálogo global (ao qual o usuário se conectou) pertence, será ineficaz, pois somente os grupos locais de domínio do domínio do catálogo global do qual o usuário é membro são representados no token de acesso do usuário. Como resultado, um usuário pode ter acesso negado quando o acesso deveria ter sido concedido, ou o acesso permitido quando o acesso deveria ter sido negado.

"Como prática recomendada, você deve evitar o uso de grupos locais de domínio ao atribuir permissões a objetos do Active Directory ou estar ciente das implicações, caso as use."