Active Directory: Estruturas do Active Directory

Como o simples geralmente é o melhor, considere utilizar um layout mais criativo na sua infraestrutura do Active Directory.

Brien M. Posey

Uma coisa que sempre me surpreendeu ao olhar de implantações do Active Directory do mundo real: Embora certamente existam exceções, na maioria dos casos, as organizações ficar com a configuração mais simples, com o qual eles podem realisticamente fugir.

De certa forma, isso não deve ser uma surpresa. Faz-me lembrar um professor universitário que muitas vezes disse que deve viver de acordo com o princípio da KISS-Keep It Simple, Stupid. Talvez em nenhum lugar este princípio se aplica com mais precisão do que o mundo dele.

Qualquer profissional de TI experiente sabe manter as coisas simples reduz as chances de ter problemas. Ele também torna muito mais fácil de solução de problemas quando algo der errado. Enquanto eu vou ser o primeiro a admitir que há algo a ser dito para a simplicidade, quando se trata de infra-estrutura do Active Directory, você pode ser melhor servido por uma estrutura mais criativa.

Não há absolutamente nada de errado com o uso de uma topologia padrão do Active Directory. Há uma razão que a Microsoft fez a topologia padrão o padrão. Estes projetos um pouco mais detalhados, no entanto, podem ser mais apropriados para grandes organizações, a necessidade de segregar as responsabilidades de gestão.

Domínios de usuário

Na maioria das configurações de Active Directory do mundo real, a estrutura de domínio imita a estrutura geográfica da organização. Por exemplo, se uma organização tem três escritórios, é provável que tenha três domínios. Que certamente não quer dizer que cada organização utiliza este projeto, mas é o tipo mais comum de estrutura do Active Directory. Enquanto geográficas topologias do Active Directory são comuns e realmente eficaz, talvez também queira considerar algumas estruturas de domínio alternativos.

Como você está sem dúvida consciente, Active Directory é realmente nada mais do que um banco de dados elaborado. Um banco de dados do Active Directory é preenchido com vários tipos de objetos. Cada objeto é atribuído a um ou mais atributos. Algumas organizações basear sua estrutura de domínio em tipos específicos de objetos do Active Directory. Um exemplo claro deste tipo de classificação é domínios do usuário.

Um domínio de usuário é um domínio do Active Directory que tem a finalidade de gerenciar contas de usuário. Para se ter uma idéia de por que isso é útil, considere uma das empresas onde eu costumava trabalhar. Essa organização particular tinha alguns milhares de usuários. Havia sempre uma alta taxa de rotatividade de funcionários. Conseqüentemente, a organização empregadas duas pessoas cujo trabalho era criar, configurar e remover contas de usuário.

Este tipo de situação, um domínio de usuário provou útil. Este tipo de estrutura de domínio dá aos usuários encarregados de conta manutenção total controle administrativo sobre as contas de usuário. Ele, no entanto, dão acesso a outros objetos do Active Directory ou funções.

Existem outras maneiras de realizar este tipo de isolamento do direito administrativo. Mesmo assim, uma estrutura de domínio do usuário pode ajudar uma organização para ficar melhor organizado. Se nada mais, ele ajuda a tornar os domínios individuais que menos confuso. Ele também fornece uma sensação de isolamento físico de administrativo. Algumas organizações talvez prefira isso o isolamento lógico administrativo que pode ocorrer quando vários tipos de objetos residem em um domínio comum.

Domínios de recursos

Domínios de recursos são semelhantes aos domínios do usuário. Estas são a única finalidade na natureza e utilizada para melhorar a segurança ou fazer a estrutura do Active Directory mais lógica ou mais gerenciáveis. Existem implantações de Active Directory do mundo real em que todos os computadores desktop são agrupados em um domínio de recurso dedicado. Existem também outros domínios de recurso usados para outros tipos de recursos. Por exemplo, uma organização colocou todos os seus servidores que executam o seu principal aplicativo (LOB) de linha de negócios em um domínio de recurso dedicado.

Domínios de recurso são provavelmente o mais útil quando eles são tratados como domínios de gestão. Por exemplo, eu criei uma floresta do Active Directory dedicada, projetada para funcionar puramente como um domínio de gerenciamento para meus servidores Hyper-V. Existem algumas razões por que optei por fazer isso.

A primeira é uma razão de gestão. System Center Operations Manager 2012 (e um número de outros produtos de gestão) podem apenas gerenciar servidores que são membros de um domínio do Active Directory. Eu não quero juntar meus servidores Hyper-V para meu domínio principal, porque todos os meus controladores de domínio para o meu domínio principal são virtualizados. Eu não queria correr o risco de não ser capaz de fazer logon em um servidor de Hyper-V simplesmente porque os DCs virtuais estavam offline. Juntando-se os servidores Hyper-V para uma floresta de gerenciamento do Active Directory dedicada resolveu este problema.

A outra razão que eu escolhi para criar um domínio de recurso dedicado para meus servidores Hyper-V tem a ver com algumas das novidades chegando no Hyper-V versão 3.0. Dentre as características do Hyper-V 3.0 que eu estou mais animado é a capacidade de replicar uma máquina virtual (VM) do host de um servidor para outro.

Este tipo de replicação não é necessariamente uma solução de cluster de failover, mas sim uma solução de recuperação de desastres que pode ajudá-lo a manter uma cópia atualizada de suas VMs em um servidor de host alternativo. Se algo acontecesse a uma matriz de disco ou primário host Hyper-V, há uma outra cópia do seus VMs que você pode cair para trás sobre. Para utilizar esse recurso, no entanto, o servidor host e o servidor de réplica devem ser autenticados.

A maneira mais fácil de fornecer esta autenticação é juntar ambos os servidores em um domínio comum e usar Kerberos. Como tal, a criação de um domínio de recurso dedicado para servidores Hyper-V faz todo o sentido. Isto é especialmente verdadeiro quando você considera que há outros recursos do Hyper-V que também exigem a participação no domínio.

Recursos domínios e domínios do usuário não são mutuamente exclusivos, a propósito. Algumas organizações usam uma combinação de domínios de usuário e domínios de recurso dentro de uma floresta do Active Directory comuns. Ambos têm seus pontos fortes, e você pode aplicar ambos conforme necessário.

Topologia geográfica

A grande maioria das implantações do Active Directory no mundo real é baseada na estrutura geográfica. Por exemplo, uma organização com cinco filiais pode usar cinco domínios separados — um para cada serviço que inclui todas as máquinas físicas dentro desse escritório. Tecnicamente, não há nada de errado com o uso deste tipo de topologia do Active Directory, mas existem algumas coisas que você deve considerar.

Em primeiro lugar, é importante não confundir a estrutura de domínio com a estrutura do site. A estrutura do site do Active Directory sempre deve imitar a topologia geográfica de uma organização. Para cada ligação de rede (WAN) de área ampla entre escritórios, deve haver um link de site correspondente no Active Directory. Além disso, os computadores que estão localizados dentro de um escritório físico devem ser colocados dentro de um site do Active Directory comuns. Idealmente, cada local deve usar uma sub-rede dedicada, pois você não pode ter uma única sub-rede abrangem vários sites do Active Directory.

A estrutura do site do Active Directory é tão importante é porque a estrutura do site tem um impacto direto no volume de tráfego de replicação do Active Directory que pode fluir entre os links WAN. Por exemplo, imagine uma organização tem várias filiais, mas ele escolheu configurar seu Active Directory como um único domínio. Mais uma vez, tecnicamente não há nada de errado com essa abordagem, mas pode ser ineficiente.

Em uma situação como aquela, atualizações para o Active Directory potencialmente poderiam ser feitas para qualquer controlador de domínio gravável em qualquer lugar dentro da organização. Quando ocorre uma atualização, cabe esse DC para fazer a atualização disponível para os outros DCs.

Porque esta organização não fazer uso de uma estrutura de site adequada, uma atualização comum não será capaz de passar através de um link WAN várias vezes. Por exemplo, se houvesse cinco DCs em uma filial, então uma atualização de Active Directory poderia potencialmente ser enviada através da ligação WAN cinco vezes separado, uma vez para cada DC.

Um controlador de domínio em cada site do Active Directory funciona como um servidor bridgehead. Emprego do servidor bridgehead é receber as atualizações do Active Directory de através da ligação WAN. Em seguida, distribui as atualizações para outros DCs dentro do site. Isso significa Active Directory atualizações só precisa ser enviado para cada filial uma vez, independentemente de quantos DCs existiria dentro dessa filial.

E quanto a organizações que usam um domínio separado para cada filial? Se cada filial tem uma floresta do Active Directory dedicada, então você não precisa se preocupar com a definição de sites do Active Directory. Por outro lado, se cada domínio é um membro de uma floresta comum, então você definitivamente deve implemente uma estrutura de site do Active Directory apropriada como uma forma de manter o tráfego de replicação do nível de floresta do Active Directory em cheque.

Há muitas maneiras diferentes de configurar uma topologia de domínio do Active Directory. Finalmente, você deve escolher a topologia que faz mais sentido para a disposição física de sua organização e infra-estrutura de rede. Isso pode ser um modelo de domínio único ou um modelo de vários domínios que baseia-se na proximidade geográfica, usuários ou mesmo recursos.

Brien M. Posey

Brien PoseyMVP, é um escritor técnico freelance com milhares de artigos e dezenas de livros para o seu crédito. Você pode visitar o site de Web do Posey em brienposey.com.

Conteúdo relacionado