Design da OU do Active Directory para <500 usuários, 4 locais

Estamos procurando adicionar alguma estrutura lógica à nossa hierarquia de AD (Win 2003). Temos um único domínio e cerca de 500 usuários. Todos os usuários e computadores estão atualmente organizados em uma OU. Todos os grupos de segurança e distribuição estão em uma segunda OU. A associação ao grupo é essencialmente baseada no usuário individual, sem aninhamento de grupos.

Minhas perguntas:

1. Para uma organização desse tamanho, vale a pena definir uma hierarquia de OUs com base no departamento, geografia e / ou classe de objeto (ou seja, computadores, usuários, grupos) e mover os usuários, computadores e grupos para as OUs relevantes?
2. Se sim, como você estruturaria a hierarquia, por exemplo, departamento-> localização-> classe de objeto?
3. Devemos aninhar grupos, quando apropriado, para melhor mapeamento para funções de aplicativos corporativos e entradas de endereço do Exchange?

Aqui estão os principais princípios da recomendação da Microsoft para o design lógico do AD:

• Projete primeiro para delegação de controle, porque é baseado nas permissões do AD e é o eixo mais inflexível a ser modificado. Se você não estiver delegando o controle, não se preocupe com isso (mas eu planejaria isso de qualquer maneira - mesmo em uma organização tão pequena que você possa precisar de usuários designados nas filiais para redefinir senhas, etc).

• Design segundo para aplicação da diretiva de grupo. A filtragem do aplicativo de diretiva de grupo pela associação ao grupo de segurança permite que um GPO seja aplicado apenas a um subconjunto dos objetos de usuário ou computador abaixo do ponto em que está vinculado no diretório, para que esse eixo tenha mais flexibilidade do que as permissões do AD.

• Design por último para organização e facilidade de uso. Facilite a localização de coisas para você e outros administradores.

Pense em cada uma dessas considerações ao projetar, priorizando-as conforme recomendado. É fácil mudar as coisas mais tarde (comparativamente) e você nunca "acertará" na primeira tentativa. Antes de eu mesmo DCPROMO, meu primeiro controlador de domínio, tipicamente desenhar a estrutura proposta em papel ou em um quadro branco e percorrer os cenários de uso em potencial para ver se meu design "se mantém". É uma ótima maneira de eliminar problemas em um design.

(Também não se esqueça do aplicativo de diretiva de grupo nos objetos do site. Você deve ter cuidado com o aplicativo GPO entre domínios ao vincular GPOs nos sites, mas se você for um ambiente de domínio único, poderá obter ótimos resultados. funcionalidade ao vincular GPOs a sites.Trabalhe com alguns cenários de exemplo com ele - acho que é ótimo para carregar software com configurações "específicas do site" ou fornecer scripts de logon específicos para usuários ao fazer logon em computadores em determinados locais. locais físicos, por meio do processamento da diretiva de grupo de loopback.)

Eu sempre dividia usuários, computadores e grupos em OUs separadas, pelo simples motivo de facilitar o gerenciamento.

Se você não tiver um motivo convincente para uma estrutura específica do AD, projete-o do ponto de vista administrativo. Pense em onde você aplicará políticas.

Se você estiver aplicando a maioria de suas políticas no nível do departamento, use Department \ Location \ Object

Se você estiver aplicando a maioria de suas políticas no nível do local, use Localização \ Departamento \ Objeto

Se você fizesse o contrário, isso significaria que você teria que vincular suas políticas em várias UOs, o que envolve trabalho desnecessário.

Aninhar grupos é perfeitamente adequado e, novamente, facilita muito o gerenciamento do AD.

Costumo projetar estruturas de AD com 'facilitando o gerenciamento' em mente, em vez de refletir a estrutura física da empresa, no entanto, ambas são geralmente as mesmas.

Eu acho que, se eu tivesse que redesenhar meu anúncio novamente, há algumas coisas que eu faria de maneira diferente, mas descobri que:

Usuários - Divida as teses em departamentos, mas também com uma área / s para funcionários temporários ou de agências. A localização destes não será tão importante quanto as pessoas se movimentarão.

Computadores - divida-os em locais e subalimentos. Ou seja, OfficeComputers / LondonOffice / Room103 (Finanças). Isso significa que você pode aplicar configurações a um local ou escritório - por exemplo, um servidor proxy diferente ou configurações antivírus diferentes (é claro, apenas se o programa de gerenciamento AV usar o AD) - sem reorganizar e, esperançosamente, não será necessário abrir o lata de worms em processamento de loopback.

Também achei útil não usar grupos de usuários ou computadores embutidos, nenhum problema técnico, mas apenas para que você possa ver facilmente onde as coisas não deveriam estar.

Finalmente, divida seus servidores também, procurei o local / função que parece ter funcionado muito bem.

Como já foi respondido, aqui está minha pequena amostra, lembre-se de que não há certo ou errado, tudo depende das necessidades - ou seja, organização ou localização primeiro? Prefiro a função organizacional primeiro, mesmo para computadores / funções de servidor. Também gosto da capacidade de indicar uma única UO para obter todos os funcionários e nenhum lixo para preencher as listagens de funcionários da intranet. Sinta-se livre para editar!

• Pessoas (usuários / tipo = pessoa)
  • interno
    • Departamento A
      • Localização X
      • Localização Y
    • Departamento B
    • Departamento C
  • Externo
    • Empresa 1
    • Empresa 2
• Máquina (usuários / tipo = qualquer computador incluindo)
  • Cliente
    • Computadores portáteis
    • Desktops
  • Servidor
    • Inscrição
      • Local T
      • Local V
    • A infraestrutura
    • Base de dados
  • Serviço
  • Contas administrativas (se usadas)
• Listas (grupos e contatos)
  • Contato
  • Distribuição
  • Segurança

Eu apenas os dividiria por local neste caso. A estrutura da OU resultante seria algo parecido com isto:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

etc.

Realmente não vejo necessidade de mais divisões aqui, por exemplo, por Departamento, pois isso geraria uma sobrecarga administrativa adicional sem realmente dar muito em troca. A divisão por local, no entanto, permitiria implementar a delegação em cada site.

Uma linha de guia que eu uso é: Usuários; organizar de acordo com os grupos do chartflow de RH; organizar de acordo com o fluxo de trabalho Computadores; organizar de acordo com a localização geográfica

As outras respostas neste tópico também são muito boas.