Access Control Lists (ACLs) are those settings that define who gets access to which objects, along with the type of access in Active Directory. These settings are called Access Control Entries (ACEs), and they are also useful in enabling auditing object accesses.
Each ACE refers to a security principal – Users, Groups and Processes and defines the object access rights (allowed or denied) for that principal. ACLs are highly flexible and more ACEs can be added as and when needed.
A typical ACE contains the following information:
- A Security Identifier (SID) that is unique to every trustee
- An Access Mask, which is a 32 bit value that defines the operations that are either allowed or denied for the trustee in the ACE.
- A flag that indicates the type of ACE viz., access denied ACE, access allowed ACE and system audit ACE.
- A set of bit flags that determine if child containers or objects can inherit the ACE from their primary object or parent.
When a security principal sends an Access Request for an object, the SID from the request is compared against the Access Control List. If the SID matches with that of a SID present in the ACL, then the security principal is granted access to the object based on the predefined rights – Eg: read, write, modify, delete, etc.
Let’s explain how ACLs work with an illustration. Assume there’s a user ‘Max Webber’ who wants to access a file. For Max to access a specific file,
- An ACE containing Max’s SID should be created for the file.
- Max should be included in a group that has access to the specified file.
The above illustration gives an overview of the file’s ACLs and its ACEs. The specified file has:
- An ACE that defines access for Max Webber based on his SID.
- Two other ACEs that provide access to the groups – Admin users and Domain users.
The above mentioned ACEs form the ACL of that file.
If a new group, say Privileged Users’ is granted permission to access the file, then all the members of the group will also get to access the file.
Types of ACLs:
An object’s security descriptor can contain two types of ACLs. So what is a security descriptor? It is a data structure that contains security information about an object. These security descriptors define everything right from who owns the object, who has access to it, and the ways by which access to the object can be audited. It is the security descriptor that contains the ACL of an object.
The two types of ACLs are:
- Discretionary access control list (DACL): This defines the security principals which are either granted or denied access to a securable object.
- System access control list (SACL): This grants power to administrators to log the access attempts made to secured objects.
Discretionary Access Control List:
Any object that doesn’t have an exclusive ACL, grants access to all the security principals who are trying to access it. When the DACL is defined, object access will be granted to those principals who are included in the ACL.
Why is the order of the Access Control Entry crucial?
Consider a situation wherein an administrator wans to allow a group to access an object but prevent a specific member of the group from accessing the object. How would an administrator do that?
Administrators need to create a separate ACE that denies access to the specific member in the group and then create another ACE granting the access to the group. The system reads the ACEs in an order until it stumbles upon an Access Allowed or Access Denied entry. By default, the ‘Access Denied’ ACEs appear first in the list. So when the system goes through the list of ACEs it reads the ACE corresponding to the access denial for the user first, before it reads the ACE that allows access thus denying the specific user the right to access while allowing the other members of the group to access the objects.
System Access Control List (SACL):
SACLs helps administrators to log all object access attempts. ACEs under SACL can generate log record for all types of accesses – failed access, successful one, or even both under the security event log category.
It is advised that access to this audit data be made available to authorized administrators only.