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

Question

Estamos procurando adicionar alguma estrutura lógica à nossa hierarquia do AD (Win 2003). Nós 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 feita por usuário individual, sem aninhamento de grupos.

Minhas perguntas:

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

Answer 1

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

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

• Design em segundo lugar para aplicação da política de grupo. Filtrar o aplicativo de diretiva de grupo por associação de grupo de segurança permite que um GPO seja aplicado apenas a um subconjunto do usuário ou objetos do computador abaixo do ponto em que está vinculado no diretório, portanto esse eixo tem mais flexibilidade 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 para 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 vai "acertar" na primeira tentativa. Antes mesmo de eu DCPROMO meu primeiro controlador de domínio eu costumo tirar a estrutura proposta em papel ou um quadro branco e percorrer possíveis cenários de uso para ver se o meu projeto "se mantém". É uma ótima maneira de eliminar problemas em um design.

(Não se esqueça do aplicativo de diretiva de grupo nos objetos do site. Você deve ter cuidado com o aplicativo de GPO entre domínios ao vincular GPOs em sites, mas se for um ambiente de domínio único, poderá obter um Muitas ótimas funcionalidades fora da vinculação de GPOs a sites.Trabalhe com alguns exemplos de cenários com ele-- Eu acho que é ótimo para carregar software que tenha configurações "específicas do site" ou fornecer scripts de logon específicos para os usuários quando fizerem logon computadores em determinados locais físicos, por meio de processamento de diretiva de grupo de loopback.)

    

Answer 2

Eu sempre dividia usuários, computadores e grupos em unidades organizacionais separadas, pelo simples motivo de que isso facilita o gerenciamento.

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

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

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

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

O aninhamento de grupos é perfeitamente adequado e, mais uma vez, facilita muito o gerenciamento do AD.

Eu tenho a tendência de projetar estruturas de DA com 'facilitando o gerenciamento' em mente, em vez de refletir a estrutura física da empresa, no entanto ambas são geralmente as mesmas.

    

Answer 3

Acho que, se eu tivesse que reprojetar meu anúncio novamente, há algumas coisas que faria diferente, mas descobri que:

Usuários - Divida as teses em departamentos, mas também com uma área / s para funcionários temporários ou da agência. O local para estes não será tão importante quanto, sem dúvida, as pessoas se movimentarão.

Computadores - Divida-os em locais e sub-locais. 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, somente se o programa de gerenciamento de antivírus usar o AD) - sem reorganizar e, com sorte, não precisará abrir o lata de worms que é o processamento de loopback.

Também achei útil não usar os usuários internos ou grupos de computadores, nem problemas técnicos, mas apenas para que você possa ver facilmente onde as coisas não deveriam estar.

Finalmente, divida seus servidores também, eu escolhi a localização / função que parece ter funcionado muito bem.

    

Answer 4

Como já foi respondido, aqui está a minha opinião para um pequeno exemplo, lembre-se que não há certo ou errado, tudo depende das necessidades - ou seja, organização ou localização primeiro? Eu prefiro primeiro o papel organizacional, mesmo para papéis de computadores / servidores. Também gosto da capacidade de apontar uma única UO para obter todos os funcionários e nenhum lixo para preencher listas de funcionários da intranet. Sinta-se à vontade 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 incluindo computadores)
  • Cliente
    • Laptops
    • Desktops
  • servidor
    • Aplicativo
      • Localização T
      • Localização V
    • Infraestrutura
    • Banco de dados
  • Serviço
  • Contas administrativas (se usadas)
• Listas (grupos e contatos)
  • Contato
  • Distribuição
  • Segurança

Answer 5

Eu acabei de dividi-los por local nesse caso. A estrutura da OU resultante seria algo como isto:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

etc.

Eu realmente não vejo necessidade de mais divisões aqui, por exemplo pelo Departamento, pois geraria sobrecarga extra de administração sem realmente dar muito em troca. A divisão por localização, no entanto, permitiria que você implementasse a delegação em cada site.

    

Answer 6

Uma linha de guia que uso é: Comercial; organizar de acordo com o fluxo gráfico de RH Grupos; 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.