Censimento dei figli diretti OU AD: verificare prima di ristrutturare

Cosa stabilisce un censimento dei figli diretti OU AD

Un censimento dei figli diretti OU AD registra quali oggetti si trovano immediatamente sotto una determinata unità organizzativa. Prima di ristrutturarla, usatelo per rispondere a una domanda circoscritta: cosa contiene questa OU a questo livello, nella vista della directory che abbiamo effettivamente letto? Conservate un inventario separato della gerarchia sottostante. Il conteggio dei figli diretti è utile per pianificare, ma un contatore apparentemente vuoto non deve mai diventare una decisione automatica di rimozione.

Questa guida è stata revisionata il 4 ottobre 2026 sulla base di Microsoft Learn e della revisione del collector identificata più avanti. Fornisce una procedura di riconciliazione per gli amministratori che esaminano un inventario di OU. I comandi PowerShell sono esempi documentali per il lettore, adattati dalla sintassi documentata dei parametri; non sono stati eseguiti su un dominio AD per questo articolo. Non si afferma che sia stata completata una raccolta con successo, che una OU di produzione sia vuota o che una modifica sia stata completata.

Il problema pratico è la discordanza tra l’etichetta di un contatore e la sua popolazione. Un rapporto può mostrare Users, Computers, Groups e OUs mentre il revisore presume che descriva tutti gli oggetti sotto la OU. Può inoltre omettere oggetti a causa di limiti di raccolta, esclusioni o un confronto del DN del padre. Conservate questi confini prima di utilizzare il rapporto in una richiesta di modifica.

Funzionamento: separare i conteggi su un livello dalla gerarchia

La documentazione di Get-ADObject di Microsoft distingue OneLevel, che cerca i figli immediati, da Subtree, che include la base e i discendenti. SearchBase imposta il percorso di destinazione e Server seleziona l’istanza della directory. Specificate entrambi quando producete evidenze.

Create due registrazioni per la stessa destinazione: un inventario dei figli diretti per la popolazione locale e un inventario del sottoalbero per le dipendenze più profonde nella gerarchia. Indicate esplicitamente i rispettivi ambiti. Non confrontate la somma dei contatori di classe dei figli diretti con un totale del sottoalbero senza precisarne l’ambito. Una OU che contiene un’altra OU può avere poche identità dirette, mentre la gerarchia subordinata contiene gli oggetti rilevanti per la modifica.

Per ogni inventario, conservate gli identificatori degli oggetti, i DN originali, la classe, il contesto di raccolta e lo stato di completamento. Tenete l’elenco grezzo degli oggetti accanto a ogni conteggio riepilogativo, così da poter indagare una discrepanza senza dover indovinare quali oggetti vi abbiano contribuito. Un elenco di oggetti consente anche di distinguere una classe inattesa da una relazione con il padre inattesa.

Stabilire il significato delle etichette di classe

Trattate Users, Computers, Groups e OUs come quattro popolazioni del collector, non come una garanzia che sia stata letta ogni classe della directory. Definite le query indipendenti prima di confrontarle. Registrate separatamente le altre classi restituite; non includetele tacitamente in Users e non ignoratele perché la dashboard non dispone di un contatore corrispondente.

La popolazione di utenti LDAP esaminata include nel filtro predefinito un ramo per gli account di servizio gestiti di gruppo. Di conseguenza, la query di utenti della categoria person riportata di seguito e il gruppo Users del collector possono differire anche quando entrambe le letture si completano. Confrontate le definizioni effettive dei filtri e gli identificatori degli oggetti restituiti. Mantenete visibili le sottoclassi degli account di servizio e le altre classi senza corrispondenza nel registro di riconciliazione, invece di forzare una coincidenza numerica.

La nostra guida ai contenitori predefiniti e all’ambito dei Criteri di gruppo spiega perché le destinazioni predefinite e l’ambito previsto dei criteri richiedono una verifica separata del posizionamento. Il suo esempio OneLevel inventaria i computer nel contenitore Computers predefinito. Non fornisce un censimento delle quattro popolazioni di una OU, non tiene conto di ogni classe e non risolve il problema dei DN con caratteri di escape affrontato qui.

Rilevamento: leggere gli oggetti prima di confrontare i contatori

1. Stabilire il contesto delle query

Selezionate la OU approvata e un server di directory esplicito. Registrate il contesto di lettura dell’operatore, gli orari di inizio e completamento, la base di ricerca, l’ambito, il filtro di classe e gli eventuali errori. Usate un host di amministrazione autorizzato con il modulo AD PowerShell. Il DN della OU riportato di seguito compare nell’esempio 5 della documentazione di Get-ADObject; il nome del server è un FQDN fittizio usato come segnaposto. Sostituite entrambi con la destinazione esaminata.

Gli esempi seguenti adattano i parametri documentati Filter, LDAPFilter, SearchBase, SearchScope, Server e Properties di Get-ADObject. Richiedono identificatori per la riconciliazione. Salvate gli oggetti restituiti e l’esito dell’operazione attraverso il vostro flusso di amministrazione prima di calcolare un riepilogo.

Leggete innanzitutto la popolazione diretta senza restrizioni di classe:

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

Usate questo elenco per individuare le classi che i quattro contatori non descrivono. L’inventario rimane circoscritto alla vista selezionata e al contesto di lettura. Se fallisce o si interrompe prima del termine, conservate tale esito; gli oggetti già visualizzati non provano che il censimento sia completo.

2. Mantenere separate le query di classe

Questi esempi per il lettore definiscono popolazioni di verifica separate; non riproducono tutti i filtri del collector. Il primo combina objectClass=user con objectCategory=person, come documentato nella guida di Microsoft alla ricerca degli utenti. Un filtro sulla sola classe user trova anche i computer, perché la classe computer deriva da 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

Mantenete identificabili singolarmente i quattro output. Registrate se ogni query si è completata e confrontate il suo insieme di oggetti con l’elenco OneLevel senza restrizioni. Quando compare un’altra classe, aggiungete una popolazione di verifica con un’etichetta separata. Se un gruppo del collector usa un filtro più ampio, documentate la popolazione aggiuntiva prima di riconciliarne il conteggio.

3. Leggere il sottoalbero come evidenza diversa

Usate un’operazione separata per la gerarchia:

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

Etichettate questo output come Subtree e distinguete la OU di base dagli oggetti sottostanti. Esaminate le OU subordinate e il loro contenuto con i rispettivi responsabili. Non aggiungete questo totale ai contatori dei figli diretti e non descrivetelo come una seconda misurazione della stessa popolazione.

4. Riconciliare gli identificatori e i DN con caratteri di escape

Learn documenta objectGUID come identificatore accettato da Get-ADObject. Usatelo come chiave di confronto negli inventari indipendenti e conservate il DN come evidenza della posizione. Quando il payload del collector non contiene un GUID, risolvete il DN registrato nello stesso contesto e conservate il collegamento; non inventate un identificatore e non stabilite corrispondenze basate soltanto sul nome visualizzato.

La documentazione dei nomi distinti di Microsoft spiega che gli RDN sono separati da virgole e che una virgola nel valore di un attributo deve essere sottoposta a escape. Una virgola grezza non basta quindi a determinare dove termina un nome e dove inizia il suo padre.

Per esempio, Learn fornisce questo DN con una virgola sottoposta a escape nell’RDN della OU:

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

Preferite il risultato OneLevel della directory quando stabilite la relazione immediata con il padre. Se un’esportazione deve essere elaborata localmente, usate un parser di DN che gestisca l’escape e conservate la stringa originale. Non suddividete la stringa a ogni virgola e non rimuovete le barre inverse prima di determinare la relazione con il padre.

Riconciliare il censimento prima della ristrutturazione (Remediation)

1. Qualificare ogni osservazione

Usate il registro di riconciliazione per stabilire cosa è accertato e cosa rimane aperto. Una discrepanza è un motivo per indagare l’ambito, i filtri, gli identificatori o la raccolta, anziché modificare gli oggetti finché i conteggi coincidono.

Associate questa classificazione alla OU e alla classe specifiche. Un’etichetta per l’intera riga come «vuota» perde la distinzione tra uno zero di classe verificato e una lettura di classe mancante. Se query diverse si sono completate in momenti differenti, conservate tale differenza invece di presentarle come un’unica istantanea simultanea.

2. Spiegare le differenze prima di cambiare la gerarchia

Confrontate prima i singoli oggetti, poi i totali. Registrate se ogni differenza deriva da un’altra classe, un discendente più profondo, un’esclusione, un filtro, una raccolta incompleta o una corrispondenza con il padre non risolta. Mantenete aperte le differenze non spiegate, con un revisore responsabile e le evidenze necessarie per risolverle.

Usate lo stesso server e lo stesso contesto di destinazione per la prima riconciliazione. Se la verifica include un altro server, etichettatene l’inventario separatamente. Una differenza tra viste richiede un’indagine; questa procedura non consente di ipotizzare un risultato di replica né di trattare un conteggio conveniente come autorevole.

Documentate le esclusioni del collector e gli eventuali limiti di raccolta accanto alle letture indipendenti. Mantenete separato un censimento amministrativo senza restrizioni da un sottoinsieme deliberatamente allineato agli input del collector. Un oggetto escluso rimane rilevante per la ristrutturazione anche se non contribuisce a un contatore filtrato.

3. Conservare la responsabilità e le protezioni dalla cancellazione

Fornite al responsabile il registro a livello di oggetto, la verifica del sottoalbero, le differenze non risolte e l’ambito proposto. Ottenete una decisione sulla destinazione esatta e sulle sue dipendenze. Un nome di OU, un conteggio ridotto o un campo vuoto della dashboard non identifica chi possa approvare uno spostamento o una pulizia.

Seguite la guida complementare alla verifica indipendente dei permessi e alla decisione del responsabile prima della pulizia di una OU. Questa guida affronta le protezioni dalla cancellazione e le eccezioni circoscritte. Mantenete tale verifica nel processo di modifica; questo censimento non valuta i permessi pertinenti e non autorizza la rimozione della protezione.

Prima di approvare la ristrutturazione, identificate le conseguenze previste sui criteri e sull’amministrazione degli oggetti coinvolti. Mantenete il posizionamento nei contenitori predefiniti e l’ambito delle GPO nella verifica del posizionamento, e le protezioni dalla cancellazione nella verifica complementare dei permessi. Il censimento fornisce la popolazione di oggetti da cui dipendono queste decisioni.

4. Verificare l’esito approvato

Dopo una modifica autorizzata, ripetete le letture OneLevel e Subtree pertinenti usando il contesto di destinazione registrato. Riconciliate gli oggetti conservati tramite l’identificatore e registratene le posizioni attuali. Conservate la decisione del responsabile e l’esito effettivo dell’operazione accanto alle evidenze precedenti e successive.

Chiudete l’attività di inventario quando le popolazioni concordate e le incertezze residue sono documentate. Chiudete l’attività di modifica secondo i suoi criteri di risultato, compresa la verifica complementare delle protezioni. Un conteggio che sembri più ordinato non basta a dimostrare che siano stati gestiti le dipendenze, l’ambito dei criteri e la protezione degli oggetti conservati.

Come EtcSec rileva questo caso

Questa sezione descrive soltanto INFO_DOMAIN_OU_INVENTORY, esaminato nel commit afca1b9f7bba6f076d6a6493371486071001452b di etc-collector. Il detector pertinente è public/internal/audit/detectors/ad/permissions/organization/ou-inventory.go:31.

Il suo metodo Detect() emette un risultato Info con Count=1 per ogni OU raccolta. Questo conteggio identifica una voce di inventario, non il numero dei figli né un verdetto di vulnerabilità. Non restituisce risultati quando l’input delle OU è vuoto. I dettagli delle entità interessate sono popolati solo quando IncludeDetails è abilitato; l’assenza di dettagli non dimostra l’assenza di figli.

Il metodo GetOUs del provider LDAP, in public/internal/providers/ldap/client.go:946, legge le unità organizzative tramite la sua funzione ausiliaria di ricerca nel sottoalbero. Una raccolta delle OU nel sottoalbero non trasforma i contatori dei figli emessi in conteggi dei discendenti e non dimostra una completezza universale.

In public/internal/audit/gpo_policy.go:365–436, OUEntity costruisce ChildCounts a partire dagli array Users, Computers, Groups e OUs forniti. La funzione ausiliaria conta solo i figli immediati. Le esclusioni di asset applicate prima del rilevamento influenzano queste popolazioni; le altre classi della directory non costituiscono un quinto contatore di tutti gli oggetti. Il conteggio deve essere interpretato in base a ciò che è stato effettivamente raccolto.

Il test del padre verifica un suffisso di OU senza distinguere maiuscole e minuscole, poi rifiuta una parte iniziale contenente una qualsiasi virgola. Inferenza statica: una virgola sottoposta a escape nell’RDN iniziale può causare l’omissione di un autentico figlio diretto. Questo deriva dal predicato di stringa esaminato e dalle regole documentate di escape dei DN; non è stato dimostrato qui eseguendo un test su un dominio.

Infine, OUEntity inizializza Delegations come array vuoto segnaposto, perché il collegamento delle deleghe DACL delle OU non è popolato su questo percorso. Non fornisce alcuna evidenza che i diritti delegati siano assenti. Usate l’inventario per selezionare e riconciliare le OU; stabilite i contenuti, i permessi e l’esito approvato della ristrutturazione attraverso le evidenze separate descritte sopra.