Active Directory Design and Security Concepts - MCTS Guide to Microsoft Windows Server 2008 Active Directory Configuration - page 122

Table 4-4 ACEs for an OU: Example 3

ACE Permission How assigned

Bill Allow Full control Explicit

Jane Allow Create all child objects Explicit

Group1 Deny Full control Inherited

Group2 Deny Create all child objects Inherited

The effective permissions are as follows:
• Bill: Allow Full control
• Jane: Allow Create all child objects
• Tom, Mary, Susan, Alex: Denied access

In this example, the Deny permissions are inherited, so any explicitly assigned Allow per-
missions take precedence. Remember, this is the exception to the rule that Deny permissions
override Allow permissions. So although Bill and Jane are denied permission because of their
group memberships, those permissions are inherited, and the Allow permissions for their user
accounts are assigned explicitly.
Now take a closer look at permission inheritance. As stated, permissions for an object are
inherited from its parent automatically. In Active Directory, the domain is the top-level object for
permission inheritance. So the domain object doesn't inherit any permission settings because it
has no parent container from which to inherit settings. OUs inherit some permissions from the
domain object or, with nested OUs, from their parent OU. In addition, several permissions are
added to an OU's DACL by default when it's created. You can see which permissions are inher-
ited and which have been added to a DACL by viewing the Advanced Security Settings dialog
box, shown previously in Figure 4-5. The Inherited From column shows “<not inherited>” or
the complete path to the object from which permission was inherited. The Apply To column
shows whether the permission is set to be inherited by child objects. The following are some of
the most common settings for permission inheritance:
• This object only —The permission setting isn't inherited by child (descendant) objects. This
setting is the default when a new ACE is added to an object's DACL manually instead of
with the Delegation of Control Wizard.
• This object and all descendant objects —The permission setting applies to the current
object and is inherited by all child objects.
• All descendant objects —The permission setting doesn't apply to the selected object but is
inherited by all child objects.
• Descendant [object type] objects —The permission is inherited only by specific child object
types, such as user, computer, or group objects.

Permission inheritance is enabled by default on child objects but can be disabled. Inherited
permissions can't be changed or removed without disabling permission inheritance first. However,
you can add permissions to an object without disabling inheritance. In Figure 4-5, note the
“Include inheritable permissions from this object's parent” check box. By default, it's selected,
which means the object does inherit permissions from its parent object. Clearing this check box
blocks permission inheritance, and you're prompted to copy inheritable permissions from the
parent object, remove inherited permissions, or cancel the operation. Selecting the option to copy
inheritable permissions is a good idea so that you have a starting point for your DACL. After you
have disabled inheritance, you can always remove or change the copied permissions.
Use caution before changing permissions and permission inheritance. Incorrect settings can
cause Active Directory access problems, so be sure you know what effect your changes will have
on Active Directory before applying them. If your changes cause problems, you can click the