Object Permissions and ACLs
Although the concepts of permissions and ACLs were just discussed, you’ll need to know a little more about them. First of all, every object in Active Directory has an associated ACL. This controls who can do what to an object. By default, the ACL associated with an object is hidden, but can be viewed in the object’s properties after choosing to view Advanced Features from the View menu item in Active Directory Users and Computers:
After this has been done, access the ACL from the security tab in the object’s properties. The list of ACEs will be different based on the type of object, and will control what users can and cannot do with respect to that object. As a best practice, you should note that it is generally not a good idea to change the ACL of individual objects. Instead, change the ACL on a parent object, and by default these changes will be inherited by all child objects.
You will note that a DACL has two main columns in which ACEs can be modified – Allow and Deny. The rule is simple – the effective permissions that will apply to a user when accessing an object are the combination of all permissions that apply to the user, but an explicit deny always overrides an allow. The deny permissions should be used for special cases, such as when you want to give all users in the Help Desk group the ability to change object information for user accounts, but need to explicitly deny a single user who is a member of that group the same privilege.
Note also that the ACL that you see when viewing the permissions on an object is the standard list. If you click on the Advanced button, you are presented with a list of users and groups and their associated permissions, as shown below:
By choosing an entry from the list and then choosing View/Edit, you
can access an even more granular level of permissions for the
object, which includes controlling how inheritance settings will
be applied to the object by default, as shown below.
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, as shown below:
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, as shown below:
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, as shown directly below:
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.