Início > Active Directory, Nesting Groups, Windows Server, Windows Server 2003/R2, Windows Server 2008/R2, Windows Server 2012/R2 > Active Directory – Entendendo o conceito de “Nested Groups” e boas práticas

Active Directory – Entendendo o conceito de “Nested Groups” e boas práticas

junho 16, 2014

Olá pessoALL,

Vou escrever um pouco sobre um conceito que muitas vezes não é bem aplicado por não ser bem compreendido por quem administra uma infraestrutura de Directory Services. O conceito de “Nested Groups” e a sua utilização como boa prática de gerenciamento de grupos.

Antes de implementar uma infraestrutura de grupos em sua infraestrutura de Directory Service, você deve ter em mente os conceitos, diferenças entre cada tipo de grupo disponível, escopo, convenção de nomes, etc. que podem ser criados para que o gerenciamento destes objetos se torne fácil e a identidade de cada grupo lhe permita saber qual é a sua finalidade.

Um exemplo prático de uso e também de problemas que você pode encontrar em seu dia a dia é um uso de contas de usuários VS grupos de acesso para informar quem pode acessar determinado recurso em sua rede ou não.

Imagine a seguinte situação:

  • você possui um diretório compartilhado.
  • você precisa conceder privilégios de acesso a este diretório para um grupo de usuários.

Como realizar esta ação de forma eficiente? Não é incomum encontrar profissionais de IT que gerenciam uma infraestrutura de Directory Services fazendo este tipo de tarefa de forma complementa ineficiente concedendo privilégios para contas de usuários ao invés de utilizar grupos de acessos.

A princípio, pode parecer trivial e não lhe apresentar nenhum tipo de impacto inserir contas de usuários ao invés de grupos na ACL de um diretório, mas a verdade é que isto gera um processamento complemente desnecessário em background, que normalmente não é conhecido por quem faz este tipo de implementação.

Deixe me esclarecer o que este tipo de situação gera como resultado. Primeiramente, quem faz o desenho dos grupos a serem criados e utilizados em uma infraestrutura de Directory Services precisa conhecer como funciona a verificação de privilégios e garantia de acessos no AD DS.

Quando você cria um compartilhamento e insere em sua ACL, por exemplo, 30 contas de usuários com os privilégios necessários, quando um usuário faz o acesso a este compartilhamento, todas as entradas de cada usuário informada na ACL do diretório são lidas e verificadas para saber se o SID da conta do usuário confere com um dos SIDs disponíveis na ACL do diretório. Estes seriam os passos para que o usuário tenha acesso ao diretório:

  1. O usuário efetua logon em seu computador com seu usuário e senha.
  2. O processo de logon faz contato com o KDC (Key Distribution Center) que é parte do AD DS para validar através da função de AS (Autentication Service) se o usuários e as suas credenciais são válidas.
  3. Credencias validadas, o usuário recebe do AS um TGT (Ticket Granting Ticket) que essencialmente é um ticket de autenticação.
  4. O usuário submete seu TGT para KDC novamente, mas desta vez para a função TGS (Ticket Granting Server) que o verifica e devolve para o usuário um Session Ticket (Access Token) contendo o SID (Security Identifier) de sua própria conta, o SID dos grupos a qual conta pertence, a lista de privilégios de acesso que a conta possui entre outras informações de acesso.
  5. De posse do Session Ticket, o usuário tenta acessar um diretório compartilhado em um servidor remoto e fornece o seu Session Ticket para o servidor onde o diretório está localizado.
  6. Um subsistema de segurança verifica então cada SID presente nas ACEs (Access Control Entries) da DACL (Discretionary Access Control List) do diretório compartilhado e compara com os SIDs disponíveis no Session Ticket sumetido pelo usuário que deseja acessar o diretório.
  7. Se um ou mais SIDs nas ACEs da DACL do diretório compartilhado combinar com um ou mais SIDs disponíveis no Session Ticket submetido pelo usuário, o subsistema de segurança verifica qual é o tipo da ACE (se é um ACE do tipo Permitir ou do tipo Negar) e então concede o acesso ao usuário.
  8. Caso nenhum SID que combine com qualquer SID disponível no Session Ticket do usuário for encontrado, o acesso é negado.

Este tipo de verificação toma um tempo de processamento desnecessário, pois caso você tenha diversos usuários inseridos na DACL do diretório, isto fará com que o subsistema de segurança tenha que enumerar vários SIDs até encontrar um SID que combine ou não com um ou mais SIDs do usuário que deseja acessar o recurso.

Quando você cria um grupo, insere os mesmos 30 usuários dentro deste grupo e o insere na ACL deste diretório, seguindo as melhores práticas da Microsoft que é a criação de um grupo para leitura e outro para leitura e escrita, você reduz consideravelmente este processamento necessário para verificar a combinação de SIDs e concessão de acessos, por reduzir o número de ACEs a serem verificadas no diretório.

Quando estamos falando de grupos de usuários, precisamos ter em mente que este tipo de estratégia tem como objetivo facilitar o gerenciamento e a concessão de acessos para usuários.

É muito importante para quem faz o gerenciamento de grupos no AD DS entender os tipos de grupos e cenários onde você deve utilizá-los. Em uma infraestrutura com poucos usuários, digamos 30 usuários, pode não fazer tanta diferença para o gerenciamento, mas tente imaginar uma infraestrutura com milhares de contas de usuários, diversos setores, etc. como seria determinar quem possui acesso a um recurso de rede, se a DACL deste recurso possui 500 contas de usuários e cada uma podendo ter caracteristicas diferentes em sua ACE?

Experimente olhar para sua infraestrutura e imaginar como seria a atividade de realizar uma auditoria de acesso em diretórios que possuem informações sensíveis e críticas ao seu negócio? Tenha em mente que alguns segmentos de negócios sofrem auditorias rígidas de orgãos públicos/privados que visam garantir que o acesso a determinadas informações é controlado e passível de ser auditado no menor tempo possível em caso de acesso indevido.

Tenha em mente ainda que documentar estes acessos e controlá-los sem o uso de grupos pode ser um completo pesadelo se o número de objetos a serem auditados for grande demais e pode se tornar confuso tanto para quem gerencia, quanto para quem deseja interpretar quem possui ou não algum privilégio de acesso.

Sabendo destas questões, mas não se limitando apenas a elas, pois há diversos outros fatores que justificam o uso de grupos, como melhorar sua infraestrutura usando grupos de forma eficiente?

Entenda o conceito de Nesting Group!

Nesting Group é um processo de agrupamento de grupos por inserir grupos dentros de outros grupos para criar um hierarquia que reflita as funções de negócios e permita o gerenciamento dos acessos destas funções.

Quando falamos de Nested Groups, é imprescindível falamos de um termo chamado IGDLA que significa Identities, Global Groups, Domain Local Groups e Access. O que estes itens especificam?

  • Identities: são contas de usuário/computador que são membro de um grupo.
  • Global Groups: são grupos que representam um função de negócio – vendas, pesquisa, contabilidade, compras, etc.
  • Domain Local Groups: são grupos que representam o nível de acesso que uma ou mais funções devem ter em um diretório – leitura, leitura e escrita, etc.
  • Access: representa a ação de inserir um Domain Local Group na ACL de um diretório com os privilégios que este grupo necessita ter – leitura, leitura e escrita, etc.

Abaixo você pode ver uma exemplo de IGDLA sendo aplicado em um cenário comum encontrado no dia a dia.

adds-nested-groups-0001

Qual a vantagem de se usar uma abordagem de agrupamento de grupos do tipo IGDLA? Ter apenas um ponto de gerenciamento para determinar quem tem acesso de leitura e leitura e escrita no diretório Research que são os grupos ACL_RESEARCH_READ e ACL_RESEARCH_WRITE. Os usuários devem ser inseridos dentro do grupo de função e o grupo de função inserido dentro do grupo de gerenciamento.

Defina um padrão para o nome dos grupos

É muito importante a definição do nome dos grupos, pois a partir deste detalhe, você irá permitir que seja interpretado qual é o objetivo de determinado grupo, seja ele de privilégios de acesso, de setor, etc.

Para definir o padrão de nomes para os grupos, siga os seguintes conceitos:

  • Grupos de função: devem possuir o nome propriamente dito da função que ele representa – vendas, pesquisa, etc. -, ser único e por convenção e boa prática, pode se acrescentar ao final o sufíxo _USERS.
  • Grupos de gerenciamento: devem possuir um préfixo, nome do recurso representado e um sufíxo combinados usando o underscore (_) para demilitar cada porção.
    • prefixo: identificador do propósito do grupo – ACL (Access Control List)
    • recurso representado: identificador do nome do diretório – RESEARCH_FLD (FLD = Folder)
    • sufíxo: nível de acesso – READ, WRITE, etc.
    • delimitador: ACL_RESEARCH_FLD_READ, ACL_RESEARCH_FLD_WRITE.

Embora a Microsoft recomende o uso de nomes como GG_RESEARCH_USERS, ACL_RESEARCH_FLD_READ, UG_RESEARCH_FLD_READ, etc., esta não é uma regra literalmente, mas uma boa prática para que a visualização destes objetos se torne intuitiva para uma pessoa que precise entender o propósito de um grupo.

  • GG = Global Group
  • DLG = Domain Local Group
  • UG = Universal Group

Tente imaginar que hoje um novo colaborador inicou em sua instituição e ele será responsável por gerenciar os objetos de sua infraestrutura de serviço de diretório. Se houver um padrão na nomenclatura, isto irá facilitar o entendimento desta pessoa sobre como e qual grupo utilizar no momento de realizar o seu trabalho de gerenciamento.

Outro ponto muito importante aqui e que deve ser ponderado é o comprimento do nome dos grupos, pois se fossemos seguir a risca as orientações sobre a nomenclatura, poderemos ter nomes muito longos quando há uma necessidade de segregar o acesso a subdiretórios.

Vamos imaginar que existe um diretório compartilhamdo chamado RESEARCH e que dentro do mesmo, existam diversos outros níveis de subdiretórios. Seguindo a recomendação, se houver a necessidade de segregar o acesso do diretório RESEARCH\PROJECTS\CLASSIFIED, deveriamos criar um grupo do tipo Domain Local Group com o seguinte nome:

  • ACL_RESEARCH_PROJECTS_CLASSIFIED_READ
  • ACL_RESEARCH_PROJECTS_CLASSIFIED_WRITE

Acima está um exemplo de três (3) níveis de subdiretórios, mas e se existissem dez (10) níveis? Seria uma boa prática compor o nome do grupo com todos os níveis? É neste momento que você deve usar do bom senso para a criação de seus grupos. Mas como deixar claro qual é o propósito do grupo com um nome que não representa literalmente o recurso que ele tem como objetivo permitir um certo nível de acesso?

Minha recomendação é: use e abuse da descrição de seus objetos no Active Directory! Por mais dificil que seja acreditar, é comum encontramos ambientes com centenas de milhares de objetos sem uma descrição do seu objetivo. Use este campo de forma clara e objetiva para descrever qual é o objetivo de tal objeto e principalmente o local onde ele será usado.

adds-nested-groups-0002

Entendendo os tipos de grupos

É importante saber quais são os tipos de grupos disponíveis e quais são os casos de uso para cada um deles. Existe 2 tipos de grupos:

  • Grupos de distribuição: este tipo de grupo é usado apenas para mensageria, ou seja, pelo Microsoft Exchange Server e não pode ser usado para dar permissões, pois não possui um SID.
  • Grupos de segurança: este tipo de grupo é usado para garantir privilégios em recursos pois possui um SID e também pode ser usado para receber mensageria.

Entendendo o escopo de cada grupo

Existem 4 escopos de grupo:

  • Local
  • Domain Local
  • Global
  • Universal

Cada escopo possui caracteristicas que distinguem uns dos outros como:

  • Replicação: onde o grupo e seus membros estão armazenados?
  • Associação: quais tipo de objetos e de quais domínios podem ser membro de um grupo?
  • Disponibilidade/escopo: onde o grupo pode ser usado? Em quais escopos de grupo o grupo pode ser membro? O grupo pode ser adicionado a uma ACL?

Vamos agora entender as caracteristicas de cada grupo disponível.

Local Group
Replicação:
Existe apenas localmente no servidor/computador e está armazendo no SAM
Associação não é replicada para qualquer outro servidor/computador.
Associação: podem ter como membro.
Contas de usuário, contas de computador, GlobalGroups, Domain Local Groups do domínio.
Contas de usuário, contas de computator e Global Groups de qualquer domínio na floresta.
Contas de usuário, contas de computator e Global Groups de qualquer domínio confiável.
Universal Groups de qualquer domínio da floresta.
Disponibilidade/Escopo:
Limitado apenas ao computador/servidor onde esta disponível e uso em ACEs locais.
Não pode ser membro de outros grupos.

Utilização: em grupos de trabalho ou Workgroups para gerenciar o acesso a recursos locais como pastas compartilhadas, etc.

Domain Local Group (usado para delegar permissões em recursos)
Replicação:
Definido no contexto de nome de domínio.
Replicado para cada Domain Controller no domínio.
Associação: podem ter como membro.
Contas de usuário, contas de computador, Global Groups, Domain Local groups do domínio.
Contas de usuário, contas de computator e Global Groups de qualquer domínio na floresta.
Contas de usuário, contas de computator e Global Groups de qualquer domínio confiável.
Universal Groups de qualquer domínio da floresta.
Disponibilidade/Escopo:
Pode ser inserido em uma ACL em qualquer computador/servidor membro do domínio.
Pode ser membro de outros Domain Local Groups ou de Local Groups.

Utilização: são usados para gerenciar as permissões de acesso em recursos disponíveis em computadore/servidores membros do domínio.

Global Group (usado para conter usuários de um departamento)
Replicação:
Definido no contexto de nome de domínio.
Replicado para cada Domain Controller no domínio.
Associação: podem ter como membro.
Apenas contas de usuário, contas de computador, Global Groups, Domain Local groups do mesmo domínio.
Disponibilidade/Escopo:
Uso em qualquer domínio na floresta, todos os membros do domínio e em todos os Trusting External Domains.
Pode ser inserido na ACLs de qualquer servidor/computador em qualquer um dos domínios.
Pode ser membro de um Domain Local Group ou Universal Group na floresta ou um Domain Local Group em um Trusting External Domain.

Utilização: usado para agrupar objetos de um determinado segmento do negócio que identifica a sua associação, por exemplo, um departamento chamado Vendas.

Universal Group (usado para Multidomain Forests)
Replicação:
Definido em um único domínio na floresta.
Replicado para o Global Catalog (Forest-Wide).
Associação: podem ter como membro.
Contas de usuário, contas de computador, Global Groups, Universal Groups de qualquer domínio da floresta.
Disponibilidade/Escopo:
Disponível para qualquer domínio e qualquer membro do domínio na floresta.
Pode ser inserido na ACLs de qualquer servidor/computador em qualquer um dos domínios da floresta.
Pode ser membro de um Domain Local Group ou Universal Group em qualquer lugar da floresta.

Utilização: este tipo de grupo pode ser usado com o mesmo próposito do Domain Local Group ou Global Group e seu uso depende do tipo de cenário. O caso mais comum de uso deste tipo de grupo é para gerenciar e garantir acesso a recursos em uma floresta que possui vários domínios.

De forma mais geral, a tabela abaixo também exemplifica o que nós acabamos de ver anteriormente com relação aos grupos:

Group Scope Members from the Same Domain Members from Another Domain in the Same Forest Members from a Trusted External Domain
Local
Users
Computers
Global groups
Universal groups
Domain local groups
Also, local users defined on the same computer as the local group
Users
Computers
Global groups
Universal groups
Users
Computers
Global groups
Domain Local
Users
Computers
Global groups
Domain local groups
Universal groups
Users
Computers
Global groups
Universal groups
Users
Computers
Global groups
Universal
Users
Computers
Global groups
Universal groups
Users
Computers
Global groups
Universal groups
N/A
Global
Users
Global groups
N/A N/A

Caso prático de uso

Deixe me mostrar uma situação comum onde o uso de nested group é necessário juntamente com o entendimento dos tipos de grupos, suas associações, disponibilidade e escopo.

Vamos imaginar o seguinte cenário:

  • Uma (1) floresta
  • Dois (2) domínios chamados NOSAFEFORWORK.LOCAL e ALKAHOLICS.LOCAL
  • Um (1) diretório compartilhado chamado RESEARCH em um servidor membro de cada domínio
  • Membros do grupo RESEARCH no domínio NOSAFEFORWORK.LOCAL precisam ter privilégio de leitura e escrita no diretório RESEARCH de seu domínio e privilégios de somente leitura no diretório RESEARCH no domínio ALKAHOLICS.LOCAL
  • Membros do grupo RESEARCH no domínio ALKAHOLICS.LOCAL precisam ter privilégio de leitura e escrita no diretório RESEARCH de seu domínio e privilégios de somente leitura no diretório RESEARCH no domínio NOSAFEFORWORK.LOCAL

Com base no cenário acima, qual seria a sua solução para resolver esta demanda? Vamos aos passos necessários!

  1. Crie dois (2) grupos do tipo Domain Local Group no domínio NOSAFEFORWORK.LOCAL chamados ACL_NSFW_RESEARCH_FLD_READ e ACL_NSFW_RESEARCH_FLD_WRITE.
  2. Inclua estes grupos nas permissões do diretório RESEARCH no servidor membro do domínio NOSAFEFORWORK.LOCAL atribuindo as permissões necessárias para cada grupo.
  3. Crie dois (2) grupos do tipo Domain Local Group no domínio ALKAHOLICS.LOCAL chamados ACL_ALKA_RESEARCH_FLD_READ e ACL_ALKA_RESEARCH_FLD_WRITE.
  4. Inclua estes grupos nas permissões do diretório RESEARCH no servidor membro do domínio ALKAHOLICS.LOCAL atribuindo as permissões necessárias para cada grupo.
  5. Crie um (1) grupo do tipo Global Group no domínio NOSAFEFORWORK.LOCAL chamado NSFW_RESEARCH_USERS.
  6. Crie um (1) grupo do tipo Global Group no domínio ALKAHOLICS.LOCAL chamado ALKA_RESEARCH_USERS.
  7. Inclua o grupo NSFW_RESEARCH_USERS dentro do grupo ACL_NSFW_RESEARCH_FLD_WRITE no domínio NOSAFEFORWORK.LOCAL.
  8. Inclua o grupo ALKA_RESEARCH_USERS dentro do grupo ACL_ALKA_RESEARCH_FLD_WRITE no domínio ALKAHOLICS.LOCAL.
  9. Inclua os usuários do time de RESEARCH que necessitam de acesso de leitura e escrita no diretório RESEARCH do domínio NOSAFEFORWORK.LOCAL dentro do grupo criado no passo 5.
  10. Inclua os usuários do time de RESEARCH que necessitam de acesso de leitura e escrita no diretório RESEARCH do domínio ALKAHOLICS.LOCAL dentro do grupo criado no passo 6.
  11. Crie um (1) grupo do tipo Universal Group em qualquer domínio chamado UG_ACL_RESEARCH_FLD_READ.
  12. Inclua o grupo NSFW_RESEARCH_USERS dentro do grupo UG_ACL_RESEARCH_FLD_READ no domínio NOSAFEFORWORK.LOCAL.
  13. Inclua o grupo ALKA_RESEARCH_USERS dentro do grupo UG_ACL_RESEARCH_FLD_READ no domínio ALKAHOLICS.LOCAL.
  14. Inclua o grupo UG_ACL_RESEARCH_FLD_READ dentro do grupo ACL_NSFW_RESEARCH_FLD_READ no domínio NOSAFEFORWORK.LOCAL.
  15. Inclua o grupo UG_ACL_RESEARCH_FLD_READ dentro do grupo ACL_ALKA_RESEARCH_FLD_READ no domínio ALKAHOLICS.LOCAL.

Após efetuar os passos anterioes, você teria este tipo de solução aplicada para resolver este cenário:

adds-nested-groups-0003

Como podemos ver, este não é um conceito complicado de ser entendido e sua implementação é simples.

No entanto, este conceito precisa estar muito claro na mente de quem implementa/gerencia grupos, pois será de grande ajuda no momento de realizar um throubleshooting para a solução de problemas.

Ponto de atenção!

Embora os conceitos anteriores sejam uma boa prática, eles podem ser perigosos caso o número de grupos associados a uma conta de usuário for muito grande gerando um problema chamado Token Bloat.

Mas o que seria um problema de Token Bloat?

Quando um usuário faz logon em sua estação de trabalho ele solicita ao KDC um Access Token que contem todos os SIDs dos grupos que ele pertence. Este Access Token é utilizado toda vez que esta conta tenta acessar um recurso, seja ele um compartilhamento de rede, um base de dados SQL, etc. para validar se você possui permissões para aquela ação e quais são estas permissões de acesso.

Por padrão, nas versões Windows 2000 Server SP2+, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 and Windows Server 2008 R2 o tamanho máximo de um Access Token é de 12,000 bytes. No Windows Server 2012/R2 este limite foi aumentado para 48,000 bytes para permitir o uso do recurso de Dynamic Access Control (DAC).

A título de exemplo, um SID de um grupo do tipo Domain Local ocupa 40 bytes de espaço em um Access Token, enquanto um SID de um grupo do tipo Global e/ou Universal ocupam 8 bytes. Pois bem, se um Access Token possui um tamanho pré definido de 12,000 bytes para as versões anteriores ao Windows Server 2012 e cada SID inserido dentro do mesmo ocupa um espaço também pré determinado para ser armazenado, isso representa um problema, pois há um limite (normalmente 900) de grupos cujo um usuário pode ter em seu Access Token.

Mas qual é o problema? Bem, quando você ultrapassa o limite de tamanho em seu access token, o Kerberos não é capaz de armazenar em buffer suas informações de autorização de acesso (SIDs) o que impede você normalmente de efetuar o logon em estações de trabalho, acessar recursos de rede, entre outros recurso que façam uso do Kerberos para lhe garantir acesso.

Em ambientes pequenos e médios, este limite normalmente não é alcançado, mas em ambientes de grande porte e com alta complexidade, optar por uma abordagem do tipo IGDLA (o que pode ser entendido como Resource Based Groups) pode ser um grande risco e também representar um tempo de tarbalho investido desnecessário, pois, você terá que optar por outro tipo de aborgadem, como por exemplo, RBAC ou pensando em grupos Role Based Groups.

Existem maneiras de mitigar este problema aumentando o tamanho do buffer disponível para o Access Token e isto é conhecido pelo nome de MaxTokenSize.

MaxTokenSize é o nome do valor que precisa ser criado no registro de cada cliente/servidor membro do domínio para permitir que um número maior de grupo seja possível caso não seja possível reduzir o número atual de grupos. O procedimento para o aumento do buffer pode ser encontrado no KB abaixo, tal como instruções de como implementar este valor através de Group Policy Object:

How to use Group Policy to add the MaxTokenSize registry entry to multiple computers

Mas o procedimento no KB anterior resolve definitivamente a questão relacionada com Token Size? A resposta é, depende…

Se por um lado é possível aumentar o tamanho do buffer disponível para o Token Size, por outro lado nós temos uma restrição em um nível mais baixo (sistema operacional) que determina um limite de 1015 grupos aos quais um objeto pode ser membro.

A bem da verdade, aumentar o tamanho do buffer para o Token Size pode ser apenas uma forma de lhe dar uma pequena folga até que o problema volte a ocorrer, ou seja, uma false sensação de problema resolvido.

Como mitigar ou resolver então este tipo de problema? Existem várias abordagens para isto:

  • auditar o AD DS e procurar por grupos que estejam associados a um objeto, mas que de fato não estejam sendo usados e removê-los.
  • usar grupos globais/universais ao invés de Domain Local pelo fato de seu SID ocupar um espaço menor se o uso for apenas em uma única floresta/domínio.
  • implementar uma abordagem de Role Based Groups, ou seja, criar um grupo chamado App 1 Admins e associar este grupo a todos os recursos relacionados com a App 1.
  • caso os objetos tenha sido migrados de outro domínio, limpar o atributo sIDHistory que também faz uso do buffer do Token Size.
  • Migrar para o Windows Server 2012/R2 para utilizar o buffer de 48,000 bytes, o novo sistema de compressão de SIDs implementado e/ou utilizar o Dynamic Access Control (DAC).
  • etc.

Em resumo, escolher e gerenciar uma infraestrutura de grupos no AD DS pode parecer algo trivial, mas existem fatores e comportamentos que se não forem levado em consideração no momento de sua decisão, afetarão seu negócio de forma significativa.

É isto pessoal! Espero que a informação e o conceito seja útil para o dia a dia de vocês e que isto tenha esclarecido um pouco o conceito e o uso de agrupamento de grupos ou nesting group.

Até o próximo post…

%d blogueiros gostam disto: