The effective permissions appear to be hiding the fact that the AO can delete the object. I truly don't understand this.

I liked this Secure Identity post so much about this topic, I figured I'd reference and quote the relevant parts of it as it relates to your question specifically.

I think that's a good question many people would want to know once they are aware of this if using Account Operators is standard practice in their AD domain environment—I certainly had never tried to delete a Domain Admin member AD account with an Account Operator, but I have supported environments in the past where they used Account Operators where I was a Domain Admin.

Now, if we look at the options we have regarding deleting objects in Active Directory you may have seen that there is three different types of Delete:

• Delete (DELETE Access Mask)
• Delete Child (ADS_RIGHT_DS_DELETE_CHILD Access Mask)
• Delete Subtree (ADS_RIGHT_DS_DELETE_TREE Access Mask)

And here it gets interesting. When performing a delete action, the system verifies the security descriptor for both the object and its parent object before allowing or denying the deletion.

An ACE that explicitly denies Delete access to a user has no effect if the user has Delete Child access on the parent. Similarly, an ACE that denies Delete Child access on the parent can be overridden if DELETE access is allowed on the object itself.

Source: Access Control and Object Deletion

Delete and Delete Child examples:

Example One:

My admin user Tony don’t have the ACE: Allow Delete access on a Domain Admin user named Hank. Tony could still delete the account if he has the ACE: Allow Delete Child User on the parent OU.

Example Two:

If an Explicit ACE: Deny Delete access is set on Hank. Tony would still be able to delete the account if he has the ACE: Allow Delete Child User on the parent OU.

And if we reverse it: Tony ends up in an ACE: Deny Delete Child User on the parent OU, he could still delete it if he has Explicit Allow Delete in an ACE on the user object.

So, with this we can see that the AdminSDHolder Security Descriptor doesn’t really protect the admins or nested groups in all scenarios. If you look back at the effective permissions picture, Tony had no rights on the user to delete it. But he has the ACE: Allow Delete Child User on the parent OU and will be able to delete Hank which is a member of Domain Admins group.

Default rights

Now when we have talked about the delete access rights it could be a good idea to think about who has these powers default in Active Directory? Besides the obvious ones like Administrators, Domain Admins, Enterprise Admins we of course also have the well-known Account Operators group.

Account Operators has default explicit Full Control on User, Computer, Group and InetOrgPerson objects. They don’t have that explicit access granted on the AdminSDHolder Security Descriptor, but they do have an explicit Create/Delete Child User, Group, Computer and InetOrgPerson on Organizational Units. If the parent OU to the Domain Admins don’t have the explicit Deny Delete Child Users AO will be able to delete Domain Admin users.

(This can be removed from the defaultSecurityDescriptor attribute of the object class defined in Schema if you’re up to the task)

Another angle is targeting group nesting, if users has DA membership via group nesting just delete that group and they won’t be DA anymore.

These are a few reasons why I want to have Admin OU separated as a Root OU to minimize the risks of faulty delegation.

Source

Supporting Resources

• Secure Identity
• Access Control and Object Deletion