Administração do Windows

Criando estruturas de UO que funcionam

Ken St. Cyr

Visão geral:

• Princípios fundamentais para um bom projeto de UO
• Modelos de projetos comuns de UO
• Documente seu projeto de UO

Não subestime a importância — e a complexidade — de criar uma boa estrutura de UO (unidade organizacional). Descobri que os departamentos de TI muitas vezes andam nas duas direções — eles

colocam muita ênfase na estrutura de UO ou não pensam suficientemente nela. De qualquer maneira, isso pode levar a problemas com seu modelo do Active Directory®.

Enfatizar demais a estrutura de UO retira o foco de outras áreas do projeto do Active Directory, como planejar a topologia do local ou pensar no dimensionamento do controlador de domínio. Por outro lado, quando o planejamento de UO é colocado em uma posição secundária, a Diretiva de Grupo e a delegação são afetadas.

Uma das desculpas que ouço ocasionalmente é que a estrutura da UO é flexível e pode ser alterada posteriormente se ela não se adequar. É verdade que a estrutura de UO é flexível; no entanto, os administradores muitas vezes descobrem que alterar a estrutura da UO mais adiante é mais difícil do que eles haviam previsto originalmente. É claro que novas UOs podem ser adicionadas, mas as antigas não são fáceis de apagar.

Uma estrutura de UO com um planejamento ruim tende a impor uma vida própria. Se um novo objeto é criado no diretório e o administrador não sabe em que parte da estrutura da UO colocar o objeto, ele criará uma nova UO ou colocará o objeto em outro lugar ao qual ele não pertence. Existem perigos nesses dois cenários. Criar uma nova UO é fácil, mas difícil de controlar ao longo do tempo. A criação desenfreada de UO contribui para uma estrutura de UO caótica e é fácil deixar as coisas serem inseridas no diretório não-documentado. Por outro lado, se você adicionar um objeto a uma UO existente à qual ele realmente não pertence, o novo objeto pode receber diretivas que não deveria ou permissões para o objeto podem ser delegadas a usuários indesejados.

Ao criar estruturas de UO, você deve manter uma equação básica em mente: simplicidade + adaptabilidade = sustentabilidade. Se seu projeto for muito simples, ele pode não ser adaptável e, portanto, terá que ser alterado com muita freqüência. Se seu projeto for muito adaptável, tudo será compartimentalizado e isso acarreta muita complexidade.

Existem três princípios fundamentais com relação à Diretiva de Grupo, delegação e administração de objetos que podem ajudar a orientar a decisão do seu projeto. Esses princípios podem ser resumidos com três perguntas que você deve se fazer e ajudarão a garantir que a estrutura de UO criada por você agüentará os testes de tempo e alteração organizacional:

1. Essa UO precisa ser criada de forma que um GPO (Objeto de Diretiva de Grupo) único possa ser aplicado a ela?
2. Um grupo particular de administradores precisa ter permissões aos objetos nessa UO?
3. Essa nova UO facilitará a administração dos objetos encontrados nela?

Se a resposta a alguma dessas perguntas for "sim", você deverá provavelmente criar a UO. Se a resposta a todas as perguntas for "não", você deve pensar novamente no layout e determinar se um projeto diferente pode criar um ajuste melhor. Mas antes de me aprofundar mais nesse assunto e mostrar a você como aplicar esses princípios, devo primeiro explicar por que eles são importantes.

Princípio 1: Diretiva de Grupo

O primeiro princípio do projeto de UO é levar em conta os objetos de diretiva de grupo que serão aplicados a uma UO. Um GPO permite que você defina configurações para usuários e computadores de maneira aplicável. Você pode definir vários GPOs no Active Directory e aplicá-los a um domínio inteiro, várias UOs ou até mesmo os locais do domínio. Os GPOs são divididos em duas categorias — uma para usuários e uma para computadores.

As diretivas do computador e do usuário podem ser definidas no mesmo GPO. A seção de Configuração do Usuário do GPO define principalmente a experiência que o usuário terá quando conectado. Esses tipos de configurações existem também na seção de Configuração do Computador, mas essa seção também contém mais configurações relacionadas à segurança do computador, como quem pode fazer logon no computador localmente ou como os dados são criptografados.

Veja alguns conceitos básicos para se ter em mente ao definir UOs para suportar GPOs. Primeiro, apenas porque as diretivas do usuário e do computador podem ser definidas no mesmo GPO, não significa que é uma boa idéia colocar os objetos do usuário e do computador na mesma UO. Combinando-os no mesmo GPO torna os problemas do aplicativo GPO mais difíceis de serem solucionados. Isso se torna muito evidente quando você possui uma diretiva de loopback habilitada.

Segundo, várias pessoas esquecem que você pode aplicar GPOs no nível do local e, portanto, projetam suas estruturas de UO para modelar a estrutura do seu local para os objetivos do aplicativo GPO. Isso é um modelo comum de projeto de UO, conhecido como Modelo Geográfico. Falarei mais sobre esse modelo em breve. Eu seria negligente se não reconhecesse que o Modelo Geográfico tem seu lugar na criação da UO, mas como você verá posteriormente, não acredito que o aplicativo GPO deva ser a razão principal para implementar esse modelo.

Além disso, quando você pensa na sua estrutura de UO em termos de GPOs, o objetivo deve ser eliminar a complexidade. Certifique-se de que a UO é adicionada ao fluxo da herança de GPO. Se sua UO contiver servidores que exigem a mesma diretiva de outros servidores, considere colocar esses objetos do computador sob uma UO de servidores mais ampla e criar várias UOs para diferentes tipos de servidores abaixo da UO de servidores (consulte a Figura 1). Isso pode simplificar a aplicação da diretiva, uma vez que cada objeto de computador nas UOs inferiores irá obter a diretiva da UO dos servidores, bem como qualquer outra diretiva específica àquele tipo próprio de servidor.

Figure 1** Creating multiple OUs for different server types **(Clique na imagem para aumentar a exibição)

Outro conceito básico é garantir que você não crie desnecessariamente ou vincule vários GPOs. Com um GPO, é possível criar uma diretiva e aplicá-la a várias UOs. Isso às vezes é útil, ms também pode ser prejudicial. Se você precisar alterar uma configuração de GPO e possuir um sistema exageradamente complexo de GPOs vinculados, você poderia acidentalmente aplicar uma alteração nos objetos errados. Quanto mais vínculos criar, mais difícil será compreender o escopo de uma diretiva. Do mesmo modo, você deve evitar criar diretivas adicionais com as mesmas configurações de outras diretivas. Se julgar que faz isso com freqüência, pense em modificar sua estrutura de UO para aplicar um novo modelo de herança de GPO.

E, finalmente, você deve quase sempre criar uma nova UO para objetos do usuário e do computador. Por padrão, objetos do usuário e do computador são colocados em contêineres, que não permitem a você vincular GPOs diretamente a eles. Os GPOs podem ser aplicados aos contêineres de Usuários e Computadores a partir do domínio, mas, a menos que você bloqueie a herança em outro lugar, essas diretivas serão aplicadas a todos os usuários e computadores do domínio. No Windows Server® 2003, você pode usar as ferramentas rediruser.exe e redircomp.exe para alterar o local padrão para objetos do usuário e do computador para a UO que você criou para eles.

Princípio 2: Delegação

É importante que você crie a estrutura da UO de uma maneira que seja consistente com o modo como as permissões são delegadas no domínio. Tenha em mente que quando as permissões são delegadas no Active Directory, as alterações de permissão são feitas apenas para o objeto. Então, se você precisasse conceder a um usuário Controle Total para um determinado objeto do computador, essa pessoa poderia modificar os atributos do objeto, mas não teria privilégios de administrador no computador em si.

Veja algumas práticas recomendadas com relação à delegação para quando você criar uma estrutura de UO:

Crie com a herança de permissão em mente Por exemplo, digamos que você queira que os administradores da camada 1 possam alterar a senha para a maioria das contas. Há um grupo especial de usuários para os quais os administradores não devem ter a capacidade de redefinir senhas, mas os administradores precisam poder alterar os nomes de exibição nessas contas.

Há duas opções reais aqui. Primeiro, você poderia criar duas UOs paralelas separadas e separar os usuários especiais dos usuários regulares. Isso, no entanto, significa que se você desejar alterar as opções de delegação para todos os usuários, precisará alterar essas permissões em dois locais diferentes. Isso também contradiz a prática de não desnecessariamente fazer a vinculação múltipla de diretivas (consulte a Figura 2).

Figure 2** Maintaining two separate parallel OUs **(Clique na imagem para aumentar a exibição)

A outra opção é criar uma UO aninhada e colocar uma permissão de negação explícita na UO com usuários especiais nela. Qualquer especialista em delegação dirá a você que uma negação explícita não é preferível — mas, nesse caso, você precisa selecionar o menos pior dos dois males (consulte a Figura 3). Você pode duplicar e manter as configurações em duas UOs separadas ou pode colocar uma negação explícita em uma das UOs. A negação explícita é realmente a melhor decisão a longo prazo.

Figure 3** Using an explicit deny permission **(Clique na imagem para aumentar a exibição)

Cuidado com o AdminSDHolder Esse exemplo funciona bem, a menos que os usuários especiais pertençam todos a um dos grupos de Administradores (Admins. do Domínio, Administradores do Esquema, Administradores de Empresa ou Administradores), uma vez que as permissões para contas nesses grupos são tratadas de modo diferente. A idéia é que você não deseja fornecer acidentalmente a alguém permissões para uma conta de administradores.

Se você criar uma UO separada para os administradores, descobrirá que as permissões que você delega a eles continuam desaparecendo. Isso ocorre devido ao AdminSDHolder, que é um contêiner especial que aplica sua Lista de Controle de Acesso a todas as contas de administradores a um intervalo específico. Como resultado, qualquer alteração de delegação feita a uma conta de administrador será revertida se as alterações não forem feitas também ao contêiner AdminSDHolder. Então, você não deve separar contas de administradores de outras contas para o objetivo da delegação. É preferível, no entanto, separar as contas de administradores para fins da Diretiva de Grupo — isso é válido especialmente no Windows Server 2008, onde você pode ter várias diretivas de senha.

Princípio 3: Administração de Objetos

A UO deve facilitar a administração dos objetos. Agrupar objetos na mesma UO pode muitas vezes facilitar a execução de alterações em massa. O snap-in Usuários e Computadores do Active Directory permite que você edite certos atributos em uma seleção de vários objetos. Então, se você precisa alterar regularmente um atributo em um grupo de objetos, é mais fácil fazê-lo se eles estiverem todos na mesma UO.

Isso também é particularmente útil se você estiver fazendo atualizações com um script. Os idiomas de script facilitam bastante a enumeração de todos os objetos em uma UO e o tratamento deles um por um. A outra opção é pesquisar e modificar cada objeto individualmente. Simplesmente colocar os objetos na mesma UO para administração pode às vezes economizar horas de trabalho desnecessário a cada semana.

Outra maneira de ajudar com a administração de objetos é separar os objetos em diferentes UOs com base no seu tipo. Criar uma UO separada para objetos da impressora ou compartilhamentos publicados garante que esses objetos não precisem ser eliminados quando você executar a administração em outros objetos da UO. Essa prática também se alinha com a prática de não agrupar contas de usuário e do computador juntas na mesma UO.

Escolhendo um modelo

Agora que tratei dos princípios da criação da UO, posso examinar mais de perto alguns modelos comuns de projeto. Observe que existem muito mais modelos do que o espaço que possuo aqui para falar deles. E você não está limitado a trabalhar dentro das restrições de um único modelo. Você pode escolher partes de cada um e criar o seu próprio modelo híbrido que atenda às suas necessidades específicas.

Praticamente qualquer modelo pode ser bem-sucedido em uma pequena escala, mas quando sua empresa cresce, sua capacidade de manter o controle do ambiente diminui. Então, certifique-se de primeiro testar a fundo seu modelo em um ambiente de laboratório adequado. E lembre-se de que, embora as estruturas de UO possam ser alteradas facilmente de início, quanto mais tempo elas estiverem em vigor, poderá ser mais difícil alterá-las.

O modelo raso

O modelo raso obtém seu nome a partir do fato de que ele é mantido na maior parte do tempo simples. Nesse modelo, algumas UOs de alto nível contêm a maioria dos objetos (consulte a Figura 4). Esse modelo é mais realizado em empresas menores, onde há uma pequena compra de TI, não há muitas divisões diferentes ou as pessoas tendem a desempenhar várias funções. Eu tipicamente recomendo não se aprofundar mais do que 10 sub-UOs, embora a Microsoft sugira um limite de 15 sub-UOs antes que as penalidades de desempenho sejam percebidas.

Figure 4** The Shallow Model has a few high-level OUs that contain the majority of objects **(Clique na imagem para aumentar a exibição)

Se sua pessoa de Recursos Humanos é também sua pessoa de folha de pagamento, não faz sentido criar duas UOs separadas para Recursos Humanos e Folha de Pagamento. No modelo raso, todos os objetos do usuário podem ser agrupados em uma grande UO de Contas ou podem ser mantidos no contêiner Usuários padrão. Na pior das hipóteses, seus objetos do usuário devem ser separados a partir dos objetos do computador.

Para esse modelo, também recomendo que você dê um passo além e separe suas estações de trabalho dos servidores. Em seguida, você pode pelo menos aplicar diferentes Diretivas de Grupo sem ter que definir um GPO que usa uma Consulta do WMI (Windows® Management Instrumentation) para filtrar estações de trabalho ou servidores.

Uma vantagem de manter sua estrutura da UO ampla, e não profunda, é que as pesquisas do Active Directory serão executadas mais rapidamente. Tipicamente recomendo não se aprofundar mais que 10 sub-UOs. Seu controle sobre os objetos não é muito refinado nesse modelo, mas se estiver gerenciando objetos em uma pequena empresa, você não precisará desse controle refinado. Portanto, esse modelo seria difícil de usar com sucesso em uma grande empresa, mas ele funciona muito bem em organizações menores.

O modelo geográfico

No modelo geográfico, você cria UOs separadas para diferentes regiões geográficas. Esse modelo é melhor adequado para organizações que descentralizaram departamentos de TI, mas não desejam incorrer nos custos associados à operação de vários domínios (consulte a Figura 5).

Figure 5** The Geographic Model separates OUs by geographical region **(Clique na imagem para aumentar a exibição)

Digamos que você tenha escritórios em Atlanta, Baltimore e Seattle. Se cada local gerencia seus próprios usuários e computadores, isso pode ser uma opção adequada em termos de delegação. Mas o que acontece se um usuário de Seattle voa para Baltimore para um treinamento e bloqueia sua conta? A equipe de TI de Baltimore pode não conseguir ajudar esse usuário se não foram delegadas a ela permissões para a conta desse usuário. Se são 8 da manhã em Baltimore, são 17 horas em Seattle, o que significa que o usuário pode ter que esperar horas até conseguir falar com alguém no escritório de Seattle para obter ajuda.

Algumas empresas globais usam um modelo "follow the sun" (24 horas contínuas, contando com as equipes fisicamente distantes), onde as chamadas de suporte técnico são encaminhadas para um local em um fuso horário onde é no momento horário comercial padrão. Isso significa que a empresa não precisa operar um suporte técnico 24 horas em cada local, mas pode ainda fornecer aos funcionários noturnos ajuda, como desbloquear suas contas, quando necessário.

Se esse é o seu modelo, criar UOs separadas com base no local geográfico provavelmente não é a melhor opção para suas necessidades operacionais. Você teria que delegar permissões separadas a cada suporte técnico regional para cada UO de usuários. No entanto, se seus locais não possuem seus próprios departamentos de TI, o modelo geográfico poderá, na verdade, ser um bom modelo para a sua organização.

O modelo geográfico também é difícil de ser executado em um único domínio devido à natureza de como um domínio é operado. Um domínio tende a ter um modelo de segurança diferente de outros domínios. Isso é mais evidente quando você examina um aplicativo empresarial, como o Microsoft® Exchange.

O Exchange Server em Atlanta pode ter diretivas de mensagens diferentes definidas, mas todos os Exchange Servers da empresa provavelmente possuem os mesmos GPOs aplicados. Se for esse o caso, colocar os Exchange Servers em UOs separadas com base na região faria com que você vinculasse desnecessariamente o mesmo GPO a várias UOs. Em termos de delegação, você precisa perguntar se os administradores do Exchange realmente precisam de permissões únicas para os objetos do computador para os Exchange Servers. Na maioria dos casos, os objetos do computador que são divididos em UOs geográficas são divididos para fins da Diretiva de Grupo, e não da delegação.

O modelo baseado em tipo

O modelo baseado em tipo classifica os objetos por suas finalidades (consulte a Figura 6). Quando você criou seu último objeto de usuário, foi para uma conta de usuário regular, uma conta administrativa ou uma conta de serviço? Em um modelo baseado em tipo, cada um desses objetos é tratado diferentemente.

Figure 6** The Type-Based Model groups objects according to their functions **(Clique na imagem para aumentar a exibição)

Na maioria dos casos, você deve distinguir entre diferentes classificações de objetos de usuário para diretivas. Suas diretivas provavelmente serão diferentes com base no tipo de conta de usuário. Por exemplo, permitir que as pessoas façam logon em um computador com uma conta de serviço é geralmente uma prática de negócios ruim. As senhas da conta de serviço são normalmente compartilhadas entre várias pessoas, então se alguém faz logon com uma conta de serviço, sua identidade permanece anônima. Se algo fosse acontecer, você teria problemas para rastrear o usuário que estava conectado quando o evento ocorreu. Nesse exemplo, você precisaria definir uma diretiva sobre contas de serviço que impede o logon interativo. Isso se ajusta bem ao modelo hierárquico mostrado na Figura 3.

Você poderia usar a herança de GPO como vantagem aqui. Por exemplo, você poderia ter uma diretiva de todos os usuários referente a diretivas em vigor para todos os objetos de usuário. Além disso, você poderia ter uma diretiva separada e distinta para contas de serviço, baseada na diretiva de todos os usuários. Essa abordagem garante que suas contas de serviço tenham o mesmo conjunto base de diretivas como todas as outras contas, bem como as restrições de logon específicas.

Essa abordagem também funciona bem para a delegação, onde você está usando a herança de permissão em vez da herança de GPO. Suponha que você queira que os administradores da camada 2 possam redefinir senhas para todas as contas, exceto para as contas do administrador da camada 3. Com uma estrutura de UO simples, você teria que delegar permissões a cada UO que mantém contas de usuários. No entanto, em um modelo baseado em tipo com uma estrutura hierárquica, você pode conceder ao grupo da camada 2 permissões para "redefinir senha" na UO de Contas e, em seguida, na UO da camada 3, você poderia simplesmente não herdar as permissões ou até mesmo definir uma negação explícita para a camada 2 redefinir senhas.

Isso também funciona bem para objetos do computador. Servidores e estações de trabalho podem ser separados, permitindo que diferentes diretivas sejam aplicadas a eles. Os servidores podem então ser mais subdivididos em funções (consulte a Figura 1). Nesse projeto, você pode definir uma diretiva de alto nível na UO de Servidores que afeta todos os servidores e ainda definir diretivas individuais em cada UO de nível inferior.

Por exemplo, digamos que você tenha uma conta de serviço do MOM (Microsoft Operations Manager). Com esse modelo em camadas, é possível criar um GPO do MOM e aplicá-lo a UO de Servidores MOM. E dentro desse GPO, você pode conceder ao serviço MOM direitos de conta para fazer logon como um serviço. Isso apenas se aplicaria aos servidores MOM nessa UO. Os servidores MOM ainda obterão o GPO de servidores da UO de servidores de nível mais alto, mas também irão obter o GPO do MOM especializado, vinculado à UO do MOM.

Documente a criação

Pode ser muito compensador criar uma estrutura de UO que resistirá às várias alterações que um ambiente do Active Directory poderá encontrar. Mas você precisa de alguma maneira de rastrear as características dinâmicas das UOs. Se não tiver isso, poderá rapidamente perder o controle do seu ambiente. Quando as coisas precisam de uma alteração e uma UO precisa ser adicionada ou excluída, deve haver uma orientação clara sobre o que fazer para garantir que seu modelo continue seguindo o projeto, respeitando os três princípios de orientação. É por isso que você precisa possuir um projeto bem-documentado.

A Microsoft fornece guias de documentação no kit de recursos do Windows Server. Esses guias são bons se a sua estrutura é sólida e você não espera alterá-la muito. Mas a maioria das organizações possui uma estrutura muito dinâmica alterada com freqüência. Veja algumas dicas importantes para garantir que sua estrutura de UO seja bem documentada e possa suportar um ambiente dinâmico.

Verifique se todas as informações são relevantes Eu altamente acredito na documentação com objetivo. Muitos documentos operacionais possuem tantas informações irrelevantes que é difícil encontrar o que importa. Não se envolva no processo da documentação apenas visando a documentação. Você realmente precisa incluir o número de objetos em cada UO ou cada ACE (Entrada de Controle de Acesso) na Lista de Controle de Acesso para a UO? Para documentação da UO, as seguintes informações normalmente serão suficientes:

• Nome da UO
• Breve descrição
• Quem a criou — ou com quem entrar em contato para mais informações ou alterações
• Quando ela foi criada

Não dificulte as atualizações Se você precisa atualizar de modo tedioso algum documento do Microsoft Word complexo, provavelmente você irá adiar a colocação de atualizações. Não há problemas se você adiar a inserção de pequenas alterações quando sabe que em breve terá uma quantidade maior de atualizações para inserir de uma vez. Infelizmente, as pessoas muitas vezes esquecem dessas pequenas alterações ou simplesmente continuam adiando sua inserção e o trabalho nunca é feito. Portanto, atualizar o documento deve ser muito fácil de forma a não desestimulá-lo. Na maioria dos casos, uma simples planilha do Microsoft Excel® com algumas colunas funcionará bem.

Faça comentários no objeto em si Os objetos de UO têm um atributo de descrição onde você pode inserir comentários. Em vez de escrever os comentários no documento do projeto, pense em colocá-los no atributo de descrição para que outras pessoas possam dizer imediatamente para que serve a UO. Se precisar incluir mais detalhes, coloque uma breve descrição no atributo de descrição e inclua mais detalhes no documento de UO.

Automatize a documentação Um script pode ser escrito para despejar o conteúdo da estrutura da UO para um arquivo de texto, uma planilha do Excel ou até mesmo um arquivo HTML. Esse script pode ser executado em uma tarefa programada todas as noites. Isso pode ser muito útil se você incorpora comentários no campo de descrição da UO. Depois, é só uma questão de despejar o atributo de descrição para o arquivo e você automaticamente tem uma estrutura de UO totalmente documentada sempre atual. Se você cria um novo arquivo todas as vezes que o script é executado, em oposição a substituir o documento existente, você pode manter um registro histórico de como a estrutura de UO mudou com o tempo.

Infelizmente, a maioria dos administradores não percebe a importância de uma boa documentação da estrutura de UO até que realmente precisam disso. E, até lá, às 3 horas da manhã, é praticamente impossível descobrir que outras UOs foram acidentalmente excluídas sem executar uma restauração.

Não aguarde até que isso ocorra com você. Eu recomendo enfaticamente que você se torne proativo nessa área e inicie imediatamente um documento da UO e designe uma pessoa para ser responsável para atualizá-lo. E se você seguir a regra de tornar a documentação fácil de atualizar, essa será uma tarefa muito pequena para manter em atividade.

Ken St. Cyr é um consultor da Microsoft com 10 anos de experiência na indústria de TI. Ele projeta e implementa soluções para diretórios com base no Active Directory desde sua criação.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..