Object Ownership and Inheritance

By default, objects are owned by the person who creates them. Who can create objects is controlled by the ACL of the object in which they are being created. For example, a user needs appropriate permissions on a container (such as an OU) in which they want to create a user object. In order to find out who owns an object, access the Security tab of an object, and then click the Advanced button. The owner tab will show you the current owner of the object, and give you choices as to who is allowed to take ownership of the object. Remember that much like NTFS ownership, ownership can only be taken, and not given.

One of the reasons all of this is important is because Active Directory allows us a much more granular level of possible administrative control if we choose to take it. That is, we can delegate control of objects to other users or groups without giving them more control than we want to. For example, I could place all users in an OU called Company Users, and then delegate the ability to reset passwords to all Help Desk users. This allows members of the Help Desk group to Reset passwords, but not change anything else about a user’s account. By the same token, I could delegate full control over the HR OU to a single user who is responsible for controlling HR resources. This user could then create users, change properties, and so forth, but only within the HR OU.

Delegation can be controlled by directly editing the DACL associated with the object you wish to delegate and changing permissions, but this can be cumbersome and confusing. Instead, Active Directory Users and Computers provides the ability to run the Delegation of Control Wizard, a tool which provides a simplified way of delegating control according to common administrative needs. To run the tool, right-click on the appropriate object (an OU for example) and choose Delegate Control.

The Delegation of Control Wizard starts, allowing you to choosing to whom you wish to delegate control. I have chosen to delegate control of the Company Users OU to Help Desk staff.

When I click next, it will ask what type of control I wish to delegate. This screen focuses on the most common task-based delegations.

However, if I were to choose to create a custom task, I could give a user or group full control of the OU, or get even more granular, allowing a group the ability to only read and change the postal code properties of an account (shown in second screen shot below). You also have to choose whether you wish to grant the ability to control all objects, or only a particular type of object.

Of course, the DACL of the object (and potentially child objects) will automatically change based on the settings you choose with the wizard. The wizard is highly recommended as the much simpler way of delegating administrative control in Active Directory. Remember that by default any permission that gets set on an object will be inherited by all child objects. If you wish to have a child object not inherit the permissions, you can simply uncheck the ‘Allow inheritable permissions parent to propagate to this object’ check box on the Security tab. You will be given the choice of either copying existing permissions to the object directly, or removing all associated permissions from the ACL.

Author: Dan DiNicolo

Dan DiNicolo is a freelance author, consultant, trainer, and the managing editor of 2000Trainers.com. He is the author of the CCNA Study Guide found on this site, as well as many books including the PC Magazine titles Windows XP Security Solutions and Windows Vista Security Solutions. Click here to contact Dan.