4.1 Entendendo o modelo de delegação dinâmica

O DRA permite gerenciar o acesso administrativo à sua empresa no contexto de um modelo de delegação. O modelo de delegação permite que você configure acesso de “privilégio mínimo” para administradores assistentes por meio de um conjunto dinâmico de controles que podem se adaptar à medida que a empresa muda e evolui. O modelo de delegação fornece controle de acesso administrativo que representa mais de perto como sua empresa funciona:

  • Com regras de escopo flexíveis, os administradores podem direcionar permissões para objetos gerenciados específicos com base nas necessidades comerciais, em vez da estrutura da empresa.

  • A delegação baseada em funções garante que as permissões sejam concedidas de forma consistente e simplifica o aprovisionamento.

  • A designação de privilégios pode ser administrada em domínios, locatários da nuvem e aplicativos gerenciados de um único local.

  • Poderes granulares permitem que você personalize o acesso específico concedido aos administradores assistentes.

4.1.1 Controles do modelo de delegação

Os administradores usam os seguintes controles para provisionar o acesso por meio do modelo de delegação:

  • Delegação: Os administradores provisionam acesso a usuários e grupos, atribuindo uma função que especificou permissões no contexto de uma ActiveView que fornece o escopo.

  • ActiveViews: Uma ActiveView representa um escopo específico de objetos gerenciados que são definidos por uma ou mais regras. Objetos gerenciados identificados por cada regra em uma ActiveView são agregados em um escopo unificado.

  • Regra da ActiveView: As regras são definidas por expressões que correspondem a um conjunto de objetos gerenciados com base em várias condições, como tipo de objeto, local, nome e assim por diante.

  • Funções: Uma função representa um conjunto específico de poderes (permissões) necessários para executar uma função de administração específica. O DRA fornece várias funções integradas para funções de negócios comuns e você pode definir funções personalizadas que melhor atendem às necessidades da sua organização.

  • Poderes: Um poder define uma permissão específica para tarefas suportadas pelo objeto gerenciado, como exibir, modificar, criar, apagar e assim por diante. As permissões em torno da modificação de um objeto gerenciado podem ser subdivididas nas propriedades específicas que podem ser mudadas. O DRA fornece uma lista extensa de poderes incorporados para objetos gerenciados suportados e pode definir poderes personalizados para estender o que pode ser provisionado por meio do modelo de delegação.

4.1.2 Como o DRA processa solicitações

Quando o servidor de Administração recebe uma solicitação para uma ação, como mudar uma senha de usuário, ele usa o seguinte processo:

  1. Pesquise por ActiveViews que estão configuradas para gerenciar o objeto de destino da operação.

  2. Valide os poderes atribuídos à conta que está solicitando a ação.

    1. Avalie todas as atribuições da ActiveView que contenham o administrador assistente solicitando a operação.

    2. Quando essa lista estiver concluída, crie uma lista de todas as ActiveViews que contenham o objeto de destino e o administrador assistente.

    3. Compare os poderes com os poderes necessários para a operação solicitante.

  3. Se a conta tiver o poder correto, o servidor de Administração permitirá que a ação seja executada.

    Se a conta não tiver o poder correto, o servidor de administração retornará um erro.

  4. Atualizar o Active Directory.

4.1.3 Exemplos de como o DRA processa atribuições de delegação

Os exemplos a seguir descrevem cenários comuns que surgem em como o DRA avalia o modelo de delegações ao processar uma solicitação:

Exemplo 1: Mudando a senha de um usuário

Quando um administrador assistente tenta definir uma nova senha para a conta do usuário JSmith, o servidor de Administração localiza todas as ActiveViews que incluem JSmith. Essa pesquisa procura por qualquer ActiveView que especifique JSmith diretamente, por meio de uma regra curinga ou por meio da participação do grupo. Se uma ActiveView incluir outras ActiveViews, o servidor de Administração também pesquisará essas ActiveViews adicionais. O servidor de Administração determina se o administrador assistente tem o poder Redefinir Senha da Conta do Usuário em qualquer uma dessas ActiveViews. Se o administrador assistente tiver o poder Redefinir Senha da Conta do Usuário, o servidor de Administração redefinirá a senha para JSmith. Se ele não tiver esse poder, o servidor de administração negará a solicitação.

Exemplo 2: Sobrepondo as ActiveViews

Um poder define as propriedades de um objeto que um administrador assistente pode exibir, modificar ou criar em seu domínio gerenciado ou subárvore. Mais de uma ActiveView pode incluir o mesmo objeto. Esta configuração é chamada sobrepondo ActiveViews.

Quando as ActiveViews se sobrepõem, você pode acumular um conjunto de diferentes poderes sobre os mesmos objetos. Por exemplo, se uma ActiveView permitir que você adicione uma conta do usuário a um domínio e outra ActiveView permita apagar uma conta do usuário do mesmo domínio, você poderá adicionar ou apagar contas de usuário nesse domínio. Desta forma, os poderes que você tem sobre um determinado objeto são cumulativos.

É importante entender como as ActiveViews podem se sobrepor e você pode ter mais poderes sobre os objetos incluídos nelas. Considere a configuração da ActiveView ilustrada na figura a seguir.

As guias brancas identificam as ActiveViews por local New York City e Houston. As guias pretas identificam as ActiveViews por sua função organizacional, Vendas e Marketing. As células mostram os grupos incluídos em cada ActiveView.

O grupo NYC_Sales e o grupo HOU_Sales são ambos representados na ActiveView de Vendas. Se você tiver poder na ActiveView de Vendas, poderá gerenciar qualquer membro dos grupos NYC_Sales e HOU_Sales. Se você também tiver poder na ActiveView de Nova York, esses poderes adicionais serão aplicados ao grupo NYC_Marketing. Dessa forma, os poderes se acumulam quando as ActiveViews se sobrepõem.

A sobreposição de ActiveViews pode fornecer um modelo de delegação eficiente e flexível. No entanto, esse recurso também pode ter consequências não intencionais. Planeje cuidadosamente suas ActiveViews para garantir que cada AA tenha apenas os poderes que você pretende em cada conta do usuário, grupo, OU, contato ou recurso.

Grupos em várias ActiveViews

Neste exemplo, o grupo NYC_Sales é representado em mais de uma ActiveView. Os membros do grupo NYC_Sales são representados na ActiveView de Nova York porque o nome do grupo corresponde à regra de ActiveView NYC_*. O grupo também está na ActiveView de Vendas porque o nome do grupo corresponde à regra de ActiveView *_Sales. Ao incluir o mesmo grupo em várias ActiveViews, você pode permitir que diferentes administradores assistentes gerenciem os mesmos objetos de maneira diferente.

Usando poderes em várias ActiveViews

Suponha que haja um administrador assistente, JSmith, que tenha o poder Modificar Propriedades Gerais do Usuário na ActiveView New York City. Esse primeiro poder permite que JSmith edite todas as propriedades na guia General (Geral) de uma janela de propriedades do usuário. JSmith tem o poder Modificar Propriedades de Perfil do Usuário na ActiveView de Vendas. Esse segundo poder permite que JSmith edite todas as propriedades na guia Perfil de uma janela de propriedades do usuário.

A figura a seguir indica os poderes que JSmith tem para cada grupo.

JSmith tem os seguintes poderes:

  • Propriedades gerais na ActiveView NYC_*

  • Propriedades de perfil na ActiveView *_Sales

A delegação de poder nessas ActiveViews sobrepostas permite que JSmith modifique as propriedades General (Geral) e de Perfil do grupo NYC_Sales. Assim, JSmith tem todos os poderes concedidos em todas as ActiveViews que representam o grupo NYC_Sales.