4 min de leitura

Quantas contas têm controle total do seu Active Directory?

Se você respondeu olhando quantas estão em Domain Admins, o número está errado. E provavelmente errado por muito.

Em uma auditoria de grupos privilegiados que eu fiz, num ambiente enterprise, o grupo Domain Admins tinha dezenas de contas, o que já é problema por si só. Mas o número real de contas com poder equivalente ao de administrador de domínio era bem maior, porque estava espalhado por grupos que ninguém chama de privilegiados.

E nenhum deles apareceria num relatório que olha só o grupo óbvio.


Os grupos que deveriam estar vazios

O Active Directory cria, no momento em que o domínio nasce, uma coleção de grupos administrativos. Eles vivem em dois lugares diferentes: alguns no container Builtin, outros no container Users do domínio.

Os do container Builtin são grupos domain local: existem em cada domínio e não replicam entre eles. Os do container Users são global ou universal, e alguns valem para a floresta inteira. Essa distinção não é cosmética, e é ela que explica por que o script mais adiante precisa de dois blocos.

Alguns desses grupos existem para operações raras e específicas. A recomendação da Microsoft, para esses, é a mesma: mantenha vazio, adicione alguém só durante a operação, remova depois.

Quase ninguém faz isso.

Schema Admins. Quem está aqui pode modificar o schema do Active Directory: adicionar classes de objeto, criar atributos novos, alterar a definição do que existe no diretório. É uma operação irreversível que afeta a floresta inteira, e acontece talvez duas ou três vezes na vida de um ambiente, quando se instala algo como Exchange ou um conector de sincronização.

Enterprise Admins. Poder sobre toda a floresta, incluindo domínios que ainda nem existem. Mesmo raciocínio: existe para operações estruturais, não para o dia a dia.

Account Operators. Este é o mais interessante, e o mais ignorado. Quem está neste grupo pode criar, modificar e deletar contas de usuário e grupos em boa parte do diretório. Sem ser Domain Admin. Sem aparecer em nenhum relatório de conta privilegiada.

Com o grupo vazio, é só potencial. Com membros dentro, é poder real.

Print Operators. O grupo parece inofensivo pelo nome, mas quem está nele pode carregar drivers de impressora nos Domain Controllers. Driver roda em kernel. É um vetor de escalonamento conhecido.

Server Operators. Pode parar e iniciar serviços nos Domain Controllers, e fazer backup deles. É poder suficiente para derrubar a autenticação do domínio inteiro, ou para levar embora o mesmo arquivo que o Backup Operators leva.


O grupo que é quase um Domain Admin

Backup Operators merece parágrafo próprio.

Quem está neste grupo pode fazer backup de qualquer arquivo em qualquer Domain Controller, ignorando as permissões de arquivo. Isso soa administrativo e chato, até você lembrar do que existe num DC.

O arquivo C:\Windows\NTDS\ntds.dit é o Active Directory inteiro: todos os usuários, todos os grupos, e todos os hashes de senha do domínio.

Quem consegue fazer backup dele consegue levá-lo embora. E quem tem o ntds.dit junto com o SYSTEM hive tem, na prática, a senha de todo mundo.

Backup Operators é quase um Domain Admin, com outro nome. A diferença é que ninguém o trata assim, porque o nome não assusta e ele não aparece nos relatórios de privilégio.


Por que a sua soma está errada

Um relatório de "contas privilegiadas" olha Domain Admins e talvez Enterprise Admins. Isso deixa de fora Account Operators, Server Operators, Backup Operators, Print Operators, e o grupo Administrators.

Cada um desses concede algum caminho para controle total, direto ou indireto. Alguns exigem um passo a mais, um driver malicioso, um backup levado embora, uma conta criada onde não devia. Mas o destino é o mesmo.

A pergunta que vale, então, não é "quem está em Domain Admins". É:

Quantas contas, somando todos os caminhos, conseguem chegar a controle total do domínio?

Esse número é sempre maior do que a primeira resposta. Às vezes muito maior.


Como fazer essa soma no seu ambiente

Os grupos administrativos do AD têm identificadores fixos, iguais em qualquer domínio do mundo. Isso permite auditá-los sem depender do idioma do sistema, o que importa se o seu ambiente estiver em português e os nomes vierem traduzidos.

powershell

$dom = (Get-ADDomain).DomainSID.Value

# Grupos do domínio: Domain Admins, Schema Admins, Enterprise Admins
"512","518","519" | ForEach-Object {
    $group = Get-ADGroup -Identity "$dom-$_" -Properties Members -ErrorAction SilentlyContinue
    if ($group) { "$($group.Name): $(@($group.Members).Count)" }
}

# Grupos BUILTIN: Administrators, Account/Server/Print/Backup Operators
"544","548","549","550","551" | ForEach-Object {
    $group = Get-ADGroup -Identity "S-1-5-32-$_" -Properties Members -ErrorAction SilentlyContinue
    if ($group) { "$($group.Name): $(@($group.Members).Count)" }
}

A saída vem como uma linha por grupo, no formato Nome do grupo: quantidade.

O que cada identificador representa:

IdentificadorGrupoO que concede
512Domain AdminsControle total do domínio
518Schema AdminsModificar o schema da floresta
519Enterprise AdminsControle sobre toda a floresta
S-1-5-32-544AdministratorsAdministrador local dos DCs
S-1-5-32-548Account OperatorsCriar, editar e deletar contas e grupos
S-1-5-32-549Server OperatorsParar serviços e fazer backup em DCs
S-1-5-32-550Print OperatorsCarregar drivers em DC
S-1-5-32-551Backup OperatorsLer qualquer arquivo do DC, incluindo o ntds.dit

Some os membros. Descontando as sobreposições, esse é o seu número real.


O que fazer com o resultado

Não saia removendo ninguém. Você pode desligar acesso de alguém que sustenta um processo que ninguém documentou, e descobrir isso da pior forma possível.

Para cada membro de cada grupo, três perguntas:

Essa conta ainda pertence a alguém que trabalha aqui? É a pergunta mais fácil e a que mais rende. Conta de quem saiu, permanecendo em grupo privilegiado, é o achado mais comum de qualquer auditoria.

É pessoa ou é conta de serviço? Conta de serviço em grupo administrativo é um problema diferente: ela tem senha que não expira, ninguém troca, e frequentemente está gravada em texto puro em algum script ou tarefa agendada.

Precisa desse nível, ou precisa de uma delegação específica? Quase sempre a resposta é a segunda. A pessoa precisa resetar senha de um departamento, e recebeu poder sobre o domínio inteiro porque delegar direito dá trabalho.

Os grupos que deveriam estar vazios são o ponto de partida. Schema Admins e Enterprise Admins não precisam de membro permanente. Se alguém precisa entrar para fazer uma mudança, entra, faz, e sai.

Isso se chama acesso just-in-time, e não exige ferramenta nenhuma para começar. Exige disciplina.


Faça essa soma no seu ambiente. Some os membros de todos os grupos da tabela.

Se o número te surpreendeu, ele surpreenderia seu auditor também.