Windows 2000 Active Directory provides a user interface (UI) to modify the access control permissions for objects within the directory. This UI is referred to as the Access Control List (ACL) Editor. This article addresses a concept of inheritance used by the ACL Editor that administrators should be aware of. For more information on the ACL Editor, please reference the product documentation.

When a user or group is given permissions in the ACL Editor dialog box, by default these permissions are restricted to the container object itself, and the child objects within the container are not affected by the permission change. These child objects do, however, have default explicit permissions of their own. For example, an administrator creates an Organizational Unit (OU) within the domain named "OU1". Within OU1, several user objects exist. The administrator adds a user to the permissions list for OU1 and grants that user Full Control. When the user logs on and attempts to modify one of the user objects within OU1, the user receives an access denied error message. This is because the user was only given permissions on the container object and not on the child objects of that container.

The administrator can either:

• Change the scope of the user's permissions on the container object, and allow the child objects to inherit the permissions from the parent container.
  
  -or-
• Add the user to the permissions list of each object within the container.

By default, child objects of a container will allow the inheritance of permissions from the parent container. When adding or modifying a permission on the parent container, perform the following steps to allow those permissions to propagate to child objects.

1. Open the Properties for the container object in the Directory and select the Security tab.
2. Click Advanced. This will display the Access Control Settings dialog box.
3. Select the user or group to modify the permissions for, and click View/Edit. If the user is not already present, click Add to add the user before continuing.
4. In the drop down menu for Apply Onto, select "this object and all subobjects," and customize the permissions appropriately.
5. Check the state of the "Apply these permissions down the tree" check box. If this check box is disabled, the permissions will only be propagated to the immediate child objects of this container. If this check box is enabled, it allows the inheritance of permissions to flow past the immediate children to other containers within the parent.
6. Click Ok and close the remaining dialog windows.

As stated above, child objects of a container will allow the inheritance of permissions from the parent container by default. To confirm this, the administrator can open the properties for a given object, select the Security tab, and note the state of the "Inherit permissions from parent" check box at the bottom of the property page. To view the inherited permissions, click Advanced, and note that the user who was given permissions at the container level is listed in the permissions list, but with a discolored icon.

To disable a particular object's inheritance of the parent container's permissions, clear the "Inherit permissions from parent" check box. When this is done, the users and groups that were given permissions at the parent container level are now displayed as active entries in the permissions list. The administrator may remove these entries before closing the dialog box.