AD OU accidental deletion protection: verify safeguards before cleanup

What AD OU Accidental Deletion Protection Does

AD OU accidental deletion protection is a safeguard to review before directory cleanup. An organizational unit can contain identities and sit within an administrative hierarchy that other teams depend on. Before removing or reorganizing that hierarchy, establish which OUs should remain, who owns the decision, and whether the actual directory permissions provide the intended protection.

Microsoft's Set-ADOrganizationalUnit reference describes ProtectedFromAccidentalDeletion as a Boolean property: when true, the object cannot be deleted without changing the property. This is a permission safeguard, rather than an immutable lock. Administrators who can remove the protection still require a reviewed operational decision.

This how-to was reviewed on 4 October 2026 against Microsoft Learn and the collector source identified below. All commands are documentary reader examples, not operations executed against a customer domain. No deletion, restoration, or successful protection check is claimed here.

How It Works: Permissions, Creation Defaults, and Recovery

The protection is represented by Deny permissions

The protection uses two Deny permissions for Everyone, identified by SID S-1-1-0: Delete and Delete Subtree. Microsoft's accidental-deletion prevention guidance describes Deny ACEs for DELETE and DELETE TREE on the object. It also describes a complementary DELETE CHILD denial on the parent. Review the object and its parent where permission behavior is unclear; do not equate one matching ACE with a complete effective-permission assessment.

In Active Directory Users and Computers, enable Advanced Features to expose the Object tab and its protection checkbox. For a permission review, inspect the Security tab's advanced entries, their trustee, denied rights, and scope. The prevention guidance cited above documents the checkbox and the underlying permission model. Keep a record of the relevant entries rather than relying solely on a screenshot of a checked box.

The distinction matters when comparing tools. An extended property presents an administrative view of protection, while a detector may recognize only a subset of permission representations. An ACL review must also account for the parent and scope of each entry. If those observations disagree, preserve the disagreement and investigate it before changing permissions.

A protected creation default does not audit existing OUs

Example 1 of New-ADOrganizationalUnit creates a protected OU without explicitly setting the protection parameter. Example 2 explicitly creates an unprotected OU with $False. Therefore, a current creation default does not establish the state of older, migrated, or subsequently modified OUs. Their protection may differ and needs to be read.

Our default containers and redirection guide uses that implicit protection when creating target OUs for redircmp and redirusr. Its concern is placement and Group Policy scope. Reviewing an existing OU's deletion safeguards is a separate task; the creation example does not provide an inventory or approval for cleanup.

Prevention and recovery answer different questions

Protection aims to prevent an accidental operation. Backups and object recovery address what happens after data is lost. Microsoft's Recycle Bin guidance explains that only objects deleted after enablement can be recovered through that feature. Check the actual feature state and recovery preparation separately.

Our Active Directory forest recovery and backup validation guide explains backup selection, restore evidence, and Recycle Bin limits. Use it for the complementary recovery review. Neither a protected OU nor an available Recycle Bin proves that a forest recovery has been validated. Likewise, recovery preparation does not justify leaving a production OU unprotected without an accepted exception.

Detection: Independently Inventory and Read the DACL

1. Establish a successful, scoped collection

Use an authorized administration host with the Active Directory PowerShell module. Record the domain, queried server, collection time, credential context, and search scope. A failed or partial read belongs in the evidence record as an unresolved collection issue. Do not classify an unreadable object as unprotected, and do not interpret an empty result as a completed inventory.

The following reader example adapts the documented Filter and Properties parameters of Get-ADOrganizationalUnit. It requests the extended property explicitly:

Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion

Choose the intended domain and server rather than silently accepting an administration host's defaults. Learn also documents Server, SearchBase, and SearchScope for defining that context. The command above is an inventory starting point, not a forest-wide completeness guarantee or an instruction to modify every result.

For each successfully read OU, retain its distinguished name and object GUID alongside the property value. Add the responsible business or infrastructure team, intended purpose, and any proposed cleanup decision. The responsible team is a review input; do not assume an attribute or an OU name proves who may approve deletion.

2. Read the permissions independently of the collector

For a specific object, the next reader example requests both the protection property and security descriptor using the same documented Properties mechanism. The Fabrikam DN is a fictional placeholder to replace with the reviewed target:

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

Inspect the returned security descriptor's DACL with an authorized directory administration tool, or use the advanced Security view in Active Directory Users and Computers. Confirm Everyone by its SID rather than depending on a localized display name. Examine Delete and Delete Subtree denials, whether they apply to the object, and relevant parent permissions. Retain the raw or exported permission evidence when available.

This independent read must preserve Deny entries. Reusing the collector's filtered ACL list reproduces the exact limitation under investigation. If access to the descriptor fails, record that failure and obtain the appropriate read access through the normal administration process. A property value and a failed DACL read should remain distinguishable.

3. Reconcile findings with directory evidence

Compare the collector inventory with the successfully read administrative inventory. Use object identifiers and actual DNs to investigate discrepancies. A spelling or case difference should prompt reconciliation, rather than a decision that two records necessarily describe different objects. Preserve the original values so the collector's case-sensitive lookup can be explained.

A finding supplies neither an attack timeline nor a deletion history. Do not infer compromise, malicious intent, or a completed incident from this configuration signal. If an actual deletion has occurred, its investigation and recovery need separate evidence.

Remediation: Protect Selected OUs and Bound Cleanup Exceptions

1. Decide the intended state with the owner

Start with the reconciled inventory. Identify retained production OUs, staging hierarchies, migration exceptions, and objects proposed for removal. Ask the responsible team to confirm dependencies and the exact objects covered by the change. An apparently empty OU is not itself an approved cleanup request.

Record the current property and DACL evidence, decision owner, target identifier, intended state, and verification method. Review who can change the relevant permissions. Protection does not replace that administrative review, a usable backup, or an object-recovery plan. If collection or ownership remains uncertain, keep the item open rather than turning uncertainty into a bulk change.

2. Enable protection on an approved retained OU

This reader example uses the documented Identity and ProtectedFromAccidentalDeletion parameters of Set-ADOrganizationalUnit, setting the Boolean to true for a fictional target. It is a targeted modification example, not a recommendation to pipe the whole inventory into a change:

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

Apply the change only to the reviewed object through the authorized administration workflow. Save any error and the actual operation outcome. A request to set a value is different evidence from a successful directory update. Where a change fails, investigate access and target context before retrying or expanding permissions.

3. Re-read the object and its relevant permissions

After a successful change, independently retrieve the target again:

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

Confirm the property and inspect the DACL, using the recorded collection context. Preserve before-and-after evidence and any remaining discrepancy. If another server is part of the verification plan, record that separate read rather than assuming all directory views are already identical. Close the change only against the intended acceptance evidence.

Do not attempt a production deletion to demonstrate that protection works. This guide requires a successful readback and permission review; it does not prescribe a destructive test. A collector count that remains unchanged is also insufficient to declare this modification unsuccessful, given the provider defect described below.

4. Limit removal of protection to the approved operation

Microsoft's Set reference includes a $false example for removing protection. Such a change belongs only in a separately approved cleanup or migration decision. Record the precise target, reason, operator, and period of the exception. Avoid removing safeguards from an entire hierarchy merely to simplify one operation.

After the approved work, reapply protection to retained objects that were temporarily exempted and repeat the property/DACL review. If the object was intentionally deleted, retain the approval and operation evidence; there is no surviving object to reprotect. An abandoned or failed cleanup must not silently leave retained OUs without their intended safeguard.

How EtcSec Detects This

The reviewed etc-collector check is OU_UNPROTECTED, in public/internal/audit/detectors/ad/advanced/other/ou-unprotected.go:24. The detector and LDAP provider were read at commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; the same relevant behavior was also inspected at collector HEAD 42bfefbace3189588e76ff291c39e100c6a603a0.

The detector builds a set of protected object DNs from supplied ACL entries. An entry qualifies only when its type matches the exact ACCESS_DENIED type name, its trustee equals S-1-1-0, and its access mask contains DELETE (0x10000). The type-name comparison uses strings.EqualFold, so letter case is ignored for that comparison; ACCESS_DENIED_OBJECT is a different type and does not qualify.

It then looks up each inventoried ou.DN in that set using the ObjectDN string key. That DN match is case-sensitive. Unmatched OUs contribute to one Low finding's Count. The finding is returned even at count zero; affected OU entities are added only when details are requested and the count is positive.

Despite the broader comment about Delete and Delete Subtree, the predicate does not test DELETE_TREE (0x40). It also does not test parent DELETE CHILD, ACE scope flags, or effective deletion rights. A qualifying Delete denial is sufficient for its protected set, so the detector predicate alone cannot validate the full safeguard.

The provider prevents reliable end-to-end detection on this reviewed path. In public/internal/providers/ldap/acl_parser.go:276, parseACE retains only Allow ACEs. Lines 297-300 return nil for types other than ACCESS_ALLOWED and ACCESS_ALLOWED_OBJECT, eliminating the Deny ACEs this detector expects. With that filtered input, its protected set can remain empty and the count can cover all inventoried OUs, including OUs that are actually protected.

This is a collection limitation requiring an independent property and DACL check, not a reliable measurement of missing protection. Correcting the provider belongs to the collector team and is outside this article's scope. No end-to-end detection success or customer count is asserted.