Se você é um administrador de sistemas Windows, provavelmente já teve que gerenciar usuários e computadores do Active Directory. Para os não iniciados, pode parecer simples – é apenas um monte de computadores e usuários em uma estrutura semelhante a uma pasta conhecida como Unidades Organizacionais (OUs). No entanto, compreender os comos e porquês de projetar a estrutura de determinadas maneiras para atender às necessidades da sua empresa é uma consideração importante. Se não for feito certo desde o início, pode ser um projeto em si mesmo para desvendar a bagunça resultante para trazer tudo de volta a um estado gerenciável.
As principais considerações sobre como estruturar OUs se resumem a três áreas; facilidade de gerenciamento, permissões e políticas de grupo.
Mais comumente, as estruturas de OU que as pessoas usam são simples (sem sub OUs), com base geográfica, com base em departamento ou com base em funções. Frequentemente, há uma mistura dessas estruturas, em vez de um único estilo escolhido para todo o ambiente.
Permissões
A delegação de controle funciona como a maioria das metodologias de segurança – aplique as configurações na OU de nível superior em que você deseja começar e isso irá fluir para todas as OUs filhas e objetos dentro delas. Sem uma estrutura de OU bem planejada, isso pode ficar confuso rapidamente. Você pode negar a herança em OUs para que não obtenham as configurações de segurança acima delas, o que é necessário em alguns cenários, mas pode aumentar a complexidade do gerenciamento de permissões.
Ter seu helpdesk com acesso para redefinir senhas de usuário pode ser bom para a equipe padrão, mas você pode não querer que eles possam fazer isso para qualquer conta que tenha acesso de nível superior (especialmente administrador de domínio). Ter diferentes tipos de conta em diferentes OUs oferece a flexibilidade de diferentes níveis de acesso e permissões. O mesmo se aplica a computadores e pode evitar que ocorra erro humano quando alguém desativa ou redefine uma conta de computador – algo que você geralmente não quer que aconteça em um servidor de produção.
Também vale a pena mencionar que, idealmente, você deve criar um grupo de segurança dedicado para cada conjunto de permissões usado para o Active Directory e, em seguida, adicionar os usuários que precisam desse acesso ao grupo. Pode parecer mais trabalhoso no momento, mas é muito fácil de gerenciar e descobrir quem tem acesso a quê. Se você já teve que gerenciar permissões e compartilhamentos de arquivos antes, uma lógica semelhante se aplica.
Políticas de Grupo
Da mesma forma que as permissões, as Políticas de Grupo são aplicadas a uma OU e alimentadas por todas as OUs filhas, a menos que sejam configuradas para bloquear a herança. Por exemplo, as políticas de grupo do servidor podem ser muito diferentes das políticas de grupo do computador do usuário final. Devido a esses diferentes requisitos de segurança, faz muito mais sentido ter servidores em uma OU diferente de nível superior. Você pode ter algumas configurações globais que deseja aplicar a todos os objetos de computador (como uma política de senha) e, em seguida, configurações extras que se aplicam apenas a estações de trabalho.
Você também pode querer dividi-los novamente em localizações geográficas; as configurações do site podem então ser aplicadas, como apontar estações de trabalho na OU de Nova York para o servidor WSUS de Nova York.
Aqui está um exemplo de design usando os critérios acima, mas novamente você precisará decidir o que é melhor para sua situação e requisitos:
Outro ponto a ser mencionado é que, por padrão, as pastas de nível superior chamadas ‘Usuários’ e ‘Computadores’ são criadas. Não use-os porque não são OUs adequadas, mas existem por motivos de legado.
Facilidade de gerenciamento
Esta é uma consideração em torno das convenções de nomenclatura e o design torna os objetos dentro dela fáceis de encontrar. Nesse aspecto, faz sentido fazer com que os objetos Computador entrem em uma OU chamada Computadores, mas provavelmente faz sentido separar servidores e clientes. Você pode desejar OUs separadas para grupos de segurança, listas de distribuição, contas de serviço, contas de usuário padrão, contas de administrador e assim por diante. Isso também significa que, quando um novo objeto é criado, qualquer pessoa pode facilmente trabalhar com base no design onde o objeto deve ser colocado.
Isso realmente só se aplica depois que as outras duas considerações forem decididas e, com sorte, a maioria dessas escolhas já levará a uma estrutura bem definida.
Conclusão
Se você já tem uma bagunça e deseja começar de novo, crie uma nova OU de nível superior e crie um design lá do que você procura. Depois de ter esse design no lugar, certifique-se de que todos concordam e estão felizes com ele. A partir daí, você pode vincular ou redesenhar suas Políticas de Grupo e vinculá-las conforme necessário e, finalmente, começar a mover os objetos. Se algo der errado, você sempre pode mover os objetos de volta e descobrir qual era o problema. Continue migrando até que tudo seja movido e, finalmente, você pode começar a remover a estrutura antiga da UO.
Para aqueles que estão projetando uma estrutura de OU totalmente nova, não se prenda muito ao design; contanto que seus objetos sejam divididos logicamente, não será muito difícil mover OUs. Coloque um pouco de esforço no início e você terá um resultado fácil de navegar e usar.
Esta também é uma tarefa contínua – manutenção e revisões são necessárias para manter seu ambiente limpo e seguro. Ter um usuário ou computador na unidade organizacional errada é mais do que apenas desordenado, pode ser a aplicação de diferentes políticas de grupo que não bloqueiam o ambiente da maneira que você espera. Vale a pena investigar a automação nesta área também, e Adaxes pode ajudar a controlar fluxos de trabalho, regras de negócios e tarefas agendadas para evitar erros.
Apresentação/Demonstração ADAXES
Publicado por: Adam Fowler – IT-Admin
Link: https://www.adaxes.com/blog/choosing-an-ou-design-that-works-for-you.html
Palavras chaves: adaxes, automacao, OU, design, exemplo, AD, active directory