5

Background

After I configured our Active Directory so that the ability to move computers was delegated to helpdesk staff, I started hearing reports that computers would get "stuck" in specific OU's. They can move a computer in, but get an "access denied" message when trying to move a computer out. The problem is 100% reproducible, and is only present on a small number of OU's in our domain.

Both OU's have Protect object from accidental deletion enabled.

What I already know

Inspecting the ACL using ldp.exe does reveal one tiny but important difference. For some reason, only ONE of the OU's has the attribute ACTRL_DS_DELETE_CHILD denied to Everyone.

Toggling the Protect object flag on and off on either OU does not fix the problem. It does modify the ACL as expected, but the ACTRL_DS_DELETE_CHILD flag is completely unmodified in either case.

I can use this solution to "fix" a specific OU:

  1. Turn off Protect object flag
  2. Delete the Deny ACE associated with Everyone.
  3. Turn Protect object back on
  4. Now the ACL's match.

Could it be that different versions of Active Directory, or Remote Server Admin Tools, might have different behaviour with how the Protect object flag is actually represented on an OU?

The Question

What could possibly cause this difference, and what can I do to ensure that it is corrected on all OU's in the Active Directory domain?

Details

The unified diff looks like this:

18c18
<       Ace Mask:  0x00010042
---
>       Ace Mask:  0x00010040
20d19
<           ACTRL_DS_DELETE_CHILD

Minor ACE ACL difference prevents moving computer objects

How to identify affected organizational units

EDIT: I wrote a PowerShell script to locate Organizational Units that have this flag set on them.

$Base = "OU=MyOU,DC=your,DC=domain,DC=com"
Import-Module ActiveDirectory
Set-Location AD:
Get-ADOrganizationalUnit -SearchBase $Base -filter * |
    ForEach-Object {
        $matches = @(
            (Get-ACL $_.DistinguishedName).access |
            Where-Object {
                $_.IdentityReference -eq "Everyone"
            } |
            Where-Object {
                $_.ActiveDirectoryRights -like "*DeleteChild*"
            }
        )
        if ($matches.length -gt 0) {
            Write-Output $_
        }
    } |
    Format-Table DistinguishedName
Nic
  • 13,025
  • 16
  • 59
  • 102
  • I feel like I'm missing something here... it's that way because someone or something set it that way. And you resolve it by removing the DENY `Delete child` ACE from the OU that has it. Or... why wouldn't that be the answer? – HopelessN00b Mar 26 '14 at 22:52
  • 1
    @HopelessN00b There is no visible difference from the Security tab in ADU&C; it can only be seen from ldp.exe. I seriously doubt that somebody modified an obscure ACE on a bunch of OUs using `ldp.exe`. It's much more likely to be a historical remnant, and I'd like to confirm or deny that if possible. – Nic Mar 26 '14 at 22:56
  • Ah, so that would be what I was missing. What are your FLs now, and what were they historically (if you know)? – HopelessN00b Mar 26 '14 at 22:58
  • @HopelessN00b Our current forest and domain functional levels are `2008 R2`. We started with 2003 (or possibly earlier). – Nic Mar 26 '14 at 23:05
  • How many OUs do you have? I'm drawing a blank on possible causes, but I think the quickest way to test that none of your OUs have this ACE in them would be to use a PowerShell script (run as domain admin, of course) to create, and then attempt to delete an object in all your OUs. Where the delete fails, you can assume the OU needs this ACE corrected. I imagine you could also use PowerShell to manipulate this particular ACE on your OUs as well, but I'm not sure exactly how at the moment, so I don't want to state that like I'm sure and risk leading you down the wrong path. – HopelessN00b Mar 26 '14 at 23:29
  • @HopelessN00b I wrote a PowerShell script to identify affected OU's. Just 16% of our OU's have this unusual ACE on them. Their creation dates range from 2001 to last week. So weird. – Nic Mar 26 '14 at 23:32
  • Found a way to reproduce the issue: Enable "protect object", then notice that the ACL on the parent OU has changed. Further toggling "protect object" off or on does not affect the parent OU. http://social.technet.microsoft.com/Forums/windowsserver/en-US/16680d9c-e01d-4f1c-b1f5-8e1fa21982ff/protect-object-from-accidental-deletion – Nic Mar 27 '14 at 02:49

1 Answers1

1

Explanation

When you enable the Protect object from accidental deletion flag on an organizational unit, it affects the ACL of that object and its parent.

  1. The protected OU gets {Deny, Everyone, Delete+DeleteSubtree}
  2. The parent OU gets {Deny, Everyone, DeleteChildObjects}

The access control entry on the parent is necessary for enforcing protection, but does have unexpected results like that observed here. And no matter how many times you toggle the protect flag, the Deny access control entry on the parent will never be automatically removed.

Thus in the Active Directory that I was working with, any OU which had ever contained a protected OU (basically any non-leaf OU) had the Deny DeleteChild ACE on it, thus "trapping" computer objects in that OU from the perspective of users with delegated permissions.

Via: Protect object from accidental deletion on Technet Forums

Solution

This can easily be resolved by ensuring that the base OU used to delegate permissions has these two access control entries in the ACL.

  1. {Allow, GROUP, Create/delete computer objects, this object and all descendents}*
  2. {Allow, GROUP, Delete+DeleteSubtree, Descendent computer objects}

I had already configured the first access control entry on the relevant OU in my directory, but now I know that was insufficient. The first rule gets cancelled out by the automatic deny ACE set up whenever a protected OU is created. The second rule allows an object to be deleted directly, thus bypassing the deny entry set up when a child OU is protected.

*(It's possible that the first rule is now redundant. Can anyone confirm?)

Nic
  • 13,025
  • 16
  • 59
  • 102