Estou implementando uma ferramenta que protege determinados recursos compartilhados na floresta do AD (principalmente compartilhamentos de arquivos). Por alguns critérios, uma lista de usuários de domínios diferentes é gerada, esses usuários são adicionados a um grupo universal (porque preciso reunir usuários de domínios diferentes em um único grupo) e então esse grupo universal é adicionado a uma ACL de recurso compartilhado.
A floresta tem cerca de 10.000 usuários, acho que meus grupos universais acabarão tendo até 2.000 usuários cada. E pode haver até vários milhares desses grupos.
Tudo parece bem e funciona em ambiente de teste.
O problema é que existe um artigo da MS sobre práticas recomendadas de grupos:http://technet.microsoft.com/en-us/library/cc787646(v=ws.10).aspx
Quase o mesmo está escrito aqui: http://ss64.com/nt/syntax-groups.html
Na seção "Práticas recomendadas para controlar o acesso a recursos compartilhados entre domínios", lê-se que devo criar grupos locais de domínio e aninhar grupos globais/universais nele. Entendo que há um benefício administrativo nisso, facilidade de gerenciamento, visibilidade, etc.
Mas estou fazendo tudo de forma automatizada e minha ferramenta cuidará sozinha da segurança certa.
Alguns de nossos consultores de TI tentam me convencer de que não seguir essas práticas recomendadas também pode resultar em desempenho insatisfatório.
Então, basicamente, a questão é: pode haver um impacto no desempenho (significa tempo necessário para fazer 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?
Desde já, obrigado.
ATUALIZAR:
Há também uma restrição em relação aos grupos de aninhamento. (http://support.microsoft.com/kb/328889) Há um limite de 1.015 grupos de usuários. Portanto, no caso de aninhar grupos universais em grupos locais de domínio, recebo um limite de aproximadamente 500, o que parece uma restrição dolorosa.
ATUALIZAÇÃO2: Em relação à minha topologia de floresta. Tenho 6 domínios, agrupados em 2 árvores. (A árvore consiste em um domínio raiz e dois domínios filhos)
Responder1
Aqui está a declaração da Microsoft sobre Grupos Universais. Especialmente a parte em negrito pertence a você:
Os grupos universais podem ser usados em qualquer lugar na mesma floresta do Windows. Eles estão disponíveis apenas em uma empresa de modo nativo. Os grupos universais podem ser uma abordagem mais fácil para alguns administradores porque não há limitações intrínsecas ao seu uso. Os usuários podem ser atribuídos diretamente a grupos universais, podem ser aninhados e podem ser usados diretamente com listas de controle de acesso para indicar permissões de acesso em qualquer domínio da empresa.
Os grupos universais são armazenados no catálogo global (GC); isso significa que todas as alterações feitas nesses grupos geram replicação para todos os servidores de catálogo global em toda a empresa.As alterações nos grupos universais devem, portanto, ser feitas somente após um exame cuidadoso dos benefícios dos grupos universais em comparação com o custo do aumento da carga de replicação do catálogo global. Se uma organização tiver apenas uma LAN única e bem conectada, nenhuma degradação de desempenho deverá ocorrer, enquanto locais amplamente dispersos poderão sofrer um impacto significativo. Normalmente, as organizações que usam WANs devem usar grupos universais apenas para grupos relativamente estáticos nos quais as associações raramente mudam.
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 será maior no tempo para fazer login e no tempo para avaliar ACLs nos recursosseum catálogo global não pode ser acessado ou se seus Sites e Sub-redes estiverem configurados incorretamente, fazendo com que você se comunique com servidores de catálogo global fora do seu próprio site. Além disso, haverá um aumento na carga de replicação do catálogo global.
No entanto,Sou obrigado a informar mais uma vez que o que você está fazendo vai contra as melhores práticas comumente aceitas.
Esta parte do que você disse:"... e minha ferramenta cuidará sozinha da segurança certa." Isso também me assusta.
Portanto, 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 comumente aceitas em termos de design de AD.
Mas há a resposta para sua pergunta de qualquer maneira.
Responder2
Há muito tempo atrás, um cenário potencial de desempenho era que a replicação de associação de 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 de grupo Global/Universal era alterada, ointeiroo atributo do membro do grupo foi replicado. Isso teve sérias implicações no desempenho da replicação em diretórios grandes e distribuídos, especialmente em grupos universais com muitos membros. Portanto, em diretórios grandes e com vários domínios, era prática comum ter grupos de segurança globais em cada domínio adicionados a um grupo universal. Isto teve o efeito de particionar a replicação de membros dentro do próprio domínio.
O Windows Server 2003 introduziu a replicação de valor vinculado (LVR). Isso corrigiu muitos desses problemas para grupos recém-criados e grupos cujos membros legados foram convertidos, porque apenas os "valores vinculados" individuais (membros) são replicados quando ocorre uma alteração (adicionar/remover membro).
Outro problema potencial era o número total de membros. Se você tiver mais usuários, digamos 50.000, e 40.000 precisam estar em um grupo de segurança, era 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 atômica do Active Directory. No entanto, com um grupo LVR, as atualizações para um grupo com grandes associações não exigem mais o envio de toda a associação, de modo que isso normalmente não é mais um problema, desde que você mesmo não execute tantas atualizações (adições/remoções) em um única transação.
Dito isto, ainda é uma boa prática que grandes grupos em florestas de vários domínios tenham grupos de segurança específicos de domínio que sejam adicionados como membros de um único grupo de segurança Universal, que normalmente reside num domínio de recursos. Depende de você usar esse grupo universal para ACL de um recurso ou adicionar o grupo universal a um grupo local de domínio. Na prática, não vi muitos problemas com o uso de Grupos Universais, de desempenho ou de outra forma. Observe que o acesso a um Catálogo Global raramente deve ser um problema, já que a Microsoft recomenda há muito tempo que todos os controladores de domínio sejam Catálogos Globais. Não é incomum encontrar grandes diretórios criados antes dos grupos locais de domínio existirem e que não converteram nenhum de seus grupos ou sua estratégia para usar grupos locais de domínio.
Alguns motivos pelos quais os grupos locais de domínio são recomendados pela Microsoft porque fornecem a maior flexibilidade nos tipos de membros que podem ser adicionados ao grupo e no nível de controle discricionário para os administradores de domínio. Também fornece um meio de minimizar a replicação de membros do grupo:
Replicação de catálogo global
http://technet.microsoft.com/en-us/library/cc759007%28v=ws.10%29.aspx
"Grupos com escopo universal e seus membros são listados exclusivamente no catálogo global. Grupos com escopo global ou de domínio local também são listados no catálogo global,mas seus membros não são. Isto reduz o tamanho do catálogo global e o tráfego de replicação associado à manutenção do catálogo global atualizado. Você pode melhorar o desempenho da rede usando grupos comescopo global ou de domínio localpara objetos de diretório que serão alterados com frequência."
Você também nunca deve usar grupos locais de domínio para objetos 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. Quaisquer permissões especificadas na DACL do objeto para grupos locais de domínio que não sejam do domínio que o controlador de domínio que hospeda o catálogo global (ao qual o usuário se conectou) será ineficaz porque apenas os grupos locais do domínio do catálogo global do qual o usuário é membro serão representados no token de acesso do usuário. o usuário pode ter acesso negado quando o acesso deveria ter sido concedido ou 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 em objetos do Active Directory ou estar ciente das implicações se você usá-los."