Administração do Windows

Delegando autoridade no Active Directory

Joel Yoker and Rob Campbell

Visão geral:

• Definindo funções administrativas
• Desenvolvendo uma UO e um modelo de grupo de segurança
• Usando contas secundárias
• Ferramentas de delegação de direitos

Os recursos de delegação do Active Directory são muito eficientes e abordam uma série de problemas relacionados à segurança, além de simplificar tarefas de gerenciamento. Quando a delegação de direitos no Active

Directory® é feita corretamente, você pode aplicar funções especificadas ao ambiente, limitar o impacto e a probabilidade de erro administrativo e aplicar o princípio de privilégio mínimo ao longo de toda a sua infra-estrutura. Mesmo assim, muitas das organizações que contam com o Active Directory ainda precisam explorar mais o poder da delegação. Isso ocorre em parte porque, na superfície, o desenvolvimento de um modelo de delegação do Active Directory para o seu negócio parece ser bastante complexo. Embora o maior obstáculo seja desenvolver um modelo de delegação que se adapte às necessidades exclusivas de sua organização, a verdade é que existem modelos muito simples que podem ser aplicados à maioria das infra-estruturas de TI com pouca modificação.

Apesar de todo ambiente ser diferente de algum modo, formato ou forma, a realidade é que a maior parte das grandes empresas se assemelha de várias maneiras e enfrenta os mesmos desafios de TI. Por exemplo, várias organizações estão divididas em regiões geográficas, evoluíram de equipes distintas de engenharia de TI ou suporte operacional e possuem unidades comerciais independentes. E muitas organizações de grande porte devem lidar com assuntos como escalonamento de privilégios, abuso de conta de serviço e "confiança".

Confiança é um termo interessante e geralmente se torna a justificativa para ter várias florestas do Active Directory. Problemas relacionados à confiança geralmente se originam da capacidade de uma divisão ou região para afetar a disponibilidade de sistema de outra divisão ou região. É comum que os níveis de habilidade sejam diferentes em limites organizacionais, daí uma falta de conhecimento aprofundado sobre sistemas específicos requerido para dar suporte a uma região ou unidade comercial específica. Portanto, as divisões geralmente não querem renunciar a seus direitos administrativos e transferi-los a um grupo central.

Enquanto isso, em qualquer implementação do Active Directory, os administradores devem definir as regras de envolvimento para aplicativos que utilizam a infra-estrutura do Active Directory. Infelizmente, uma abordagem comum – mencionada geralmente em guias de instalação de aplicativos – é tornar a conta de serviço um membro do grupo Admins. do Domínio. O problema com essa abordagem é que contas de serviço são, essencialmente, contas genéricas. Concedendo esses direitos de Admins. do Domínio, você oferece uma ameaça significativa ao ambiente de TI. As contas de serviço podem ser vítimas do uso incorreto facilmente, por administradores maliciosos ou descuidados, ou ser aproveitadas por invasores que se valem problemas de segurança de base em um aplicativo.

Embora esses obstáculos possam parecer intransponíveis, eles representam um cenário principal para implementação do modelo de delegação do Active Directory. Desenvolver esse modelo de delegação é um processo de design interativo e sugerimos que você siga estas etapas:

1. Defina as funções administrativas de TI em sua organização.
2. Desenvolva uma unidade organizacional e um modelo de grupo de segurança.
3. Estabeleça contas secundárias para administradores de TI.
4. Delegue direitos.

Vamos examinar essas etapas mais de perto.

Definir funções

O processo de definição de função tem início com um entendimento meticuloso de administração de serviços e administração de dados. Esses conceitos são o fundamento de qualquer modelo de delegação do Active Directory.

Fundamentalmente, a administração de serviços é o gerenciamento de componentes críticos da infra-estrutura de serviço de diretório, como servidores Exchange e controladores de domínio. Administração de dados é o gerenciamento de objetos, como caixas de correio e contas de usuário, que residem nesses serviços. Dentro do escopo do Active Directory, os administradores de serviço são, em última análise, responsáveis pelo fornecimento e pela disponibilidade de serviços de diretório, enquanto os administradores de dados gerenciam contas de usuário e de servidor, grupos e outros recursos do domínio.

O Active Directory oferece suporte à delegação granular de autoridade por meio de UOs (unidades organizacionais). As UOs freqüentemente podem ser adaptadas para oferecer o mesmo nível de autoridade disponível para administradores nos modelos de serviço de diretório ou de domínio existentes. No entanto, é importante entender que algumas funções simplesmente não podem ser delegadas e devem ser gerenciadas por um grupo ou uma entidade único e confiável.

A análise de tarefas também é fundamental. Você precisa saber quais tarefas do Active Directory são realizadas por administradores e como essas tarefas são mapeadas a funções. Por exemplo, a criação do site do Active Directory é uma tarefa de administração de serviços, ao passo que a modificação de associação de grupo de segurança geralmente recai sob a administração de dados. Cada tarefa deve ser avaliada por freqüência, importância e dificuldade. Esses aspectos são vitais à definição de tarefas, porque definem se um direito deve ser delegado. As tarefas são executadas rotineiramente, têm risco limitado e são de execução trivial, além de serem excelentes candidatas à delegação. Por outro lado, tarefas que são executadas raramente têm um grande impacto na organização e requerem níveis altos de habilidade, além de serem candidatas fracas à delegação. Em vez disso, o escalonamento (que eleva temporariamente uma conta à função requerida ou reatribui a tarefa) é o caminho apropriado para essas tarefas.

Como muitas características de grandes organizações se assemelham, é seguro supor que um modelo de delegação comum possa ser implementado. Para os fins deste artigo, forneceremos um conjunto de amostras de funções que permitem recursos de gerenciamento, respeitando, ao mesmo tempo, limites organizacionais e tentando minimizar problemas relacionados à confiança (exemplo: a disponibilidade de ativos de toda a empresa, como controladores de domínio). Observe que este modelo é apenas um exemplo: trata-se de um ótimo início de discussão sobre funções em sua organização; no entanto, você não deverá planejar usar essa orientação textual.

Algumas funções já são definidas pelo Active Directory e outras precisam ser criadas do zero para refinar o modelo de delegação. Um conjunto de funções de exemplo que se adaptaria a muitos ambientes de grande porte do Active Directory poderia incluir Administração de Empresa, Admins. do Domínio e Administração de Nível 4 para administração de serviços, Administração de Nível 3, Administradores Regionais, Administração de Nível 2 e Administração de Nível 1 para administração de dados. Consulte a Figura 1 para obter uma lista dessas funções e responsabilidades respectivas.

Figure 1 Definir funções e responsabilidades

Administradores de serviço

Vamos examinar mais de perto as funções do administrador de serviço. Os administradores de serviços gerenciam componentes críticos da infra-estrutura e todos os administradores incluídos nesta categoria são altamente privilegiados. Portanto, uma estratégia de privilégio mínimo, ou seja, só conceder o conjunto mínimo de permissões necessárias para a realização de tarefas requeridas, é altamente recomendada neste caso.

Os Administradores de Domínio e de Empresa do Active Directory definem dois grupos de administradores especiais cujo contexto de segurança é requerido para funções essenciais dentro do diretório. Esses Administradores dos grupos de Domínio e de Empresa são responsáveis pela administração de serviços de nível superior. Para minimizar os riscos inerentes a esses grupos altamente privilegiados, aconselhamos enfaticamente a restrição de associação para esses grupos. Na verdade, o grupo Administração de Empresa não deve possuir membros permanentes e os grupos de Admins. do Domínio devem conter apenas um número pequeno e gerenciável de indivíduos de confiança que trabalhem para a organização em tempo integral.

Quando tarefas de administração de empresa, como autorização de servidor DHCP ou criação de site do Active Directory precisam ser realizadas, a Admins. do Domínio no domínio raiz de floresta do Active Directory pode escalonar privilégios gerenciando a associação do grupo Administração de Empresa. Esses privilégios só devem ser concedidos por períodos curtos, a título de evitar a criação de membros permanentes no grupo Administração de Empresa. Naturalmente, todos os membros de um grupo Admins. de Domínio em uma determinada floresta do Active Directory devem ser igualmente confiáveis.

Uma armadilha comum que ocorre com a maioria das organizações ao desenvolver um modelo de delegação é desabilitar ou enfraquecer essas funções internas. A modificação dessas tarefas padrão pode causar resultados imprevisíveis e não há nenhuma garantia de que revisões de service pack ou atualizações de produto mantenham essas configurações. Além disso, esse tipo de modificação cria um ambiente sem suporte fora da organização. Uma abordagem prática é usar os grupos e as funções internas, limitando, porém, a associação. Para isso, você provavelmente terá que criar novas funções para administradores que anteriormente contavam com associação em grupos como Admins. do Domínio.

Administração de Nível 4 A Administração de Nível 4 deve consistir em administradores de serviços centralizados, que oferecem suporte a todos os serviços empresariais. Como essa é uma função criada, as permissões de acesso ao sistema e ao serviço de diretório podem ser adaptadas aos requisitos específicos da organização. Embora membros desse grupo sejam administradores de serviço, eles também podem executar tarefas ocasionais de gerenciamento de dados em toda a floresta. Como existem várias classes de sistemas e áreas de responsabilidade distintas, as funções de nível 4 são desmembradas em vários subgrupos dentro do diretório. Por exemplo, devem ser criados grupos separados de nível 4 para oferecer gerenciamento distinto de sistemas específicos, como servidores Exchange. Esse grupo também funciona como um ponto de escalonamento para administradores de dados.

Um motivo por que as pessoas freqüentemente desejam receber a associação no grupo Admins. do Domínio é ganhar direitos administrativos sobre todo sistema em um determinado domínio. O truque para fazer com que esses administradores de serviços sejam executados no modo de privilégio mínimo é conceder à Administração de Nível 4 o controle de servidores corporativos, sem torná-los Admins. do Domínio. Para evitar o escalonamento de privilégio, a Administração de Nível 4 não deve receber a associação no grupo BUILTIN\Administrators em controladores de domínio, porque esse grupo tem muitos direitos subjacentes no serviço de diretório que não podem ser separados. Por exemplo, um membro do grupo BUILTIN\Administrators de um determinado domínio pode gerenciar a associação do grupo Admins. do Domínio, permitindo aos membros escalonar privilégios sem nenhuma verificação nem balanço.

Lembrando nossa regra de não enfraquecer permissões padrão, esse risco pode ser minimizado, tornando os grupos do nível 4 membros aninhados dos grupos de operadores do servidor e administradores de DNS de domínio interno. Isso permite o gerenciamento local de controladores de domínio, limitando, ao mesmo tempo, a habilidade da Administração de Nível 4 para escalonar privilégios. Para a maioria dos sistemas (além dos controladores de domínio, servidores de certificados e assim por diante), você deve tornar o grupo Administração de Nível 4 um membro do grupo Administradores local. A automação de uma associação de grupo local aninhado pode ser obtida com a funcionalidade Grupos Restritos em Diretiva de Grupo.

Administradores de dados

Agora vamos nos aprofundar nas funções de administração de dados. Essas funções devem ser criadas com direitos cumulativos, ou seja, uma Administração de Nível 2 deve ter todos os direitos de uma Administração de Nível 1, juntamente com alguns privilégios adicionais e assim por diante. Por essa razão, veremos esses grupos de baixo para cima.

Administração de Nível 1 O grupo Administração de Nível 1 deve oferecer gerenciamento geral de objetos de diretório criados previamente. Esse grupo destina-se ao administrador com um mínimo de treinamento ou ao administrador que executa tarefas isoladas, como redefinição de senha. Conceder direitos a esse grupo, dentro da respectiva unidade organizacional, para modificar propriedades de conta de usuário, redefinir senhas de contas de usuários, desbloquear contas, habilitar/desabilitar contas de usuários, adicionar e redefinir contas de computador de estação de trabalho e modificar associação de objeto de grupo para grupos não administrativos.

Administração de Nível 2: este grupo deve habilitar o gerenciamento e a criação seletivos de objetos, permitindo que eles sejam criados apenas quando puderem ser gerenciados pela Administração de Nível 1. (Por exemplo, grupos de segurança só podem ser criados em UO de Grupos). A Administração de Nível 2 pode adicionar e modificar contas da Administração de Nível 1, adicionar, modificar e excluir contas de usuários de uma UO, excluir objetos de computador de estação de trabalho e adicionar, modificar e excluir objetos Servidor, Contato e Pasta compartilhada.

Administradores Regionais Este grupo recebe direitos exclusivos sobre a respectiva estrutura de UO regional. No entanto, o grupo não é capaz de gerenciar outras estruturas de UOs regionais dentro do diretório. As contas de Administradores Regionais devem ser consideradas altamente privilegiadas e, como conseqüência, as contas são armazenadas em uma hierarquia de UO separada e gerenciadas pelos administradores de serviço da Administração de Nível 4. Os Administradores Regionais pode criar a maior parte dos objetos sem restrições dentro da respectiva estrutura de UO (uma exceção notável é a criação de outras UOs), o que traz o risco adicional de criar objetos que podem não ser gerenciáveis por níveis inferiores.

Administração de Nível 3: muitas organizações têm um suporte técnico de nível superior ou centralizado. Essa função completa a lista de administradores de dados, oferecendo um grupo de administradores de dados em todos os Administradores Regionais. Não são delegados direitos a esses grupos especificamente dentro do diretório; em vez disso, eles são feitos por associação aninhada em cada grupo Administradores Regionais. Isso oferece um ponto de escalonamento de nível superior para todos os administradores de dados, bem como um ponto de entrada de problemas a serem escalonados aos grupos de administração de serviços.

Desenvolver uma UO e um modelo de grupo de segurança

Depois que as funções estiverem definidas na organização, devem ser definidos uma UO e um modelo de grupo de segurança. Existem dois motivos principais para se criar uma UO no Active Directory: delegação de direitos e criação de um ponto onde Objetos de Diretiva de Grupo podem ser vinculados. As UOs definem um SOM (escopo de gerenciamento) dentro do diretório, e isso pode ser usado para restringir direitos a objetos em vários níveis. Como resultado, a forma como você escolhe delegar a autoridade deve ser o fator principal de como você implementa a sua estrutura de UO.

Com isso em mente, uma UO de nível superior (ou uma série delas) deve ser criada abaixo do domínio para abrigar todos os objetos. Essa UO atende à finalidade específica de definir o SOM de nível mais alto para a Administração de Nível 4. Criando uma UO de nível superior, os direitos sobre o serviço de diretório podem iniciar explicitamente no nível da UO, em vez de iniciar no nível do domínio. A delegação a partir de uma UO de nível superior, em vez de a partir do domínio, minimiza o risco de o usuário ter a possibilidade de escalonar privilégios através da manipulação de grupos de domínio internos já mencionados anteriormente.

Abaixo das Uos de nível superior você deve criar hierarquias de sub-UO para representar cada região ou unidade de negócios que tenha uma equipe de gerenciamento de dados distinta. Cada sub-UO regional deve ter uma hierarquia de UO comum e não extensível para gerenciamento de objetos de diretório. A uniformidade é essencial ao gerenciamento contínuo, uma vez que grande parte dos direitos de delegação será automatizada. Trata-se de um pedido exigente, porque cada região pode desejar UOs exclusivas. Administradores de TI, entretanto, devem usar suas próprias armas e, se for necessária uma extensão para uma região, a estrutura da sub-UO deverá ser estendida a todas as regiões. Isso pode parecer difícil no início, mas se a organização oferecer abrigo genérico para objetos, situações remotas tendem a se ajustar com o tempo.

Finalmente, crie grupos de subadministradores e contas para remover a capacidade dos administradores de escalonar os respectivos privilégios a grupos Administração de Nível 1, Administração de Nível 2 e Administradores Regionais a cada hierarquia de sub-UO. Colocar essas contas em UOs separadas permite a restrição de gerenciamento nos respectivos níveis ou abaixo deles. Portanto, se todas as contas de Administração de Nível 1 e o grupo de segurança associado residirem em uma UO em que não tenham direitos, os administradores não poderão seqüestrar outras contas de administradores nem escalonar os privilégios de outros administradores a seus níveis. Qualquer membro do grupo Admins. do Domínio, por exemplo, pode tornar qualquer outra conta de usuário no domínio um Admin. do Domínio. No entanto, com esse modelo de UO em vigor, esse risco é minimizado. Um exemplo de estrutura de UO com grupos de segurança associados é mostrado na Figura 2.

Figura 2** Estrutura de UO e grupos de segurança associados **

Estabelecer contas secundárias

A chave para um modelo de delegação bem-sucedido é aplicar o princípio do privilégio mínimo. Na prática, isso significa que uma entidade de segurança deve ter apenas a capacidade de executar as tarefas requeridas para a sua função determinada e nada mais. Infelizmente, muitos administradores de TI usam a mesma entidade de segurança para administração de diretório e tarefas diárias, como navegação na Web e leitura de email. Manter contas separadas diminui a probabilidade de um administrador em camadas danificar o serviço de diretório por engano ou ser vítima de um ataque que ocorre por meio de aplicativos diários, mas que se destina ao administrador de diretórios.

Para realizar isso sem requerer que o usuário faça logoff e volte a fazer logon, use o serviço Logon secundário (Runas.exe). Isso permite ao usuário elevar os próprios privilégios, fornecendo um conjunto alternativo de credenciais ao executar scripts ou executáveis em servidores e estação de trabalho.

Embora o conceito de uso de contas com privilégios mínimos seja relativamente simples, as organizações às vezes consideram difícil a sua aplicação, pois antigos hábitos de TI podem ser difíceis de modificar. Uma abordagem objetiva para se evitar o uso de contas privilegiadas em tarefas diárias é não oferecer acesso a email a essas contas no Exchange Server, aplicando essa restrição por meio de diretiva administrativa na organização. Essa abordagem relativamente simples reduz em muito a probabilidade de que tais contas sejam usadas em tarefas rotineiras e não administrativas.

Delegar direitos

A etapa final do desenvolvimento de um modelo de delegação é a delegação efetiva de direitos dentro do Active Directory. Isso exige a manipulação de ACEs (entradas de controle de acesso) e ACLs (listas de controle de acesso) em dados armazenados no diretório. As ACLs em contêineres do Active Directory definem os objetos que podem ser criados e o modo como esses objetos são gerenciados. A delegação de direitos envolve operações básicas em objetos, como a capacidade de exibir um objeto, criar um objeto filho de uma classe especificada ou ler informações de atributo e segurança em objetos de uma classe determinada. Além dessas operações básicas, o Active Directory define direitos estendidos, o que permite operações como Send as e Manage Replication Topology.

Nas etapas anteriores, discutimos a criação de grupos de segurança que são mapeados para funções organizacionais definidas. Isso significa que para toda função existe um grupo de segurança associado por estrutura de sub-UO. Para implementar o modelo de delegação, esses grupos precisam receber permissões sobre os objetos no diretório. Nesse ponto do processo, reinventar a roda e criar um ambiente altamente personalizado não é o que se deseja. Em vez disso, tente aproveitar grupos e direitos internos quando possível. Digamos que uma função específica precise gerenciar registros DNS da floresta. Não tente delegar direitos sobre os contêineres e contextos de nomeação relacionados ao DNS integrado ao Active Directory; no lugar disso, basta utilizar o grupo BUILTIN\DNS Admins no domínio. Além disso, direitos do usuário e outras permissões podem ser estendidos por meio de Diretiva de grupo, para fornecer os direitos adicionais requeridos ao gerenciamento de uma classe específica de sistema por uma determinada função.

Quando acessar permissões usando delegação, limite ou até elimine completamente o uso de Deny ACEs no diretório. Essas ACEs podem ser confusas quando se trata de solucionar problemas. Uma abordagem melhor é fazer uso de Allow ACEs explícitas, para conceder direitos aos grupos personalizados que representam suas funções. Lembre-se de que funções definidas pelo usuário, como Administração de Nível 4, só terão os direitos explícitos definidos por essa função.

A herança é essencial à segurança do Active Directory e define o modo pelo qual uma ACL específica se aplica a objetos filho em um dado contêiner ou subcontêiner. Seja sempre específico sobre o escopo de herança, garantindo que ACEs herdáveis sejam aplicadas a objetos de destino o mais próximo possível. As permissões de negação herdáveis aplicadas ao objeto pai terão precedência sobre qualquer permissão de negação aplicada ao objeto avô, o que constitui um dos principais motivos por que Deny ACEs não são recomendadas na delegação prática. Além disso, permissões herdáveis não podem substituir uma ACE explícita em um objeto. Por essa razão, recomenda-se que você limite ou elimine a capacidade de administradores em camadas para modificar a lista de controle de acesso discricionária (removendo o privilégio de gravação DACL) em objetos de diretório. (Observe que o criador do objeto tem esses direitos implicitamente). A regra geral é que, se um administrador tem a capacidade de alterar a DACL em um objeto, ele provavelmente o fará. Não permita que o trabalho árduo que a sua organização colocou em seu modelo de delegação vá para o lixo, introduzindo a opção e o erro administrativo potencial.

Existem várias ferramentas que você precisará usar para implementar corretamente um modelo de delegação do Active Directory. Para a maior parte das grandes organizações, o uso do Assistente de Delegação para atribuição de permissões no diretório é uma tarefa intimidadora comum, com possibilidade de erro administrativo. Em vez disso, deve-se sempre usar a automação, para garantir que o modelo de delegação fique bem documentado, que tenha suporte e forneça uma opção de recuperação, caso as configurações sejam de alguma forma perdidas ou alteradas acidentalmente.

A principal ferramenta requerida para implementação de delegação é o DSACLS.EXE, uma ferramenta de linha de comando usada para manipular ACLs de serviço de diretório em objetos. Essa ferramenta também permite que os sinalizadores de herança em uma DACL sejam especificados no objeto pai. (Os sinalizadores de herança incluem esse objeto e subobjetos e apenas subobjetos, e propagam permissões herdáveis em apenas um nível). Ocorrerá falha dos comandos DSACLS, no final das contas, se um sinalizador de herança for configurado incorretamente; portanto, é crucial fazer um teste ao usar essa ferramenta. Eis um exemplo da sintaxe DSACLS para delegar a capacidade de criar objetos de computador na UO de demonstração de destino:

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

O DSACLS faz distinção entre maiúsculas e minúsculas em relação a tipos de objeto. Isso significa que tentar delegar permissões para a classe de objeto "cn=Computer" sobre a "cn=computer" não irá funcionar (consulte a Figura 3).

Figura 3** Erro devido à diferenciação entre maiúsculas e minúsculas **(Clique na imagem para aumentar a exibição)

Um conjunto específico de direitos é necessário para criação de alguns objetos. Isso se relaciona a atributos "must contain" ("deve conter") e "may contain" ("pode conter") em objetos. A melhor metáfora que eu já ouvi para explicar esse conceito é o modelo de hambúrguer. O hambúrguer deve conter carne e pão de hambúrguer para ser considerado um hambúrguer. São esses os atributos must-contain da classe de objeto hambúrguer. Itens como conservas, molho de tomates, alface etc são atributos may-contain. Se estendermos a classe de objeto para definir um cheeseburguer, adicionaremos queijo à lista de atributos must-contain.

Objetos do usuário funcionam da mesma forma. Digamos que precisássemos seguir este modelo para criar objetos do usuário, utilizando a seguinte sintaxe DSACLS:

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

O administrador se depararia com vários erros durante a criação do objeto do usuário. Precisamos conceder os privilégios necessários para definir atributos requeridos no objeto do usuário, incluindo a definição da senha. Isso é descrito na sintaxe DSACLS adicional seguinte:

Na primeira etapa, conceda o privilégio para gravar atributos must-contain, concedendo leitura genérica/gravação genérica a todos os atributos da classe de usuário.

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

Na etapa seguinte, conceda o direito estendido para alterar a senha:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

Na etapa final, conceda os privilégios Propriedade de Leitura e Propriedade de Gravação ao atributo Password Last Set (Última Definição de Senha).

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

Depois de delegados os direitos adequados, as funções definidas serão limitadas apenas ao gerenciamento de classes de objeto definidas na DACL do contêiner. Usando o exemplo do objeto de computador anterior, o menu de contexto em Usuários e Computadores do Active Directory restringe a lista de novos objetos que podem ser criados pelo usuário a quem esses direitos foram delegados (consulte a lista na Figura 4).

Figura 4** Lista restrita de novos objetos **

Os DSACLS também podem ser automatizados para oferecer uma implantação complexa de direitos. Aqui estão alguns dos comandos DSACLS que podem ser usados para delegar direitos com o fim de manipular atributos de endereços comuns sobre objetos do usuário em um determinado contêiner.

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

Exemplos como esses são comuns para a maioria dos modelos de delegação e podem ser usados juntamente com as funções definidas previamente.

Outra ferramenta usada para implementar a delegação é o DSREVOKE.EXE, que permite aos administradores localizar e remover direitos delegados de entidades de segurança específicas dentro do diretório. Embora essa ferramenta seja bastante útil, ela é específica de uma entidade de segurança e não avalia a associação aninhada dentro de grupos de segurança.

Para além dessas ferramentas de linha de comando, também recomendamos enfaticamente o uso de Atribuição de Direitos de Usuário e Grupos Restritos com Diretiva de Grupo. Como discutido anteriormente, a Atribuição de direitos de usuário permite aos administradores de TI estender ou remover direitos de nível inferior (como o direito de acessar e reiniciar um sistema remotamente) para vários grupos de usuários em sistemas de destino específicos. Grupos restritos podem ser usados para especificar e aplicar a associação de grupo local e de domínio na floresta. Juntas, essas ferramentas fornecem todo o necessário para automatizar e implementar um modelo de delegação do Active Directory.

Resumo

Embora a tarefa de desenvolver um modelo de delegação do Active Directory possa parecer complexa, a verdade é que existem modelos muito simples que podem ser aplicados à maioria das infra-estruturas de TI. Uma das etapas mais importantes na implantação de um modelo de delegação prática é definir funções claras. Limite as funções definidas a um número pequeno e gerenciável. O equilíbrio é difícil, pois muitas funções resultarão em funções que não estão sendo usadas, enquanto muito poucas funções não permitirão a separação de função.

Lembre-se: ao definir tarefas, categorize-as por freqüência, importância e dificuldade. Após definir as funções, desenvolva um conjunto de casos de uso para ajudá-lo a identificar que função pode ou não realizar e automatizar o processo de teste. Casos de uso bem preparados o ajudarão a explicar essas funções às partes interessadas de sua organização, além de minimizar qualquer surpresa em razão de erros de automação.

Finalmente, é sempre aconselhável lançar mão de uma abordagem prática ao desenvolver um modelo de delegação. Lembre-se de que simplicidade equivale a flexibilidade de suporte e um modelo de delegação sustentável pagará dividendos imensos no controle de direitos administrativos dentro do seu ambiente do Active Directory.

Recursos adicionais

• Design Considerations for Delegation of Administration in Active Directory
• Best Practices for Delegating Active Directory Administration

Joel Yoker é um consultor sênior da equipe Microsoft Federal. Joel e Rob estão ambos concentrados no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.

Rob Campbell é um especialista técnico sênior da equipe Microsoft Federal. Joel e Rob estão ambos concentrados no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.

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