Censo de filhos diretos de OU AD: verificar contagens

O que estabelece um censo de filhos diretos de OU AD

Um censo de filhos diretos de OU AD regista os objetos que se encontram imediatamente abaixo de uma determinada unidade organizacional. Antes de reestruturar, utilize-o para responder a uma pergunta delimitada: o que contém esta OU neste nível, na vista do diretório que efetivamente lemos? Mantenha um inventário separado da hierarquia abaixo dela. A contagem de filhos diretos é útil para planear, mas um contador aparentemente vazio nunca deve transformar-se numa decisão automática de remoção.

Este guia foi revisto em 4 de outubro de 2026 com base no Microsoft Learn e na revisão do coletor identificada abaixo. Apresenta um procedimento de reconciliação para administradores que analisam um inventário de OUs. Os comandos PowerShell são exemplos documentais para o leitor, adaptados da sintaxe de parâmetros documentada; não foram executados num domínio AD para este artigo. Não se afirma que tenha havido uma recolha bem-sucedida, uma OU de produção vazia ou uma alteração concluída.

O problema prático é a divergência entre o rótulo de um contador e a sua população. Um relatório pode mostrar Users, Computers, Groups e OUs, enquanto o revisor pressupõe que descreve todos os objetos abaixo da OU. Também pode omitir objetos devido a limites de recolha, exclusões ou à comparação do DN do objeto pai. Preserve esses limites antes de utilizar o relatório num pedido de alteração.

Como funciona: separar contagens de um nível da hierarquia

A referência de Get-ADObject da Microsoft distingue OneLevel, que pesquisa filhos imediatos, de Subtree, que inclui a base e os descendentes. SearchBase define o caminho de destino e Server seleciona a instância do diretório. Especifique ambos ao produzir evidências.

Crie dois registos para o mesmo destino: um inventário de filhos diretos para a população local e um inventário da subárvore para dependências mais profundas na hierarquia. Identifique explicitamente os respetivos âmbitos. Não compare a soma dos contadores de classes de filhos diretos com um total da subárvore sem qualificação. Uma OU que contém outra OU pode ter poucas identidades diretas, enquanto a hierarquia subordinada contém os objetos relevantes para a alteração.

Para cada inventário, preserve identificadores dos objetos, DNs originais, classe, contexto de recolha e estado de conclusão. Guarde a lista bruta de objetos junto de qualquer contagem resumida, para investigar uma divergência sem adivinhar quais os objetos que contribuíram. Uma lista de objetos também permite distinguir uma classe inesperada de uma relação inesperada com o objeto pai.

Decidir o significado dos rótulos de classe

Trate Users, Computers, Groups e OUs como quatro populações do coletor, e não como uma garantia de que todas as classes do diretório foram lidas. Defina as consultas independentes antes de as comparar. Registe separadamente outras classes devolvidas; não as inclua silenciosamente em Users nem as ignore porque o painel não tem um contador correspondente.

A população de utilizadores LDAP revista inclui um ramo para contas de serviço geridas por grupo no filtro predefinido. Por isso, a consulta de utilizadores do tipo pessoa abaixo e a categoria Users do coletor podem divergir mesmo quando ambas as leituras são concluídas. Compare as definições reais dos filtros e os identificadores dos objetos devolvidos. Mantenha as subclasses de contas de serviço e quaisquer outras classes sem correspondência visíveis no registo de reconciliação, em vez de forçar uma igualdade numérica.

O nosso guia sobre contentores predefinidos e âmbito da Política de Grupo explica por que motivo os destinos predefinidos e o âmbito pretendido das políticas exigem uma análise separada da localização. O seu exemplo OneLevel inventaria computadores no contentor Computers predefinido. Não fornece um censo das quatro populações numa OU, não abrange todas as classes nem resolve o problema dos DNs com caracteres de escape aqui tratado.

Deteção: ler os objetos antes de comparar contadores

1. Estabelecer o contexto da consulta

Selecione a OU aprovada e um servidor de diretório explícito. Registe o contexto de leitura do operador, as horas de início e conclusão, a base e o âmbito da pesquisa, o filtro de classe e quaisquer erros. Utilize um anfitrião de administração autorizado com o módulo PowerShell do AD. O DN da OU abaixo aparece no exemplo 5 da referência de Get-ADObject; o nome do servidor é um FQDN fictício usado como marcador. Substitua ambos pelo destino revisto.

Os exemplos seguintes adaptam os parâmetros documentados Filter, LDAPFilter, SearchBase, SearchScope, Server e Properties de Get-ADObject. Solicitam identificadores para reconciliação. Guarde os objetos devolvidos e o resultado da operação através do seu processo de administração antes de calcular um resumo.

Primeiro, leia a população direta sem restrição de classe:

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Utilize esta lista para descobrir classes que os quatro contadores não descrevem. O inventário continua limitado à vista e ao contexto de leitura selecionados. Se falhar ou terminar prematuramente, preserve esse resultado; os objetos já apresentados não provam que o censo esteja completo.

2. Manter as consultas de classes separadas

Estes exemplos para o leitor definem populações de análise separadas; não reproduzem todos os filtros do coletor. O primeiro combina objectClass=user com objectCategory=person, conforme documentado nas orientações da Microsoft para consultar utilizadores. Um filtro apenas pela classe user também encontra computadores, porque a classe computer deriva de user:

Get-ADObject -LDAPFilter '(&(objectClass=user)(objectCategory=person))' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "computer"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "group"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "organizationalUnit"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Mantenha as quatro saídas identificáveis individualmente. Registe se cada consulta foi concluída e compare o respetivo conjunto de objetos com a lista OneLevel sem restrições. Quando aparecer outra classe, acrescente uma população de análise com rótulo separado. Quando uma categoria do coletor utilizar um filtro mais amplo, documente a população adicional antes de reconciliar a contagem.

3. Ler a subárvore como evidência diferente

Utilize uma operação separada para a hierarquia:

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope Subtree -Server 'dc01.fabrikam.com' -Properties objectGUID

Identifique esta saída como Subtree e distinga a OU base dos objetos abaixo dela. Analise as OUs subordinadas e os seus conteúdos com os respetivos responsáveis. Não adicione este total aos contadores de filhos diretos nem o descreva como uma segunda medição da mesma população.

4. Reconciliar identificadores e DNs com caracteres de escape

O Learn documenta objectGUID como um identificador aceite por Get-ADObject. Utilize-o como chave de comparação nos inventários independentes e preserve o DN como evidência da localização. Quando os dados do coletor não tiverem GUID, resolva o DN registado no mesmo contexto e preserve a associação; não invente um identificador nem estabeleça correspondências apenas pelo nome apresentado.

A referência da Microsoft sobre nomes distintos explica que os RDNs são separados por vírgulas e que uma vírgula dentro do valor de um atributo tem de receber um caráter de escape. Por isso, uma vírgula isolada não basta para decidir onde termina um nome e começa o seu objeto pai.

Por exemplo, o Learn apresenta este DN com uma vírgula com caráter de escape no RDN da OU:

CN=Litware,OU=Docs\, Adatum,DC=Fabrikam,DC=COM

Prefira o resultado OneLevel do diretório para estabelecer a relação imediata com o objeto pai. Se uma exportação tiver de ser processada localmente, utilize um analisador de DNs que trate os caracteres de escape e preserve a cadeia original. Não divida em todas as vírgulas nem remova barras invertidas antes de determinar a relação com o objeto pai.

Reconciliar o censo antes de reestruturar (Remediation)

1. Qualificar cada observação

Utilize o registo de reconciliação para decidir o que está estabelecido e o que continua em aberto. Uma divergência justifica investigar âmbito, filtros, identificadores ou recolha, em vez de alterar objetos até as contagens coincidirem.

Observação	Interpretação da evidência	Próxima ação
Uma consulta de classe concluída não devolve objetos diretos	Zero para esse contexto de consulta indicado	Preservar a saída e analisar outras classes e a subárvore
Alguns objetos são devolvidos antes de uma leitura falhar ou ser interrompida	Resultado parcial	Resolver o problema de recolha e repetir a leitura com âmbito definido
Uma classe devolvida não tem contador no coletor	Não é representada por esse contador	Manter uma população separada e identificar as suas dependências
Um objeto é excluído da entrada do coletor	Fora da população medida pelo coletor	Registar a exclusão e comparar um subconjunto explicitamente alinhado
OneLevel contém um objeto com RDN com caráter de escape ausente de um contador	Divergência na correspondência do objeto pai que exige análise	Preservar o DN e o identificador e examinar o predicado revisto
Delegations está vazio nos dados do inventário da OU	A evidência de delegação não foi preenchida neste percurso	Organizar uma análise independente das permissões

Associe esta classificação à OU e à classe específicas. Um rótulo para toda a linha, como «vazia», perde a distinção entre um zero verificado para uma classe e a ausência de leitura de uma classe. Se consultas diferentes terminaram em momentos diferentes, preserve essa diferença em vez de as apresentar como uma única fotografia simultânea.

2. Explicar diferenças antes de alterar a hierarquia

Compare primeiro os objetos individuais e depois os totais. Registe se cada diferença resulta de outra classe, de um descendente mais profundo, de uma exclusão, de um filtro, de recolha incompleta ou de uma correspondência não resolvida do objeto pai. Mantenha as diferenças sem explicação em aberto, com um revisor responsável e a evidência necessária para as resolver.

Utilize o mesmo servidor e contexto de destino na primeira reconciliação. Se a análise incluir outro servidor, identifique o seu inventário de forma independente. Uma diferença entre vistas exige investigação; este procedimento não fornece base para adivinhar um resultado de replicação ou tratar uma contagem conveniente como autoritativa.

Documente as exclusões do coletor e quaisquer limites de recolha junto das leituras independentes. Mantenha um censo administrativo sem restrições separado de um subconjunto intencionalmente alinhado com as entradas do coletor. Um objeto excluído continua a ser relevante para a reestruturação, embora não contribua para um contador filtrado.

3. Preservar a responsabilidade e as salvaguardas contra eliminação

Entregue ao responsável o registo ao nível dos objetos, a análise da subárvore, as diferenças não resolvidas e o âmbito proposto. Obtenha uma decisão sobre o destino exato e as suas dependências. Um nome de OU, uma contagem pequena ou um campo vazio no painel não identifica quem pode aprovar uma deslocação ou limpeza.

Siga a orientação complementar sobre análise independente das permissões e decisão do responsável antes da limpeza de OUs. Esse guia trata das salvaguardas contra eliminação e das exceções delimitadas. Mantenha essa análise no processo de alteração; este censo não avalia as permissões relevantes nem autoriza a remoção de proteção.

Antes de aprovar a reestruturação, identifique as consequências pretendidas nas políticas e na administração dos objetos afetados. Mantenha a localização em contentores predefinidos e o âmbito das GPOs na análise de localização, e as salvaguardas contra eliminação na análise complementar das permissões. O censo fornece a população de objetos da qual dependem essas decisões.

4. Verificar o resultado aprovado

Após uma alteração autorizada, repita as leituras OneLevel e Subtree relevantes utilizando o contexto de destino registado. Reconcilie os objetos restantes por identificador e registe as suas localizações atuais. Preserve a decisão do responsável e o resultado real da operação junto das evidências anteriores e posteriores.

Conclua a tarefa de inventário quando as populações acordadas e as incertezas restantes estiverem documentadas. Conclua a tarefa de alteração de acordo com os seus próprios critérios de resultado, incluindo a análise complementar das salvaguardas. Uma contagem que pareça mais limpa não basta para estabelecer que as dependências, o âmbito das políticas e a proteção dos objetos preservados foram tratados.

Como o EtcSec deteta esta situação

Esta secção descreve apenas INFO_DOMAIN_OU_INVENTORY, revisto no commit afca1b9f7bba6f076d6a6493371486071001452b do etc-collector. O detetor relevante é public/internal/audit/detectors/ad/permissions/organization/ou-inventory.go:31.

O seu Detect() emite uma ocorrência de nível Info com Count=1 para cada OU recolhida. Essa contagem identifica uma entrada de inventário, e não o número de filhos ou um veredito de vulnerabilidade. Não devolve ocorrências quando a entrada de OUs está vazia. Os detalhes das entidades afetadas só são preenchidos quando IncludeDetails está ativado; a ausência de detalhes não estabelece a ausência de filhos.

O GetOUs do fornecedor LDAP, em public/internal/providers/ldap/client.go:946, lê unidades organizacionais através da sua função auxiliar de pesquisa da subárvore. Uma recolha de OUs na subárvore não transforma os contadores de filhos emitidos em contagens de descendentes nem prova completude universal.

Em public/internal/audit/gpo_policy.go:365–436, OUEntity constrói ChildCounts a partir dos arrays Users, Computers, Groups e OUs fornecidos. A função auxiliar conta apenas filhos imediatos. As exclusões de ativos aplicadas antes da deteção afetam essas populações; outras classes do diretório não constituem um quinto contador de todos os objetos. A contagem tem de ser interpretada à luz do que foi efetivamente recolhido.

O teste do objeto pai verifica um sufixo de OU sem distinguir maiúsculas de minúsculas e rejeita depois uma parte inicial que contenha qualquer vírgula. Inferência estática: uma vírgula com caráter de escape no RDN inicial pode fazer com que um verdadeiro filho direto seja omitido. Isto decorre do predicado de cadeias revisto e do tratamento documentado dos caracteres de escape em DNs; não foi demonstrado aqui pela execução de um teste num domínio.

Por fim, OUEntity inicializa Delegations como um array vazio usado como marcador, porque a ligação da delegação da DACL da OU não é preenchida neste percurso. Não fornece evidência de que os direitos delegados estejam ausentes. Utilize o inventário para selecionar e reconciliar OUs; estabeleça os conteúdos, as permissões e o resultado aprovado da reestruturação através das evidências separadas descritas acima.