Protezione dalla cancellazione accidentale: verificare le OU AD

Cosa fa la protezione dalla cancellazione accidentale delle OU AD

La protezione dalla cancellazione accidentale delle OU AD è una salvaguardia da esaminare prima della pulizia della directory. Un'unità organizzativa può contenere identità e far parte di una gerarchia amministrativa da cui dipendono altri team. Prima di rimuovere o riorganizzare questa gerarchia, stabilite quali OU devono rimanere, chi è responsabile della decisione e se le autorizzazioni effettivamente presenti nella directory offrono la protezione prevista.

La documentazione di Set-ADOrganizationalUnit di Microsoft descrive ProtectedFromAccidentalDeletion come una proprietà booleana: quando è true, l'oggetto non può essere eliminato senza modificare la proprietà. È una salvaguardia basata sulle autorizzazioni, più che un blocco immutabile. Gli amministratori che possono rimuovere la protezione necessitano comunque di una decisione operativa sottoposta a revisione.

Questa guida pratica è stata riesaminata il 4 ottobre 2026 sulla base di Microsoft Learn e del codice sorgente del collector identificato di seguito. Tutti i comandi sono esempi documentali per il lettore, non operazioni eseguite sul dominio di un cliente. Qui non si afferma di aver eseguito alcuna cancellazione, ripristino o verifica riuscita della protezione.

Come funziona: autorizzazioni, valori alla creazione e recupero

La protezione è rappresentata da autorizzazioni Deny

La protezione utilizza due autorizzazioni Deny per Everyone, identificato dal SID S-1-1-0: Delete e Delete Subtree. Le indicazioni per prevenire cancellazioni accidentali di Microsoft descrivono ACE Deny per DELETE e DELETE TREE sull'oggetto. Descrivono anche una negazione complementare di DELETE CHILD sull'oggetto padre. Esaminate l'oggetto e il relativo padre quando il comportamento delle autorizzazioni non è chiaro; non equiparate una singola ACE corrispondente a una valutazione completa delle autorizzazioni effettive.

In Active Directory Users and Computers, abilitate Advanced Features per visualizzare la scheda Object e la relativa casella di protezione. Per esaminare le autorizzazioni, controllate le voci avanzate della scheda Security, il relativo destinatario, i diritti negati e l'ambito. Le indicazioni di prevenzione citate sopra documentano la casella e il modello di autorizzazioni sottostante. Conservate un registro delle voci pertinenti anziché basarvi soltanto su uno screenshot di una casella selezionata.

La distinzione conta quando si confrontano gli strumenti. Una proprietà estesa presenta una vista amministrativa della protezione, mentre un detector può riconoscere solo un sottoinsieme delle rappresentazioni delle autorizzazioni. Una revisione delle ACL deve considerare anche il padre e l'ambito di ogni voce. Se queste osservazioni discordano, conservate la discrepanza e indagatela prima di modificare le autorizzazioni.

La protezione predefinita alla creazione non verifica le OU esistenti

L'esempio 1 di New-ADOrganizationalUnit crea una OU protetta senza impostare esplicitamente il parametro di protezione. L'esempio 2 crea esplicitamente una OU non protetta con $False. Pertanto, un valore predefinito attuale alla creazione non stabilisce lo stato delle OU più vecchie, migrate o modificate in seguito. La loro protezione può differire e deve essere letta.

La nostra guida ai contenitori predefiniti e al reindirizzamento utilizza questa protezione implicita quando crea OU di destinazione per redircmp e redirusr. Tratta il posizionamento e l'ambito dei criteri di gruppo. Esaminare le salvaguardie contro la cancellazione di una OU esistente è un'attività separata; l'esempio di creazione non fornisce un inventario né un'approvazione per la pulizia.

Prevenzione e recupero rispondono a domande diverse

La protezione mira a prevenire un'operazione accidentale. I backup e il recupero degli oggetti riguardano ciò che accade dopo la perdita dei dati. Le indicazioni su Recycle Bin di Microsoft spiegano che solo gli oggetti eliminati dopo l'abilitazione possono essere recuperati tramite questa funzionalità. Verificate separatamente lo stato effettivo della funzionalità e la preparazione al recupero.

La nostra guida al ripristino della foresta Active Directory e alla validazione dei backup spiega la selezione dei backup, le prove di ripristino e i limiti di Recycle Bin. Utilizzatela per la revisione complementare del recupero. Né una OU protetta né la disponibilità di Recycle Bin dimostrano che un ripristino della foresta sia stato validato. Analogamente, la preparazione al recupero non giustifica lasciare una OU di produzione senza protezione in assenza di un'eccezione accettata.

Rilevamento: inventariare in modo indipendente e leggere la DACL

1. Stabilire una raccolta riuscita e delimitata

Utilizzate un host di amministrazione autorizzato con il modulo PowerShell Active Directory. Registrate il dominio, il server interrogato, l'ora della raccolta, il contesto delle credenziali e l'ambito della ricerca. Una lettura fallita o parziale deve comparire nelle prove come un problema di raccolta irrisolto. Non classificate un oggetto illeggibile come non protetto e non interpretate un risultato vuoto come un inventario completato.

Il seguente esempio per il lettore adatta i parametri documentati Filter e Properties di Get-ADOrganizationalUnit. Richiede esplicitamente la proprietà estesa:

Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion

Scegliete il dominio e il server previsti anziché accettare silenziosamente i valori predefiniti di un host di amministrazione. Learn documenta anche Server, SearchBase e SearchScope per definire questo contesto. Il comando sopra è un punto di partenza per l'inventario, non una garanzia di completezza per tutta la foresta né un'istruzione per modificare ogni risultato.

Per ogni OU letta correttamente, conservate il nome distinto e il GUID dell'oggetto insieme al valore della proprietà. Aggiungete il team aziendale o infrastrutturale responsabile, lo scopo previsto e ogni decisione di pulizia proposta. Il team responsabile è un dato di ingresso della revisione; non presumete che un attributo o il nome di una OU dimostri chi può approvarne la cancellazione.

2. Leggere le autorizzazioni indipendentemente dal collector

Per un oggetto specifico, il prossimo esempio richiede sia la proprietà di protezione sia il descrittore di sicurezza mediante lo stesso meccanismo documentato Properties. Il DN Fabrikam è un segnaposto fittizio da sostituire con il destinatario della revisione:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Esaminate la DACL del descrittore di sicurezza restituito con uno strumento autorizzato di amministrazione della directory, oppure utilizzate la vista avanzata Security in Active Directory Users and Computers. Confermate Everyone tramite il suo SID anziché dipendere da un nome visualizzato localizzato. Esaminate le negazioni Delete e Delete Subtree, la loro applicazione all'oggetto e le autorizzazioni pertinenti del padre. Conservate le prove delle autorizzazioni in formato grezzo o esportato, quando disponibili.

Questa lettura indipendente deve preservare le voci Deny. Riutilizzare l'elenco di ACL filtrato del collector riproduce esattamente la limitazione in esame. Se l'accesso al descrittore fallisce, registrate l'errore e ottenete l'accesso in lettura appropriato tramite il normale processo di amministrazione. Il valore di una proprietà e una lettura della DACL fallita devono rimanere distinguibili.

3. Riconciliare i riscontri con le prove della directory

Confrontate l'inventario del collector con l'inventario amministrativo letto correttamente. Utilizzate gli identificatori degli oggetti e i DN reali per indagare le discrepanze. Una differenza di grafia o di maiuscole e minuscole deve indurre a una riconciliazione, anziché a concludere che due record descrivano necessariamente oggetti diversi. Conservate i valori originali per spiegare la ricerca del collector sensibile a maiuscole e minuscole.

Un riscontro non fornisce una cronologia dell'attacco né uno storico delle cancellazioni. Non deducete una compromissione, un intento malevolo o un incidente avvenuto da questo segnale di configurazione. Se si è verificata una cancellazione reale, la relativa indagine e il recupero richiedono prove separate.

Correzione: proteggere le OU selezionate e delimitare le eccezioni di pulizia (Remediation)

1. Decidere lo stato previsto con il responsabile

Partite dall'inventario riconciliato. Identificate le OU di produzione da conservare, le gerarchie di preparazione, le eccezioni di migrazione e gli oggetti proposti per la rimozione. Chiedete al team responsabile di confermare le dipendenze e gli oggetti esatti coperti dalla modifica. Una OU apparentemente vuota non costituisce di per sé una richiesta di pulizia approvata.

Registrate le prove attuali della proprietà e della DACL, il responsabile della decisione, l'identificatore del destinatario, lo stato previsto e il metodo di verifica. Esaminate chi può modificare le autorizzazioni pertinenti. La protezione non sostituisce questa revisione amministrativa, un backup utilizzabile o un piano di recupero degli oggetti. Se la raccolta o la responsabilità rimangono incerte, mantenete aperto il punto anziché trasformare l'incertezza in una modifica di massa.

2. Abilitare la protezione su una OU conservata e approvata

Questo esempio per il lettore utilizza i parametri documentati Identity e ProtectedFromAccidentalDeletion di Set-ADOrganizationalUnit, impostando il booleano su true per un destinatario fittizio. È un esempio di modifica mirata, non una raccomandazione di convogliare l'intero inventario in una modifica:

Set-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -ProtectedFromAccidentalDeletion $True

Applicate la modifica soltanto all'oggetto esaminato tramite il flusso di amministrazione autorizzato. Salvate ogni errore e l'esito effettivo dell'operazione. La richiesta di impostare un valore è una prova diversa da un aggiornamento riuscito della directory. Quando una modifica fallisce, indagate l'accesso e il contesto del destinatario prima di riprovare o ampliare le autorizzazioni.

3. Rileggere l'oggetto e le autorizzazioni pertinenti

Dopo una modifica riuscita, recuperate di nuovo il destinatario in modo indipendente:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Confermate la proprietà ed esaminate la DACL utilizzando il contesto di raccolta registrato. Conservate le prove prima e dopo e ogni discrepanza residua. Se un altro server fa parte del piano di verifica, registrate quella lettura separata anziché presumere che tutte le viste della directory siano già identiche. Chiudete la modifica solo in base alle prove di accettazione previste.

Non tentate una cancellazione in produzione per dimostrare che la protezione funziona. Questa guida richiede una rilettura riuscita e una revisione delle autorizzazioni; non prescrive un test distruttivo. Anche un conteggio del collector rimasto invariato è insufficiente per dichiarare questa modifica non riuscita, dato il difetto del provider descritto di seguito.

4. Limitare la rimozione della protezione all'operazione approvata

La documentazione Set di Microsoft include un esempio con $false per rimuovere la protezione. Una modifica di questo tipo rientra solo in una decisione di pulizia o migrazione approvata separatamente. Registrate il destinatario preciso, il motivo, l'operatore e il periodo dell'eccezione. Evitate di rimuovere le salvaguardie da un'intera gerarchia solo per semplificare un'operazione.

Dopo il lavoro approvato, riapplicate la protezione agli oggetti conservati che erano stati temporaneamente esentati e ripetete la revisione della proprietà e della DACL. Se l'oggetto è stato eliminato intenzionalmente, conservate le prove dell'approvazione e dell'operazione; non esiste un oggetto sopravvissuto da proteggere nuovamente. Una pulizia abbandonata o fallita non deve lasciare silenziosamente le OU conservate prive della salvaguardia prevista.

Come EtcSec rileva questo problema

Il controllo etc-collector esaminato è OU_UNPROTECTED, in public/internal/audit/detectors/ad/advanced/other/ou-unprotected.go:24. Il detector e il provider LDAP sono stati letti al commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; lo stesso comportamento pertinente è stato esaminato anche all'HEAD del collector 42bfefbace3189588e76ff291c39e100c6a603a0.

Il detector costruisce un insieme di DN di oggetti protetti a partire dalle voci ACL fornite. Una voce soddisfa i requisiti solo quando il suo tipo corrisponde all'esatto nome di tipo ACCESS_DENIED, il suo destinatario è S-1-1-0 e la sua maschera di accesso contiene DELETE (0x10000). Il confronto del nome di tipo utilizza strings.EqualFold, quindi ignora maiuscole e minuscole in quel confronto; ACCESS_DENIED_OBJECT è un tipo diverso che non soddisfa i requisiti.

Cerca quindi ogni ou.DN inventariato in quell'insieme utilizzando la chiave stringa ObjectDN. Questa corrispondenza dei DN distingue maiuscole e minuscole. Le OU senza corrispondenza contribuiscono al Count di un unico riscontro Low. Il riscontro viene restituito anche con conteggio zero; le entità OU interessate vengono aggiunte solo quando sono richiesti i dettagli e il conteggio è positivo.

Nonostante il commento più ampio su Delete e Delete Subtree, il predicato non verifica DELETE_TREE (0x40). Non verifica neppure il DELETE CHILD del padre, i flag di ambito delle ACE o i diritti effettivi di cancellazione. Una negazione Delete che soddisfa i requisiti è sufficiente per il suo insieme protetto, quindi il solo predicato del detector non può validare la salvaguardia completa.

Il provider impedisce un rilevamento affidabile da un capo all'altro su questo percorso esaminato. In public/internal/providers/ldap/acl_parser.go:276, parseACE conserva solo le ACE Allow. Le righe 297-300 restituiscono nil per i tipi diversi da ACCESS_ALLOWED e ACCESS_ALLOWED_OBJECT, eliminando le ACE Deny attese da questo detector. Con tale input filtrato, il suo insieme protetto può rimanere vuoto e il conteggio può coprire tutte le OU inventariate, comprese OU effettivamente protette.

È una limitazione della raccolta che richiede una verifica indipendente della proprietà e della DACL, non una misura affidabile della mancanza di protezione. Correggere il provider compete al team del collector ed esula dall'ambito di questo articolo. Non si afferma alcun successo del rilevamento da un capo all'altro né alcun conteggio relativo ai clienti.