Grupos do Active Directory e grupos locais incorporados: alguma prática recomendada por aí?

Question

Estamos executando um Active Directory que consiste em várias máquinas Windows diferentes (Vista, Windows 7, Windows 10, 2008 R2, 2012 R2, ...). Eu tenho que criar um conceito que permita o gerenciamento granular de permissões locais. Atualmente, muitas pessoas têm todos os direitos sobre as máquinas.

Estou planejando fazer o seguinte:

1. Administradores (grupo local no Servidor A) < == isMemberOf () == ServerA_Administrators
2. Operadores de backup (grupo local no ServerA) < == isMemberOf () == Operadores ServerA_Backup
3. etc ...

Então eu faria o mesmo para o ServerB e assim por diante. Mais tarde, então, eu agregaria esses grupos do AD em outros maiores como este:

1. Server_Administrators (membros: ServerA_Administrators, ServerB_Administrators, ...)
2. Server_Backup Operators (membros: ServerA_Backup Operators, ServerB_Backup Operators, ...)
3. etc.

Isso permitiria que eu controlasse o AD-side, qual usuário tem direitos de administrador locais. Eu poderia dar aos usuários direitos de deus em todas as máquinas de uma só vez e outros apenas em várias máquinas (ou apenas uma).

A desvantagem é que eu iria explodir o banco de dados do AD, pois muitos novos grupos são necessários.

Infelizmente, não encontrei nenhum documento da Microsoft descrevendo a melhor prática no que diz respeito a lidar com grupos locais internos em um ambiente de AD.

Qual seria a melhor maneira de alcançar meu objetivo?

    

Answer 1

O número de grupos em si não é o problema, ele é finalmente programável por script - o número de membros do grupo é (por exemplo, devido ao tamanho do token do kerberos max). Eu prefiro o seguinte (Exemplo para membros do administrador local)

Site A
Host A1: HostA1-Admin, SiteA Admin
Host A2: HostA2-Admin, SiteA Admin

Site B
Host B1: HostB1-Admin, SiteB Admin
Host B2: HostB2-Admin, SiteB Admin

Assim, você pode atribuir um único host ou administração relacionada ao site a seus colegas. Sempre tente reduzir a participação no grupo. Grupos em cascata não reduzem isso (veja whoami / groups). Se você tem uma floresta, isso difere um pouco, mas o problema permanece o mesmo.
Dependendo do tamanho do seu domínio, use scripts ou gpos para adicionar esses grupos aos seus administradores locais.
Além disso, veja os conceitos de grupo no diretório ativo (Domínio local / Global / Universal), que é importante para a floresta, mas também para domínios locais, pois afeta o catálogo global (é o índice de pesquisa do seu anúncio e usado por muitos Serviços MS) . A Microsoft usa para grupos locais e globais os grupos de recursos e usuários (?) De terminologia, o que já sugere o uso pretendido.

    

Answer 2

Tenha cuidado com o número de grupos dos quais o usuário é! Esse número afeta o tamanho do tique Kerberos t. Depois de atingir um certo limite - o usuário não pode fazer login. Isso é muito importante em grandes domínios.

Eu recomendo criar um grupo não é "por servidor", mas "por função" do usuário ( contador, operador, gerente, administrador). E esses grupos, se necessário, incluem um grupo de servidores locais. Em seguida, ele minimiza o número de grupos de domínio aos quais o usuário pertence.