4.3 Discretionary Access Control Lists (DACLs) and Access Control Entries (ACEs)

Discretionary access control lists (DACLs, but often shortened to ACLs) form the primary means by which authorization is determined. An ACL is conceptually a list of <account, access-rights> pairs, although they are significantly richer than that.

Each pair in the ACL is termed an access control entry (ACE). Each ACE has additional modifiers that are primarily for use during inheritance. There are also several different kinds of ACEs for representing both access to a single object (such as a file) and access to an object with multiple properties (such as an object in Active Directory).

The ACE contains the SID of the account to which the ACE pertains. The SID can be for a user or a group.

Windows supports both positive ACEs, which grant or allow access rights to a particular account, and negative ACEs, which deny access rights to a particular account. This allows a resource owner to specify, for example, grant read-access to group Y, except for user Z.

DACLs 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 the following elements.

Header: Metadata pertaining to the ACEs associated with the DACL.

SID (user): The SID of the owner of the object.

SID (group): The SID of the built-in Administrators or Domain Admins group if the account that owns the object is a member of either of these groups.

Access control entry (ACE): A DACL can contain several ACEs. The following list identifies and describes these terms:

Explicit allow ACE: An ACE applied directly to the resource that grants access. An explicit allow will always override an inherited deny but will always be overridden by explicit deny ACEs.

Explicit deny ACE: An ACE applied directly to the resource that denies access. An explicit deny will always override all other permissions.

Generic deny ACE: An ACE that denies access to an account or security group based on the user or group SID. A generic deny ACE can be inherited from the object's parent or assigned directly to the object. The generic deny ACE is 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 ACE: An ACE that allows access to an account or security group based on the user or group SID. A generic allow ACEs can be inherited from the object's parent or assigned directly to the object. The generic allow ACE is specific to the object and child objects of the same class, based on the security settings defined in the object class in the schema.

Inherited deny ACE: An ACE inherited from the resource's parent object. An inherited deny ACE overrides an inherited allow permission, but is overridden by an explicit allow.

Inherited allow ACE: An ACE inherited from the resource's parent object.

Object-specific deny ACE: An ACE used within Active Directory that does one of the following:

  • denies access to a property on the Active Directory object

  • denies access to a property set on the Active Directory object

  • limits the ACE inheritance to a specified type of child object based on the SID(s) of the child or children.

The object-specific deny ACE can be inherited from the object's parent or assigned directly to the object. Also, the object-specific deny ACE applies to specific classes of child objects.

Object-specific allow ACEs: An ACE used within Active Directory that does one of the following:

  • Allows access to a property on the Active Directory object

  • Allows access to a property set on the Active Directory object

  • limit the ACE inheritance to a specified type of child object based on SID(s) of the child or children.

The object-specific allow ACE can be inherited from the object's parent, or assigned directly to the object/ Also, the object-specific allow ACE applies to specific classes of child objects.

When access is requested to an Active Directory object, the Local Security Authority (LSA) compares the access token of the account that is 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 user's access token. The security subsystem then steps through the DACL until it finds any ACEs that allow or deny access to the user or to 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. The following illustration shows the important parts of an access token and a DACL when a request is evaluated.

78c67bb8-721f-434d-995b-04a954469809

Figure 6: Evaluation process for access tokens against a DACL

If an explicit deny is found, access is denied. Explicit deny ACEs are always applied, even if conflicting 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 SIDS or group SIDs in the access token match the DACL, the user is denied access implicitly.

In Windows, a security principal's level of access to files and folders is determined by NTFS file system and share permissions. These permissions are discretionary; anyone with ownership of a file or folder, Change permissions, or Full Control permissions can assign access control at their discretion. When newly installed, Windows assigns default permission structures to operating system files and folders, but a user might need to alter these permissions to meet specific security requirements.

When a user attempts to access a file or folder on an NTFS partition, the user's access token is compared with the DACL of the file or folder. If no ACEs correspond to a SID in the user's access token, the user is implicitly denied access to the resource. If ACEs correspond to the user's access token, the ACEs are applied in the following order.

  1. Explicit deny

  2. Explicit allow

  3. Inherited deny

  4. Inherited allow

ACEs that apply to the user are cumulative, meaning that the user will receive the sum of the ACEs that apply to his or her user account and groups of which the user is a member. For example, if an ACL contains two allow ACEs that apply to the user, one for Read access and the other for Write access, the user will receive Read and Write access.

 
Show: