Limpar adminCount obsoleto: Fluxo seguro no Active Directory

Limpar adminCount obsoleto: O que está a corrigir no Active Directory

O objetivo operacional ao limpar adminCount obsoleto no Active Directory é remover uma marca administrativa residual e restaurar a herança de permissões prevista nas contas que realmente deixaram os grupos protegidos. Trata-se de manutenção de rotina após mudanças de função e saídas de colaboradores. O nosso guia de backdoors de AdminSDHolder e SDProp aborda outro cenário: uma ACE não autorizada no modelo pode propagar-se para objetos protegidos. Aqui, a decisão começa pelas associações atuais a grupos e pela ACL da conta, sem presumir a participação de um atacante.

Verificar o aninhamento, limpar a marca e ativar a herança são apenas parte deste fluxo de trabalho. Um registo de manutenção segura deve identificar grupos protegidos pelo SID, resolver separadamente o grupo primário, rever a OU superior, aprovar cada conta individualmente e verificar o resultado após um ciclo posterior do SDProp. Um inventário menor de adminCount=1 é útil, mas não demonstra que as permissões efetivas estão corretas.

Como funciona o SDProp e por que a marca persiste

O AdminSDHolder fornece as permissões do modelo para objetos protegidos. O SDProp compara as permissões desses objetos com o modelo no PDC Emulator (PDCE) de cada domínio, por predefinição a cada 60 minutos, e repõe as diferenças. Os objetos protegidos têm a herança desativada; movê-los para outra OU não remove a proteção. A Microsoft documenta este comportamento no Apêndice C: Contas e grupos protegidos. A especificação do protocolo AdminSDHolder explica a proteção periódica dos descritores de segurança.

A referência do esquema Admin-Count da Microsoft descreve o atributo como um registo de uma ACL reforçada após associação administrativa direta ou transitiva. Não é um inventário completo dos privilégios atuais. O artigo histórico da Microsoft sobre AdminSDHolder e SDProp explica que, após remover a associação protegida, adminCount=1 e a herança desativada permanecem. O antigo membro deixa de receber a ACL do modelo, mas continua sem herdar permissões do objeto superior.

Use a lista atual do Apêndice C, em vez da lista mais antiga do artigo histórico:

Administrator e Krbtgt são contas, não grupos de associação. Registe qualquer configuração aplicável do domínio ou exceção da floresta; não altere dSHeuristics para simplificar a limpeza. O grupo Protected Users é um controlo de autenticação separado; o próprio grupo não é protegido pelo AdminSDHolder.

Armadilha 1: A remoção direta deixa um caminho aninhado

O artigo histórico da Microsoft descreve a proteção transitiva, incluindo caminhos através de grupos de distribuição. Um utilizador removido de Domain Admins pode continuar a alcançar um grupo protegido através de outro grupo. Se esse caminho permanecer, limpar um atributo não remove a proteção, e o SDProp pode reverter a ativação da herança. Não prometa que apenas limpar a marca necessariamente a fará ser gravada de novo no ciclo seguinte a uma hora precisa; a conclusão sustentada é que a associação restante continua a tornar o objeto protegido.

Armadilha 2: A marca desaparece, mas a ACL continua incorreta

Para um antigo membro confirmado, limpar adminCount deixa a herança inalterada. Assim, a delegação na OU superior pode continuar sem chegar à conta. Isto não prova que a ACL existente da conta seja mais permissiva: pode, em vez disso, não conter os direitos de gestão previstos. Por outro lado, ativar a herança numa OU com delegação excessiva pode acrescentar permissões indesejadas. As ACEs explícitas também exigem revisão própria; ativar a herança não as remove.

Deteção: Criar um inventário de candidatos

Comece por um inventário apenas de leitura. Get-ADObject documenta -LDAPFilter, -Properties e -Server; esta adaptação solicita a marca e o estado necessários para a investigação:

Get-ADObject -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,objectSid,primaryGroupID,nTSecurityDescriptor -Server "dc-pdce.corp.example"

Os resultados podem incluir grupos e computadores. Classifique-os separadamente, em vez de aplicar o fluxo de contas de utilizador a todos os objetos devolvidos. Para a população de utilizadores abrangida pelas duas verificações EtcSec, use os parâmetros documentados de Get-ADUser:

Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,Enabled,SID,primaryGroupID -Server "dc-pdce.corp.example"

Um valor memberOf vazio ou aparentemente comum é uma pista para investigação, não uma prova de que a conta é órfã. A página do esquema MemberOf descreve DNs de grupos; esta propriedade, por si só, não fornece a análise completa da proteção exigida abaixo.

Este fluxo deteta uma condição do estado do diretório através de consultas e revisão de ACL. Não exige um ID de evento inventado nem trata uma remoção histórica de grupo como prova de que é atualmente seguro alterar a conta.

Remediação: Verificar antes de alterar uma conta (Remediation)

Passo 1 — Preservar o estado da conta e do objeto superior

Para cada candidato, registe o DN, SID, estado de ativação, grupos diretos, RID do grupo primário, responsável funcional, ACL completa e estado da herança. Registe o DC e a hora da recolha. Mantenha disponível um método aprovado de restauração da ACL; guardar a saída de texto é uma evidência útil, mas não equivale a afirmar que existe uma cópia de segurança AD restaurável.

A referência Microsoft de Dsacls documenta a apresentação das entradas de acesso sem as modificar. A saída predefinida omite informações de propriedade e auditoria; /A inclui esses detalhes ao recolher o registo completo de segurança. Execute cada leitura separadamente:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

dsacls "\\dc-pdce.corp.example\OU=Staff,DC=corp,DC=example"

Reveja o objeto superior antes de permitir a herança. Identifique quais os direitos herdados que devem aparecer e quais as ACEs explícitas da conta que precisam de permanecer ou de ser revistas separadamente. Uma ACL suspeita encaminha a conta para investigação, em vez de limpeza automática.

Passo 2 — Resolver grupos protegidos pelo SID

Use a referência de SIDs da Microsoft para distinguir o identificador do domínio do RID. Resolva todos os grupos protegidos no domínio relevante; os grupos da floresta exigem a cobertura adequada do domínio raiz da floresta. Nomes de grupos renomeados ou localizados não constituem uma verificação suficiente da identidade.

Get-ADGroup aceita um SID em -Identity. O SID específico do domínio abaixo é um marcador ilustrativo, não um grupo descoberto. O SID do grupo incorporado Administrators também é apresentado, com um servidor explícito para estabelecer o contexto do domínio:

Get-ADGroup -Identity "S-1-5-21-111111111-222222222-333333333-512" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Get-ADGroup -Identity "S-1-5-32-544" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Documente o SID e o DN resolvidos para cada entrada da lista protegida. Uma falha na consulta deixa uma lacuna de cobertura. Não equivale a confirmar que o grupo não contém nenhum membro relevante.

Passo 3 — Verificar a associação recursiva e o grupo primário

A documentação de Get-ADGroupMember inclui um exemplo de associação recursiva. Adapte-o a cada SID verificado de grupo protegido e compare os SIDs de utilizadores devolvidos com o candidato:

Get-ADGroupMember -Identity "S-1-5-21-111111111-222222222-333333333-512" -Recursive -Server "dc-pdce.corp.example"

Repita o processo para a lista completa de grupos protegidos e os domínios relevantes. Inclua caminhos através de grupos de distribuição. -Recursive devolve membros da hierarquia que não têm objetos subordinados; não é uma lista completa das ligações entre grupos intermédios. A Microsoft também documenta uma limitação relativa a outra floresta quando essa floresta não dispõe de Active Directory Web Service. Uma enumeração falhada ou incompleta deve deixar o veredito indeterminado.

Verifique separadamente o grupo primário. A referência Primary-Group-ID da Microsoft define o valor como o RID do grupo primário do utilizador. A referência do protocolo primaryGroupID confirma que tanto memberOf do utilizador como o atributo member do grupo primário omitem esta associação. O coletor revisto constrói o SID do grupo primário a partir do SID do domínio e desse RID. Resolva o SID completo com Get-ADGroup; não deduza a resposta a partir de um nome de grupo legível.

Determine então se o grupo primário é diretamente protegido ou alcança um grupo protegido através de aninhamento. Esta adaptação documentada de Get-ADGroup lê o conjunto seguinte de grupos superiores:

Get-ADGroup -Identity "CN=PrimaryGroup,OU=Groups,DC=corp,DC=example" -Properties memberOf -Server "dc-pdce.corp.example"

Continue a rever cada grupo superior, tratando ciclos e cobrindo os domínios envolvidos. O exemplo é uma única leitura, não um programa completo e validado de travessia. A ausência do candidato na saída de membros recursivos não dispensa a verificação do grupo primário. Membros externos não resolvidos, domínios não consultados ou ciclos por resolver impedem a aprovação de uma escrita.

Passo 4 — Registar a decisão antes de escrever

As contas incorporadas Administrator e Krbtgt continuam protegidas independentemente da ausência de uma associação direta que explique essa proteção. O coletor revisto identifica-as pelos RIDs 500 e 502, mesmo após renomeação. Uma conta desativada que continua protegida pertence à primeira linha, não à linha das órfãs. Para uma conta órfã desativada confirmada, decida entre manutenção e retirada de serviço de acordo com a política de retenção; este fluxo não a reativa automaticamente.

Passo 5 — Limpar apenas o atributo residual confirmado

Set-ADObject documenta -Clear com o nome de apresentação LDAP, além de -WhatIf e -Confirm. Primeiro, pré-visualize a alteração individual:

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -WhatIf

Só depois da decisão e da revisão, execute a escrita confirmada em separado:

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -Confirm

-Clear remove o valor; não escreve o número zero. O comando não remove associações a grupos, não modifica ACEs explícitas nem ativa a herança. Uma pré-visualização bem-sucedida também nada diz sobre se o candidato é realmente órfão.

Passo 6 — Ativar a herança e rever a ACL resultante

A referência Dsacls define /P:N como permitir que o objeto herde permissões do objeto superior. Aplique-o apenas ao objeto aprovado, depois de rever o objeto superior:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example" /P:N

Verifique o resultado da execução e repita imediatamente a leitura da ACL do passo 1. Compare os direitos herdados com a base aprovada do objeto superior e reveja independentemente as entradas explícitas. /P:N altera a proteção de herança do objeto; não altera a capacidade de uma ACE ser herdada. Não o substitua por /S ou /S /T: /S restaura a segurança predefinida pelo esquema do objeto, e /T alarga essa restauração à árvore apenas quando usado com /S.

Validação após o próximo ciclo do SDProp

Volte a ler a conta no servidor registado, usando os parâmetros de Get-ADUser documentados acima:

Get-ADUser -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Properties adminCount,memberOf,primaryGroupID,Enabled -Server "dc-pdce.corp.example"

Leia a ACL separadamente:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

Repita também a resolução das associações: estas podem mudar entre o inventário e a manutenção. Aguarde uma passagem posterior do SDProp segundo o intervalo realmente configurado e tenha em conta a replicação antes de comparar DCs. Registe a hora da verificação e os servidores, a ausência da marca residual, a herança esperada, a revisão de ACEs explícitas e um teste real da delegação prevista. Afirme «validado após o ciclo» apenas quando essa observação existir.

Se a proteção regressar, investigue um caminho de grupo restante, uma adição recente ou uma recolha incompleta. Limpar repetidamente o atributo não é uma solução. O Apêndice C da Microsoft fornece um método opcional de laboratório com Ldp.exe no PDCE e rootDSE RunProtectAdminGroupsTask=1. Prefira o ciclo normal para este fluxo de manutenção em produção e mantenha a sua frequência inalterada. A operação FixUpInheritance do artigo histórico não deve ser automaticamente usada em substituição dessa tarefa.

O nosso guia sobre desvio de acesso privilegiado explica por que as exceções de grupos e ACLs precisam de responsáveis e de revalidação face aos direitos efetivos. Aplique aqui esse princípio: uma limpeza bem-sucedida da marca é um resultado de manutenção, enquanto provar que as permissões da conta correspondem à função prevista exige uma revisão mais ampla dos direitos.

Como o EtcSec deteta esta condição

As duas verificações revistas do etc-collector partilham o mesmo predicado de conta órfã baseado em associação direta ou primária, aplicado a populações de contas diferentes:

Os blocos de seleção normalizados diferem apenas em if u.Disabled versus if !u.Disabled; os títulos, a gravidade e as recomendações também diferem. São dois ramos da mesma verificação, consoante o estado da conta, não mecanismos independentes a somar como evidência de risco maior.

As associações aninhadas não são resolvidas. Nenhuma das verificações expande um grupo aninhado num grupo protegido, incluindo um grupo primário que esteja ele próprio aninhado. Essas contas podem continuar protegidas e gerar um falso candidato órfão. A função auxiliar resolve DNs de grupos protegidos a partir dos sufixos de SID no índice recolhido e compara depois os DNs diretos; dados de grupo ou SID em falta também podem deixar um candidato sem explicação.

Nenhum dos métodos Detect() lê a ACL ou o estado da herança da conta. Por isso, um resultado não demonstra direitos residuais perigosos, não prova a ausência de proteção SDProp nem autoriza a limpeza do atributo. Confirme-o com o fluxo de associação e ACL antes de fazer alterações. Após a manutenção e a validação do diretório, execute novamente a auditoria para comparar os resultados dos candidatos com o resultado registado.