Pré-Requisitos: Conhecimento de grupos, tipos de grupos e dos fundamentos do Active Directory.

Metodologia: Considerações para o projeto de Unidades Organizacionais.

Feito o projeto da estrutura de domínios da empresa, é hora de começar a projetar a estrutura de unidades organizacionais (OUs) para cada domínio. O uso de OUs permite fazer uma divisão dos domínios de acordo com diferentes critérios. Podem ser utilizados critérios geográficos, funcionais, de segurança e assim por diante.

É importante salientar que cada domínio pode ter a sua própria estrutura de OUs, diferente dos demais domínios da empresa. Ou seja, o administrador de cada domínio tem liberdade para definir uma estrutura de OUs que atenda as necessidades dos usuários do domínio.

O conceito de OUs foi introduzido no Windows 2000 Server, juntamente com o Active Directory e veio para solucionar um dos principais problemas do Windows NT Server 4.0: a descentralização de tarefas administrativas.

Com o NT Server 4.0, não havia como atribuir permissões de acesso apenas em uma parte do domínio. Por exemplo, imagine um domínio formado pelas redes de vários escritórios dentro do estado de SP. No NT Server 4.0 não haveria como atribuir permissões administrativas para o usuário de Campinas, por exemplo, somente nas contas de usuários e computadores da rede de Campinas, para o administrador de Ribeirão Preto somente nas contas de usuários da rede de Ribeirão Preto e assim por diante. Isso não era possível de ser feito no NT Server 4.0. Ou você atribuía permissões de Administrador no domínio inteiro ou não tinha como atribuir permissões de administrador para um usuário apenas em partes da rede.

Imagine uma empresa que tem uma rede, com filiais em todos os estados brasileiros. Por questões de simplicidade vamos supor que a rede é composta de seis domínios, sendo que em cada domínio estão as filiais de 4 ou mais estados. Vamos supor que um dos domínios seja composto pelas redes das filiais do RS, SC, PR e SP. Com o NT Server 4.0, você não teria como definir que um usuário tivesse permissões de Administrador somente nos servidores da filial do RS. Uma vez que você atribuía permissões de Administrador, o usuário teria estas permissões em todos os recursos do domínio. No nosso exemplo, o usuário seria Administrador nos servidores das filiais do RS, SC, PR e SP, ou seja, em todos os servidores do domínio.

Esta situação gerava inconvenientes muito sérios. Era comum a situação onde um domínio tinha 10 ou mais contas de usuários com permissão de Administrador do domínio. Ora, eram 10 ou mais contas com permissões total em todos os servidores  e recursos do domínio. Nada bom.

Com a disponibilidade de Unidades Organizacionais, a partir do Windows 2000 Server, este problema foi minimizado. Com o uso de OUs, o administrador pode criar, dentro do domínio, várias Unidades organizacionais. Em seguida o administrador pode mover para dentro de cada unidade organizacional, as contas de usuários e computadores, de acordo com critérios geográficos ou funcionais. Em seguida é possível delegar tarefas administrativas a nível de Unidade organizacional (OU – Organizational Unit).

Neste item vou apresentar algumas recomendações que devem ser levadas em consideração quando do projeto das Unidades Organizacionais de um domínio.

Qual a estrutura de um domínio logo após a sua criação?

Ao instalar o Active Directory no primeiro DC de um domínio, momento em que é criado o domínio, são criados alguns containers padrão. (um container é um objeto que contém outros objetos. Por exemplo, uma pasta é um container, pois pode conter outras pastas e arquivos.). Na Figura 6.15 é exibida uma visão geral dos containers criados, automaticamente, quando da criação do domínio:

Figura 6.15 Estrutura padrão de um novo domínio.

A seguir descrevo o conteúdo de cada uma destas opções:

• Builtin: Nesta opção estão os grupos criados automaticamente (chamados Builtin groups) durante a instalação do Active Directory. Por exemplo, estão neste containers os grupos locais do domínio, tais como: Administrators (Administradores), Backup Operators (Operadores de cópia), Server Operators (Operadores de servidores) e assim por diante.
• Computers: Nesta opção estão as contas de computadores. Servidores (com exceção dos DCS) e estações de trabalho com o NT 4.0 (Server ou Workstation), Windows 2000 (Professional ou Server), Windows XP Professional ou Windows Server 2003, que pertençam ao domínio, terão contas de computador nesta opção. Quando você configura uma estação de trabalho para fazer parte do domínio, é criada (se já não existia previamente), uma conta de computador com o mesmo nome host do computador. Por exemplo, ao configurar uma estação de trabalho chamada micro01, para fazer parte do domínio abc.com, será criada uma conta chamada micro01. Esta conta será criada no container Computers.
• Domain Controllers: Nesta opção ficam as contas de computador de todos os DCs do domínio. Esta separação é importante por diversos fatores. O principal deles é segurança, pois ao separar as contas dos DCS, é possível protege-las de uma maneira mais eficiente, atribuindo permissões de acesso ao container Domain Controllers. Outro motivo é que estando em containers separados, é possível aplicar diferentes políticas de segurança, em relação aos demais computadores do domínio.
• ForeignSecurityPrincipals: Este contêiner contém objetos relacionados com as relações de confiança criadas manualmente entre domínios (não confundir com as relações de confiança, criadas e mantidas automaticamente pelo Active Directory, entre os domínios de uma árvore de domínios). Quando um administrador criar relações de confiança, manualmente, com domínios externos, o Active Directory, cria objetos que dão suporte á relação de confiança. Estes objetos são criados na opção ForeignSecurityPrincipals. Estes objetos são criados e mantidos pelo Active Directory, você não deve altera-los e nem excluí-los, pois isso poderia fazer com que a relação de confiança, relacionada com o objeto alterado ou excluído, deixe de funcionar.
• Users: Neste container, por padrão, estão as contas de usuários criadas automaticamente durante a criação do domínio, os grupos Globais do domínio, criados automaticamente e grupos universais criados automaticamente (dependendo do nível de funcionalidade do domínio e da floresta). Neste container também são criados, automaticamente, grupos para funções específicas. Por exemplo, quando o WINS é instalado, é criado, neste container, um grupo Global do domínio, chamado WINS Users (Usuários do WINS).

Além destes containers básicos, uma série de outros containers são criados, quando da criação do domínio. Porém estes containers não são exibidos por padrão. Para exibi-los, você deve selecionar o comando View -> Advanced Features (Exibir -> Recursos avançados), no console Active Directory Users and Computers (Usuários e Computadores do Domínio). Ao selecionar este comando, novos containers serão exibidos, conforme indicado na Figura 6.16:

Figura 6.16 Exibindo recursos avançados do Active Directory.

Observe que são exibidas as seguintes opções avançadas:

• LostAndFound: Esta pasta contém objetos para os quis o container no qual o objeto foi criado, foi deletdo do servidor atual, ao mesmo tempo em que o objeto estava sendo criado em outro servidor. Por exemplo, você criar um usuário chamado jsilva, na OU teste, do DC srv01. Um administrador exclui a OU teste no servidor srv02. Quando o servidor srv01 replicar com o servidor srv02, a conta do usuário jsilva será replicada do servidor srv01 para o servidor srv02. Mas acontece que a OU teste (na qual o usuário jsilva foi criado, no servidor srv01), não existe mais no servidor srv02. Neste caso, a conta do usuário jsilva irá parar no container LostAndFound.
• NTDS Quotas
• Program Data: Pode conter dados de configurações de aplicativos. Eu acredito (palpite meu, nada oficial), que com o tempo a Microsoft pretenda deslocar as configurações da registry para o Active Directory. Mas aí teria que ser resolvida a questão de como configurar servidores que não são DCs, ou seja, que não tem o Active Directory instalado. Talvez fosse possível que os vários computadores da rede armazenassem suas configurações no banco de dados do Active Directory, no servidor. Esta idéia seria bem interessante, ou seja, ter um repositório centralizado de configurações. Fácil de gerenciar, de administrar, de garantir o backup. Não seria má idéia. Mas são só especulações, não tenho conhecimento de nada oficial neste sentido.
• System: Contém configurações para uma série de serviços do Windows Server 2003, tais comoIpSec, configurações do DFS (Distributed File System –veja Capítulo 11 e assim por diante.

Bem, estes são os containers (também poderíamos chamar de OUs, embora tecnicamente não sejam OUs) criados, automaticamente, quando da criação de um domínio. Para redes pequenas, digamos de até 100 usuários, a utilização somente dos containers padrão seria mais do que satisfatória (a não ser que existam exigências específicas de segurança ou de aplicar diferentes configurações para diferentes grupos de usuários). Porém para redes maiores, certamente, o uso de OUs para separar e organizar os recursos do domínio, é de fundamental importância.

Para redes maiores, apenas o uso dos containers padrão não é suficiente. Colocar todas as contas de usuários em um único container (muitas vezes milhares de contas), onde uma meia-dúzia ou mais de administradores faz alterações, definitivamente não é uma boa solução. Sem contar que se um belo dia uma conta for excluída, por engano, será uma meia-dúzia de suspeitos a serem investigados. Brincadeiras à parte, para grandes redes, o uso de OUs permite uma separação, uma divisão dos recursos da rede. Além disso é possível designar administradores para atuar somente em uma OU específica, de tal maneira que um administrador somente possa alterar, excluir ou incluir novos objetos na OU da sua unidade, sem ter acesso aos objetos das demais OUs do domínio.

Outro fator que pesa muito a favor da criação de OUs é a necessidade de fornecer diferentes configurações para computadores de diferentes seções. Por exemplo, os usuários do atendimento podem precisar de um determinado conjunto de programas e devem ter restringido o acesso a determinadas opções do Windows, bem como devem ser impedidos de instalar novos programas. Já usuários do setor de pesquisa precisam de um outro conjunto de programas e devem ter liberdade para instalar novos programas e alterar as configurações dos seus computadores. Vejam que são necessidades bem distintas. Ficaria difícil (para não dizer impossível), atende-las, sem a separação das contas de usuários e computadores de cada seção em diferentes OUs.

Estes problemas, ou seja, descentralizar a administração e aplicar diferentes políticas de segurança e configurações para diferentes grupos de usuários, podem ser resolvidos como uso de OUs. Criam-se OUs separadas para cada grupo. Em seguida move-se as contas de usuários e computadores de cada grupo para a respectiva OU. O próximo passo é delegar tarefas administrativas em cada OU, somente para o administrador responsável na OU, usando o Assistente para delegação de tarefas, descrito anteriormente. Já para o problema das diferentes configurações, aplicam-se diferentes GPOs (Group Polices Objects) para cada OU. GPOs será assunto para o Capítulo 18.

Com o que foi exposto, podemos resumir as vantagens do uso de OUs, da seguinte maneira:

• Unidades Organizacionais representam unidades separadas de gerenciamento, sendo possível delegar permissões de administração e aplicar diferentes configurações a nível de OU, conforme descrito anteriormente.
• Unidades organizacionais representa diferentes unidades de configuração, pois é possível aplicar GPOs a nível de unidades organizacionais.

Um fator muito importante a ser considerado é que a utilização de OUs faz diferença somente para a equipe de TI. O usuário nem sequer fica sabendo se a sua conta está no OU Users ou em uma OU criada pelo administrador. Na verdade a grande maioria dos usuários não tem (e nunca terá) a mínima idéia do que seja uma OU e de que sua conta de usuário e a conta do seu computador está dentro de uma OU. A criação de OUs tem por finalidade facilitar a administração dos recursos de um domínio, permitindo, principalmente, que seja possível delegar tarefas administrativas para partes específicas do domínio e aplicar diferentes configurações a cada OU, através do uso de GPOs – Group Policy Objects.

Mais uma vez, a exemplo do que foi dito para o projeto de domínios, a palavra chave no projeto de OUs é: SIMPLICIDADE. Você pode ficar tentado a criar uma estrutura de OUs para representar exatamente a organização da empresa, criando dois ou três níveis de OUs, uma dentro da outra. Para não cair nesta armadilha, basta lembrar do parágrafo anterior. O uso de OUs é uma ferramenta para o administrador da rede, para que ele possa delegar permissões para tarefas administrativas a nível de OU e para aplicar configurações personalizadas usando GPOs. O objetivo das OUs não é espelhar exatamente a organização ou a estrutura geográfica da empresa.

Uma vez que foi decidido o critério a ser utilizado (e na grande maioria das situações, o critério que prevalece, para o projeto de OUs é o critério geográfico), o ideal é que você comece com um modelo bem simples, apenas com algumas OUs que refletem os critérios selecionados. Por exemplo, imagine que você administra a rede de uma empresa que tem a filial na Cidade de São Paulo e escritórios no Rio de Janeiro, Porto Alegre e Curitiba. A rede é baseada em domínio único, tendo 150 usuários na matriz em SP, e cerca de 100 usuários em cada uma das filiais. Um dos objetivos do projeto é delegar permissões administrativas, tais como desbloquear contas de usuários e criar e gerenciar grupos. Ou seja, em cada escritório você gostaria de ter um administrador com permissões específicas, principalmente para administrar as contas de usuários e grupos da própria filial. Este é um exemplo típico onde o uso de OUs é exatamente a solução indicada. Você poderia criar uma OU para cada localidade: SP, RJ, Porto Alegre e Curitiba. Em seguida mover as contas de usuários e grupos para as respectivas OU. O passo final é executar o agente para delegação de controle (clique com o botão direito do mouse na OU e selecione Delegate Control..., conforme explicado anteriormente), para atribuir as permissões de gerenciar contas e grupos para um usuário de cada filial. Com isso você mantém o controle centralizado do domínio, pois os usuários de cada filial não tem contas de administradores do domínio, apenas receberam permissões para executar tarefas específicas com os objetos dentro de sua OU. Além disso você consegue descentralizar algumas tarefas que serão melhor realizadas por usuários locais, de cada escritório.  Nesta mesma configuração, você poderia usar GPOs, para aplicar diferentes configurações, distribuir um conjunto diferente de programas e aplicar diferentes restrições (se for necessário), para os computadores e usuários de cada OU. Basta, para isso, configurar e aplicar uma GPO diferente em cada OU. Aquela s configurações que devam ser padrão para todo o domínio, poderão ser configuradas na GPO padrão do domínio, pois as configurações desta GPO são aplicadas a todos os usuários e computadores do domínio e podem, inclusive, sobrescrever configurações aplicadas por GPOs a nível de OU, em caso de conflito de configurações.

As OUs vem, em muitos casos, substituir o papel que era ocupado por domínios, no NT Server 4.0. Em redes baseadas no NT Server 4.0, muitas vezes o administrador acabava criando novos domínios, para poder atribuir permissões administrativas apenas a uma parte da rede e para poder aplicar diferentes configurações de segurança a uma determinada parte da rede. No NT Server 4.0, diferentes políticas de segurança ou necessidade de descentralizar a administração, acabavam por fazer com que novos domínios fossem criados. Já no Windows 2000 e no Windows Server 2003, com o uso de OUs, estas situações foram bastante reduzidas.

Alguns fatores que você não pode esquecer quando estiver projetando quais OUs utilizar no seu domínio:

1.         Quanto mais simples melhor. Menos é melhor.

2.         Lembre que o uso de OUs é uma ferramenta do administrador da rede, para facilitar a administração, permitir que sejam delegadas permissões administrativas para partes específicas do domínio e que sejam aplicadas diferentes configurações via GPO. Um fato que exemplifica isso é que você pode mover a conta de um usuário de uma OU para outra, durante o horário de trabalho e o usuário continuará trabalhando normalmente. Ou seja, estar em uma ou outra OU pouca diferença faz para o usuário (a não ser em termos das GPOs que serão aplicadas). Isso mostra bem que OU é uma ferramenta do administrador e que a estrutura de OUs não precisa e nem deve refletir a estrutura funcional/organizacional da empresa.

3.         Começando com uma estrutura de OUs simplificada, você sempre poderá expandi-la quando for necessário, criando novas OUs e movendo objetos entre OUs.