Cuidados ao manipular a base do Active Directory

Por: Renie Aloisi Mansur / Revisado por: Diana Hernandez

Introdução

A utilização de scripts ou programas, desenvolvidos com o intuito de manipular a base de dados do Active Directory é muito comum para agilizar tarefas específicas.

Esta prática, ao ser feita com os devidos cuidados, proporciona ganho de tempo para determinadas ações. Todavia, quando um detalhe passa despercebido ou há utilização sem devido controle, resultados indesejados podem ocorrer.

Descrição do problema

A queixa inicial do cliente era extrema demora ao acessar uma aplicação web que solicitava autenticação num domain controller. Um sintoma mencionado, era alta utilização do lsass.exe no domain controller usado, seguido de lentidão ou impossibilidade de logon na aplicação.

O próprio cliente identificara a causa deste problema :). A aplicação consultava um grupo de segurança para efetuar a autenticação do domínio... até aí, sem mistérios. Contudo, na semana onde o impacto foi percebido, durante a resolução do problema, o cliente identificou que o grupo de segurança utilizado na autenticação tinha como membro “ele mesmo”! Isto causava uma espécie de loop durante a autenticação, gerando a lentidão e demais sintomas negativos no domain controller e, conseqüentemente, na aplicação.

Com o problema do cliente resolvido (removendo o grupo “dele mesmo”), o seguinte questionamento foi levantado:

“Como um grupo poderia ser adicionado a ele mesmo se, por padrão, isso não seria permitido?”

Para esclarecer esta dúvida, dependemos da resposta de como a ação foi realizada. O cliente não tinha certeza do que acontecera por ser um post-mortem (problema que não mais ocorre com a solicitação de análise da causa), conseqüentemente, para nós, chegou a tarefa de confirmar o conceito e simular as possibilidades :).

Ações iniciais

Antes de tudo, precisamos entender qual é o comportamento normal do produto ao executar a operação.

Para tal, dois grupos de escopo global e de tipo segurança chamados “TESTE” e “TESTE2” foram criados. Este último era membro do “TESTE” e a idéia era fazer com que ele também fosse membro “dele mesmo”, eis o resultado:`

Como esperado, uma adição normal do grupo nele mesmo não foi permitida.

A partir deste momento, foi importante a geração de hipóteses de como o grupo foi adicionado “nele mesmo”. Se você também pensou num editor de baixo nível...sim...esta é uma possibilidade.

A adição de um grupo em outro, nada mais é que a alteração do atributo member ou memberOf do objeto em questão. Com isto em mente, a ação seguinte foi executar a mesma operação, utilizando o adsiedit.msc (ferramenta do support tools):

Porém, ao confirmar as alterações, tanto editando o atributo member, como memberOf a ação não era concluída, recebendo a mensagem abaixo (o que é esperado do ponto de vista do Active Directory):

Outra possibilidade seria a operação de escrita direta na base do Active Directory e entendimento de qual seria o comportamento apresentado. Para esse tipo de ação (dentre inúmeras outras úteis que esta ferramenta permite), podemos utilizar o ldp.exe. Para maiores informações sobre o ldp.exe, leia o white paper dele aqui:

Basicamente, tomamos os seguintes passos:

Conectamos ao domain controller utilizando a porta 389 (connection -> connect e bind);
Navegamos até o Menu View -> Tree;
Localizamos o objeto a ser editado, e selecionamos modify (Menu Browse);
Populamos o campo Values do atributo member com o Distinguished Name do objeto que seria adicionado a ele mesmo (CN=TESTE2,CN=Users,DC=B,DC=COM)
Finalmente, selecionamos add, clicamos em enter, seguido de Run

Após completar as ações acima, recebemos o seguinte resultado:

Bingo! Esse output indica que a alteração foi realizada com sucesso. Ao abrirmos o Active Directory Users and Computers, observamos o grupo sendo membro “dele mesmo”:

Explicamos ao cliente que, provavelmente um script ou programa foi executado, fazendo o acesso com privilégio elevado à base do Active Directory. Ou ainda, na pior das hipóteses, um usuário mal intencionado teria feito a alteração. O fato é que, independente de como, necessariamente, privilégios administrativos seriam exigidos.

Conclusão

Posteriormente, o cliente identificou que alguém, indevidamente, executou um script com ações semelhantes, que, causara a alteração da base do AD.

O importante neste caso foi esclarecer que, um ponto é o comportamento padrão do sistema operacional (por exemplo, adicionando o grupo pela GUI), outro é quando você escreve diretamente na base do Active Directory com permissões elevadas, assim, alterando seu comportamento padrão.