Quando você realmente precisa de uma unidade organizacional no Active Directory?

Question

Eu tenho que conceder algumas permissões para um determinado usuário no Active Directory do Windows Server 2003 que só estará ativo em uma determinada coleção de usuários. O pensamento inicial era apenas ter uma UO que permitisse a esse determinado usuário determinados direitos (criação de usuário, redefinição de senha, adição de usuários a grupos, etc.). No entanto, depois de ler mais sobre as coisas, não tenho certeza se uma OU é necessária ou não, e realmente não tenho certeza de quando uma OU seria necessária. Isso está me incomodando e eu realmente gostaria de entender melhor o propósito das OUs antes de usar ou não usá-las.

Eu pesquisei bastante na Web e os resultados variam do vago "Use unidades organizacionais para organizar o AD" para o algo específico " Adicione uma OU a um domínio se um grupo completamente separado precisar de acesso administrativo especial a um segmento de usuários. " Neste ponto, o último parece o mais apropriado aqui. Tecnicamente falando, você só pode usar o Assistente de Delegação de Controle em uma UO. No entanto, não vejo nada que me impeça de atribuir manualmente as permissões individualmente a um grupo de domínios e efetivamente ter a mesma coisa. O que estou perdendo aqui? Obrigado.

    

Answer 1

Em geral, as OUs são usadas para:

• Mantendo as coisas limpas e estruturadas. Seus usuários são mantidos longe de grupos, seus grupos são mantidos longe de computadores, objetos no site A são mantidos longe de objetos no site B e assim por diante.

• Delegação de controle. Só é realmente necessário se você tiver vários níveis de acesso ou vários sites com administradores diferentes em cada um. Mesmo assim, planejaria com antecedência e configuraria as coisas para ativá-lo de qualquer maneira.

• Políticas de grupo. Não é totalmente necessário, pois o aplicativo de política pode ser gerenciado por meio de permissões ou filtros WMI, mas, mesmo assim, ajuda saber que, se um usuário estiver em UO X, ele obterá a política Y.

Observe que, acima, você não pode aplicar um GPO a um contêiner; portanto, se você não criar UOs, precisará definir todos os GPOs no nível superior (do domínio) e filtrá-los usando o WMI ou a segurança. É mais fácil para você e para todos os outros usuários apenas usar UOs, exceto se você tiver um cenário em que as políticas específicas que deseja / precise não puderem ser feitas (ou podem ser feitas, mas estão confusas) usando um modelo OU .

Além dos requisitos técnicos óbvios nos meus últimos dois pontos, acho que manter as coisas limpas e arrumadas é razão suficiente. É mais fácil encontrar o objeto que você quer em uma lista de 100 do que encontrá-lo em uma lista de 1500, por exemplo. Ele também separa os objetos que você cria (usuários, computadores e grupos, principalmente) de objetos embutidos, o que pode ajudar a evitar acidentes desagradáveis ("OK, quem apagou a conta de administrador?").

    

Answer 2

OUs são usadas para organizar objetos no Active Directory. Um exemplo típico seria o seguinte:

myDomain.loc
├─Users
├─Servers
│ ├Domain Controllers
│ └Member Servers
└─Workstations
  ├New York
  ├London
  └Brisbane

Isso torna mais fácil diferenciar visualmente os objetos no domínio, em vez de confiar na memória ou em escavar. Usando essa estrutura, você também pode aplicar políticas a contêineres específicos. Você pode ter uma política geral do Internet Explorer aplicada à UO Estações de Trabalho, de modo que se aplique a todos os objetos filho dessa árvore. Em seguida, você pode definir configurações específicas do Internet Explorer para as subunidades organizacionais (por exemplo, políticas diferentes que definem a home page do IE para estações de trabalho em Londres, além de definir uma página inicial diferente para as estações de trabalho novas etc.)

No seu exemplo específico, parece que você deseja delegar o controle do AD para um grupo de usuários. Nesse caso, o método correto é criar um novo grupo de segurança e tornar todos os usuários-alvo um membro desse grupo. Em seguida, abra os Usuários e Computadores do AD, clique com o botão direito do mouse na UO que deseja que os usuários / grupo controlem e selecione Delegar Controle.

Agora ... se você organizar seu AD adequadamente, poderá ter um controle granular sobre o controle do qual deseja controlar o grupo de usuários. Por exemplo, você poderia criar um grupo chamado NewYork-Admins e delegar o controle para esse grupo APENAS para as estações de trabalho de Nova York, em vez de todas as estações de trabalho.

Uma estrutura ideal do AD para esse tipo de delegação seria uma estrutura como a seguinte:

myDomain.loc
├─Domain Controllers
├─Special Users
└─Locations
  ├─New York
  │ ├─Users
  │ ├─Workstations
  │ ├─Servers
  │ ├─Contacts
  │ ├─Servers
  │ └─Groups
  ├─London
  │ ├─Users
  │ ├─Workstations
  │ ├─Servers
  │ ├─Contacts
  │ ├─Servers
  │ └─Groups
  └─Brisbane
    ├─Users
    ├─Workstations
    ├─Servers
    ├─Contacts
    ├─Servers
    └─Groups

Isso permite que você delegue o controle a objetos do AD de uma maneira muito granular.

    

Answer 3

Eu criei duas UOs, uma para armazenar "Funcionários" e outra para armazenar clientes que precisam se autenticar em nossos servidores FTP.

O motivo pelo qual usei OUs é que alguns dos meus dispositivos podem ser autenticados em relação ao LDAP, mas não (parece?) reconhecer apenas a associação ao grupo. Além disso, "sentia" melhor isolar as contas externas. Se eu tivesse uma infraestrutura maior com mais clientes, teria criado seu próprio domínio para eles.