Configuring DACLs to Secure Active Directory Objects

Configuring DACLs to Secure Active Directory Objects

All objects and their properties in Active Directory have security descriptors to control access to the object and the values of the object s attributes. As with NTFS file system objects, the Active Directory object s security descriptor includes a discretionary access control list (DACL) and a system access control list (SACL) in addition to the object s ownership data. Figure 4-1 shows a security descriptor.

Figure 4-1. Contents of a security descriptor for Active Directory objects and attributes

What Are DACLs?

Discretionary access control lists can be configured at the discretion of any account that possesses the appropriate permissions to modify the configuration, including Take Ownership, Change Permissions, or Full Control permissions. DACLs consist of several elements, as described in this list:

• Header

  Metadata pertaining to the access control entries (ACEs) associated with the DACL.

• SID (user)

  The security identifier of the owner of the object.

• SID (group)

  The security identifier of the built-in Administrators or Domain Admins group if the account that owns the object is a member of either of these groups.

• Generic deny ACEs

  Access control entries that deny access to an account or security group based on their SIDs. These ACEs can be inherited from the object s parent or assigned directly to the object, and they are specific to the object and child objects of the same class, based on the security settings defined in the object class in the schema.

• Generic allow ACEs

  Access control entries that allow access to child objects to an account or security group based on their SIDs. These ACEs can be inherited from the object s parent or assigned directly to the object, and they are specific to the object and child objects of the same class.

• Object-specific deny ACEs

  Access control entries that deny access to child objects to an account or security group based on their SIDs. These ACEs can be inherited from the object s parent or assigned directly to the object, and they apply to specific classes of child objects.

• Object-specific ACEs

  Access control entries that deny access to an account or security group based on their SIDs. These ACEs can be inherited from the object s parent or assigned directly to the object, and they apply to specific classes of child objects.

Table 4-2 shows the settings of an example DACL an organizational unit (OU) might have.

Table 4-2. Example of a DACL

Group	Permissions	Scope
Enterprise Admins	Full Control	This object and all child objects
Authenticated Users	Read	This object
Security Managers	Reset Password	User objects

Figure 4-2 offers a visual depiction of these settings, and Figure 4-3 displays the user interface for this DACL.

Figure 4-2. Elements of DACL example shown in Table 4-2

Figure 4-3. User interface view of DACL example shown in Table 4-2

Generic ACEs offer limited control over the kinds of child objects that can inherit them. Generic ACEs distinguish between objects that can contain other objects, such as group and organization unit objects and objects that cannot contain other objects, such as user objects. For example, the DACL on an organizational unit object can include a generic ACE that allows a member of a group object the permissions to delete members of other group objects in the OU. Because this ACE can be performed only on container objects and child objects of the same class, it will not be inherited by noncontainer objects, such as user objects.

Object-specific ACEs offer greater granularity of control over the types of child objects that can inherit them. For example, an organizational unit object s DACL can have an object-specific ACE that is marked for inheritance only by user objects. Other types of objects, such as computer objects, will not inherit the ACE. This capability is the crux of object-specific ACEs: their inheritance can be limited to specific object classes of child objects.

These two categories of ACEs control access to objects in a somewhat similar fashion. Generic ACEs apply to an entire object. If a generic ACE gives a particular user Read access, the user can read all information associated with the object both data and properties.

Object-specific ACEs can apply to any individual property of an object or to a set of properties. These ACE types are used only in ACLs for Active Directory objects, which, unlike other object types, store most of their information in properties. It is often desirable to place independent controls on each property of an Active Directory object, and object-specific ACEs make that possible. For example, when you define permissions for a user object, you can use one object-specific ACE to allow Principal Self (the user) Write access to the Phone-Home-Primary property (homePhone). You also can use other object-specific ACEs to deny Principal Self access to the Logon-Hours property (logonHours) and other properties that set restrictions on the user account.

How DACLs Work

When access is requested to an Active Directory object, the Local Security Authority (LSA) compares the access token of the account requesting access to the object to the DACL. The security subsystem checks the object s DACL, looking for ACEs that apply to the user and group SIDs referenced in the thread s access token. The security subsystem then steps through the DACL until it finds any ACEs that either allow or deny access to the user or one of the user s groups. The subsystem does this by first examining ACEs that have been explicitly assigned to the object and then examining ones that have been inherited by the object.

If an explicit deny is found, access is denied. Explicit deny ACE entries are always applied, even if conflicting explicit allow ACEs exist. Explicit allow ACEs are examined, as are inherited deny and allow ACEs. The ACEs that apply to the user are accumulated. Inherited deny ACEs overrule inherited allow ACEs, but are overruled themselves by explicit allow permissions. If none of the user or groups SIDs in the access token match the DACL, the user is denied access implicitly. Figure 4-4 shows the process of evaluating access token contents against a DACL.

Figure 4-4. Access control in Active Directory

Accounts with Full Control, Modify Permissions, or Modify Owner permissions can change the DACL and SACL on the object.