Se a sua organização levar a sério a segurança do Active Directory, você precisará de um modelo RBAC (Role Based Access Control). Há muitas maneiras de fazer isso, inclusive usando uma solução de gerenciamento de identidade de terceiros. Na minha experiência, as soluções de terceiros apenas mudam o problema e aumentam a complexidade. Em vez disso, aqui está o que eu encontrei funciona muito bem:
1) Não use o contêiner Usuários padrão para delegar acesso. Criar UOs facilitará sua vida quando se trata de delegar acesso granular e aplicar diretiva de grupo. Separe suas unidades organizacionais de nível superior por níveis de administração. Qualquer coisa que possa ser usada para comprometer os Controladores de Domínio vai no Tier-0, os serviços corporativos vão no Tier-1 e suas estações de trabalho de usuário vão no Tier-2. Você também precisa implementar uma política para impedir que contas de administrador de nível superior façam login em computadores de camada inferior, pois isso as exporia a um ataque de roubo de credenciais. Isso significa que você precisaria de várias contas de domínio para alguns administradores, dependendo da função deles. Por exemplo, alguém contratado para gerenciar a floresta do AD exigiria contas separadas para o administrador corporativo, o administrador do domínio, o administrador do servidor de camada 0, o administrador do servidor de camada 1 e o administrador da estação de trabalho de nível 2. Alguém contratado na central de suporte exigiria apenas o administrador da UO da Camada 2 e o administrador da estação de trabalho da Camada 2. A conta de administração da unidade organizacional é usada para criar / excluir / modificar objetos do AD para sua área / departamento e a conta administrativa da estação de trabalho é usada para a administração remota das estações de trabalho de sua área / departamento. Você precisa dividir essas funções para que um comprometimento de uma função menor (o administrador da estação de trabalho) não seja capaz de comprometer uma função mais alta (o administrador da UO). Isso também significa que você precisa implementar PAW (Privileged Access Workstations, estações de trabalho de acesso privilegiado) para os administradores de funções superiores. Estamos nos divertindo ainda?
2) Estabeleça uma estrutura de UO padronizada que imponha o princípio do menor privilégio. Você tem que decidir se esse modelo será baseado em localização, departamento ou um pouco de ambos. Para a Camada 2, gosto de usar as duas áreas em que a UO de primeiro nível é baseada no local e, em seguida, os departamentos nesse local têm UOs abaixo dela. Isso permite que uma central de atendimento local tenha direitos delegados a todos os objetos em sua localização, e cada departamento com sua própria equipe de TI pode ter direitos delegados apenas para seus objetos. As UOs de Camada 0 e Camada 1 podem ser baseadas nas equipes que executam os serviços. Tudo depende do que funciona melhor para as suas necessidades organizacionais.
3) Cada OU que você criar deve conter um conjunto padrão de sub-UOs, grupos de segurança, ACLs e GPOs. A razão para isso é que você pode facilmente criar scripts para a criação das OUs / Grupos / ACLs / GPOs e sempre se comportará da mesma forma sempre. A padronização é a chave para manter sua sanidade mental, confie em mim. Se mais tarde você decidir mudar alguma coisa, altere-a para todas as estruturas da UO e atualize seu processo de criação. Eu prefiro ter essas UOs padrão:
- Admin (contém todos os grupos administrativos, usuários e computadores PAW para gerenciar a UO)
- Computadores (contém todos os objetos de computador da estação de trabalho para o departamento; GPO de Grupos Restritos aplicado para preencher administradores locais com o grupo de administradores da estação de trabalho dessa OU)
- Servidores (contém todos os objetos do computador servidor para o departamento; GPO de grupos restritos aplicado para preencher os administradores locais com o grupo de administradores do servidor dessa unidade organizacional)
- Usuários (contém todos os objetos de usuário sem privilégios para o departamento)
- Grupos (contém todos os objetos de grupo sem privilégios para o departamento)
As ACLs em cada OU padrão serão usadas para limitar o acesso à propriedade create / delete / computer / group e leitura / gravação de todas as propriedades a um grupo de administradores de OU padrão associado à estrutura da unidade organizacional. Preencha os grupos com os usuários que precisam desse papel. Eu desencorajo strongmente grupos de aninhamento em qualquer um dos grupos de administração padrão, a menos que seja absolutamente necessário. Você pode rapidamente perder o controle de quem são seus administradores se o aninhamento de grupo ficar fora de controle. Eu prefiro colocar os grupos de administradores do OU na OU Administrativa no nível acima para permitir que os usuários do help desk possam designar administradores de departamento do OU. Faça o que funciona para sua organização, mas mantenha-a consistente.
Aqui estão algumas informações sobre boas fontes sobre este tópico: