How to lock down OU movement and deletions

Start with the mechanics: what “move” and “delete” really mean in AD

In LDAP terms, moving or renaming an object (including an OU) is a ModifyDN operation. Under the hood, AD enforces this as rights on both the object and its parent container(s). Deletion is a different operation, and for OUs there’s an extra risk: Delete subtree, which removes the OU and everything under it.

• Delete (OU): Removes the OU object. If protected, AD can block it even for “powerful” delegated admins.
• Delete subtree: Removes the OU and all child objects (users, computers, groups, nested OUs). This is the “oops” button you must treat as privileged.
• Move OU: Requires rights at the source parent (remove child) and destination parent (create child), plus appropriate rights to modify/rename.

So the fix is rarely “deny everything on the OU itself.” You usually need to control: (1) who can delete the OU, (2) who can delete subtrees, and (3) who can create/delete OU objects in parent containers (which enables moves).

Layer 1: Make accidental deletion protection mandatory (baseline guardrail)

The simplest, highest ROI step is enabling Protect object from accidental deletion on every OU that matters. This adds explicit Deny access control entries that block deletion (and typically block subtree deletion) unless an admin first removes the protection.

Enable it in ADUC (GUI)

1. Open Active Directory Users and Computers (ADUC).
2. Turn on View → Advanced Features.
3. Right-click the OU → Properties → Object tab.
4. Check Protect object from accidental deletion.

Enable it at scale (PowerShell)

Use PowerShell to set this consistently across your OU tree. Do this in a test environment first, especially if you have automation that intentionally deletes/moves OUs.

# Example: protect a single OU
Set-ADOrganizationalUnit -Identity "OU=Finance,DC=example,DC=com" -ProtectedFromAccidentalDeletion $true

# Example: protect all OUs under a base OU (recursive)
Get-ADOrganizationalUnit -Filter * -SearchBase "OU=Corp,DC=example,DC=com" |
  ForEach-Object {
    Set-ADOrganizationalUnit -Identity $_.DistinguishedName -ProtectedFromAccidentalDeletion $true
  }

Operational pattern: treat “remove accidental deletion protection” as a privileged, time-bound action (change ticket, peer review, just-in-time access), then re-enable it immediately after the change.

Layer 2: Design your delegation so OU create/delete/move is rare by default

Most “OU disasters” happen because everyday admin roles were accidentally given structural rights. A clean model is:

• Tier 0 / Directory Engineering: OU structure changes (create OUs, move OUs, delete OUs, link high-impact GPOs).
• Tier 1 / Server + workstation admins: manage computer objects inside approved OUs, but cannot restructure the tree.
• Tier 2 / Helpdesk: reset passwords, unlock accounts, limited group membership tasks, no structural rights.

Keep OU restructuring rights in a small group (for example GG_AD_OU_Managers) and avoid assigning them directly to user accounts. If you want a repeatable pattern, manage access through groups and role design (see: RBAC using AD groups).

Layer 3: Explicitly block OU deletion and subtree deletion where it matters

Accidental deletion protection is excellent, but you should still think in terms of:

• Who can delete this OU?
• Who can delete a subtree under this OU?
• Who can create/delete OU objects in the parent container? (this influences move operations)

Practical approach: deny structural rights for “everyday admins”

For admin groups like Helpdesk or Desktop Support, explicitly deny them structural OU rights at the relevant scope (often at a top-level “Corp” OU that contains the real OU hierarchy):

• Delete and Delete subtree on OUs
• Create Organizational Unit objects on parent containers
• Delete Organizational Unit objects (or “Delete child”) on parent containers

Be careful with Deny ACEs: they are powerful and can surprise you later. Use them only for guardrails on structural permissions, not for routine object management.

Where to set permissions

In ADUC (with Advanced Features enabled):

1. Right-click the parent OU that contains your OU structure (e.g., OU=Corp) → Properties.
2. Go to Security → Advanced.
3. Add a permission entry for your “everyday admin” group(s) and set:
   • Type: Deny
   • Applies to: This object and descendant Organizational Unit objects (where applicable)
   • Permissions: Delete, Delete subtree (on OU objects), and create/delete OU child objects on the parent.

Rule of thumb: day-to-day admins should be able to manage objects within OUs, but not the OU objects themselves.

Layer 4: Lock down OU movement by controlling “create/delete child OU” at the boundaries

If you only protect an OU from deletion, someone may still be able to move it (and its entire subtree) into a different location, changing GPO scope and delegation boundaries. To prevent OU movement, focus on the containers where OUs can be moved from and to.

What to enforce

• On source parent containers: restrict the ability to “remove” (delete child) OU objects.
• On destination parent containers: restrict the ability to “add” (create child) OU objects.

In practice, most organizations want: “Only OU architects can create/move OUs under the top-level structure OU.” That means:

• Allow create/delete child OU to a small OU engineering group.
• Deny create/delete child OU to broader admin groups.
• Audit any OU move attempt/success.

If you have a “staging OU” pattern (where objects are moved in/out), keep that separation for users/computers, not for OUs. OUs should be stable. Moves should be change-controlled.

Layer 5: Turn on auditing so OU moves/deletes are visible and attributable

Prevention reduces risk; auditing ensures you can answer: what changed, when, and who did it? For OU movement and deletions, you want Directory Service change auditing plus targeted SACLs.

Enable Directory Service auditing (Advanced Audit Policy)

In Group Policy (typically applied to Domain Controllers):

1. Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration
2. Enable:
   • Directory Service Changes (Success, and consider Failure)
   • Directory Service Access (as needed; this often generates more volume)

Set SACLs on the OU structure you care about

Auditing is driven by SACLs. Apply auditing to top-level structure OUs (e.g., OU=Corp) and include auditing for:

• Delete and Delete subtree
• Create Organizational Unit
• Write property / changes that relate to moves/renames

Know the key event IDs to watch

On Domain Controllers, common Directory Service change events include:

• 5139: a directory service object was moved
• 5141: a directory service object was deleted
• 5136: a directory service object was modified
• 5138: a directory service object was undeleted (useful when Recycle Bin is enabled)

Feed these to your SIEM and alert specifically on:

• OU moves outside of approved change windows
• OU deletes (always high severity)
• Removal of accidental deletion protection (precursor event)
• Changes performed by non-break-glass accounts

If you’re building audit trails for OU and group changes more broadly, you’ll likely also want: Securing OU and group changes with audit trails.

Layer 6: Reduce blast radius with operational controls

Even with perfect permissions, you still need operational controls for the “rare but legitimate” OU changes. A mature setup often includes:

Just-in-time elevation for OU architects

• Use a separate admin account for directory engineering.
• Keep OU engineering group membership empty by default.
• Grant time-bound access via a PAM/JIT workflow (or at least manual approval + removal).

Two-person rule for destructive actions

For deletion or subtree operations, require peer review and explicit approval. If you can’t enforce it technically, enforce it through process and monitoring (alerts on deletion protection removal, OU deletions, and subtree deletes).

Change windows and “break glass” accounts

Maintain an offline-documented break-glass procedure and ensure those accounts are heavily monitored. Most OU disasters become catastrophic when the only recovery path is unclear during an incident.

Recovery: assume something will go wrong and plan the rollback

Locking down movement and deletions reduces incidents, but recovery readiness turns a crisis into a ticket. Your recovery choices depend on what you have enabled.

Enable Active Directory Recycle Bin

If you haven’t already enabled AD Recycle Bin (and you’re on an appropriate forest functional level), do it. It changes deletion from “restore from backup” to “undelete with attributes intact” for many scenarios. Related: Recovering deleted objects from Recycle Bin.

Have a tested backup/restore path

• System State backups of domain controllers
• Documented authoritative restore procedures (when needed)
• Regular restore tests (not just “backups exist”)

Document “what good looks like” for your OU tree

Maintain a simple, versioned export of OU structure (distinguished names, linked GPOs, delegation summary). This helps you detect drift and rebuild quickly if needed.

A practical rollout checklist

1. Inventory high-impact OUs: top-level structure OUs, OU roots with many objects, OU roots with critical GPO links.
2. Enable “Protect from accidental deletion” on those OUs (then expand coverage).
3. Review delegation: remove structural rights (create/delete OU, delete subtree) from everyday admin roles.
4. Enforce movement boundaries by restricting create/delete child OU rights on parent containers.
5. Enable auditing (Directory Service Changes) and apply SACLs to structure OUs.
6. Alert on precursors: removal of accidental deletion protection, OU move events, OU delete events.
7. Validate recovery: confirm Recycle Bin behavior and run a restore tabletop / test.

Common pitfalls to avoid

• Delegating “Full Control” at the wrong level: Full Control at a top-level OU often implies structural rights. Delegate specific tasks instead of blanket permissions.
• Relying only on “accidental deletion” protection: Great baseline, but movement control and auditing still matter.
• Overusing Deny: Deny is a scalpel, not a hammer. Use it for structural guardrails; document it; test it.
• No alerting: Auditing without alerting is just logs. Make OU move/delete events high-signal alerts.
• No recovery playbook: If an OU delete happens at 2 AM, you want a practiced, predictable path to restore.