Object Owner, who is that in your Active Directory environment?
When delegating admin access in Active Directory there are a few things to consider, and one of them is the owner.

When an object is created, it will have an owner set in the Security Descriptor guarding that object. The object owner will be set depending of who is creating it.

Let’s use a user object as an example:

If a user is member of the Domain Admins (DA) or the Enterprise Admins (EA) group create a user object, the owner of the object will be set to either DA or EA depending on which group he’s a member of. If he’s member of both, it will default to Domain Admins.

This is no problem. But when you delegate administrative tasks as create different types of objects in the Directory, the object owner will be set as the user creating the object.

If we have a group which is delegated Full Control on the user object class in the OU Corp Users.
Members of that group is granted permissions to create, delete and modify the User objects. When the user is removed from that group the idea is his access should be revoked, and it is.

Except from all the users he has created.

If you are an owner of an object in Active Directory you are default granted Modify Permissions and Read Permissions. This opens a weak spot, where used to be delegated admins still has permissions to modify the Security Descriptor and grant themselves Full Control of the object.

With this, a privilege escalation path opens.
If it’s a Group granting access to more users or access to other systems and data, he could take control of the group and add himself into it.

Note: He doesn’t need to be able to manage his own account since it’s the member attribute on the group that is modified, the memberOf on the user is just a back-link maintained by the System.

If it’s a user object, he could reset the password and logon as the user and access systems/data.
Even if the user has the “Smart card is required for interactive logon” bit flag set, this is not hard to bypass since he controls the userAccountControl attribute and the compromised user won’t notice a password reset since the Smart Card will still work.

If the user is Owner of an OU object, he can grant Full Control of that OU and enable inheritance taking control of everything in that OU structure (that has inheritance enabled).

The list could go on and on.

How do we manage this kind of stuff, reset the owner of all objects to DA, EA or whatever it should be? Create an application using the DirSync LDAP Control and catch all the changes and set the owner immediately? Or maybe we have a IdM system taking care of everything in AD.

If not, this is a huge problem and a way to manage this came in Windows Server 2008 and Vista with a new Security Principal named Owner Rights.

From MS:
By default, Owner Rights are not defined on objects. This means that the pre–Windows Server 2008 behavior of owners having WRITE_DAC permissions to the objects that they own still applies.

When you add the Owner Rights security principal to objects, you can specify what permissions are given to the owner of an object. For example you can specify in the access control entry (ACE) of an object that the owner of a particular object is given Read permissions or you can specify NULL permissions to an object, which grants the owner of the object no permissions.

By using this it only overrides the Owner Permissions, if a user has delegated access to the object it will still work.

Its recommended to have all DCs on the Windows Server 2008 level since older DCs won’t know how to handle the Owner Rights security principal making it useless.

It’s not uncommon I see these problems at customers trying to delegate administration. If you need to implement this, you could start here: AD DS: Owner Rights