In this post will try to describe what ACLs and all its components is and how they are used.

In Windows you can delegate access to different kinds of Securable Objects. A Securable Object has a Security Descriptor (SD). The SD helps control the access to the object, it contains information of the owner, what to be audited and granted access in what way. It contains the actual ACL which sets the security permissions. In Active Directory all objects has a Security Descriptor.

The most common securable objects are:

‒ Files or folders on an NTFS file system
‒ Active Directory objects
‒ Registry keys
‒ Network shares
‒ Local or remote printers
‒ Windows services
‒ Named pipes
‒ Anonymous pipes
‒ Processes
‒ Threads
‒ File-mapping objects
‒ Access tokens
‒ Window-management objects (window stations and desktops)
‒ Interprocess synchronization objects (events, mutexes, semaphores, and waitable timers)
‒ Job objects
‒ Distributed Component Object Model (DCOM) objects

So, now when we know what we can protect I will do a walkthrough of how ACLs and its components work for file systems and Active Directory.

Access Control List (ACL)

An ACL is an ordered list of ACEs that define the protections that apply to an object and its properties. Each ACE identifies a security principal and specifies a set of access rights that are allowed, denied, or audited for that security principal.

An object’s security descriptor can contain two ACLs:

1. A DACL that identifies the users and groups that are allowed or denied access
2. A SACL that controls how access is audited

When a user tries to access a file, the Windows system runs an AccessCheck and compares the security descriptor with the users access token and evaluates if the user is granted access and what kind of access depending on the ACEs set.

Discretionary Access Control List (DACL)

A DACL (often mentioned as the ACL) identify the users and groups that are assigned or denied access permissions on an object.  It contains a list of paired ACEs (Account + Access Right) to the securable object.

System Access Control List (SACL)

SACLs makes it possible to monitor access to secured objects. ACEs in a SACL determine what types of access is logged in the Security Event Log. With monitoring tools this could raise an alarm to the right people if malicious users tries to access the secured object, and in an incident scenario we can use the logs to trace the steps back in time. And last, you can enable logging for troubleshoot access issues.

Access Control Entries (ACE)

An ACE is what finally describes what access rights a security principal has to the secured object. A DACL or SACL can contain a lots of ACEs.

All ACEs include the following access control information:

1. A SID that identifies a user or group
2. An access mask that specifies access rights
3. A set of bit flags that determine whether child objects can inherit the ACE
4. A flag that indicates the type of ACE

There are two types of ACE collections:

Generic ACEs:

A Generic ACE can have the following types:

‒ Explicit allow ACE
‒ Explicit deny ACE
‒ Generic deny ACE
‒ Generic allow ACE
‒ Inherited deny ACE
‒ Inherited allow ACE
‒ Audit allow and deny ACEs

A Deny ACE always takes precedence over an Allow ACE. Inherited Deny ACE takes precedence over Inherited Allow ACE. But if you set an Explicit Allow ACE on the child object, you break inheritance and Allow permission takes precedence.

Explicit Deny always takes precedence of its object.

On a Windows system the access to files and folders is set in the NTFS file system. When a user tries to access a file or folder the users access token is compared with the DACL of that file or folder. If the users list of SIDs in the access token don’t correspond to any ACEs the user will be explicit denied access.

If any ACEs correspond to any SID in the access token the access is evaluated in this order:

1. Explicit deny
2. Explicit allow
3. Inherited deny
4. Inherited allow

Object-Specific ACE:

Active Directory has an extra set of ACEs called Object-Specific ACEs. Object-Specific ACEs and Generic ACEs shares the same characteristics but the Object-Specific ACEs gives a higher level of granularity.

Object-Specific ACEs have the following types:

1. Object-Specific Deny ACE

‒ 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

2. Object-Specific Allow ACE

‒ 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

3. Object-Specific System-Audit ACE

‒ Log attempts to access a property or property set, or to limit inheritance to a specified type of child object

The Local Security Authority (LSA) evaluates the ACE list in the order of first looking for Explicit Deny or Allow ACEs. And second on Inherited Deny or Allow ACEs.

When a user tries to access an object in Active Directory the LSA gets the users’ access token. The security subsystem compares the users SID and Group SIDs and the objects DACLs with the underlying ACEs to evaluate an access denied or granted. If no match can be done with users access token it will implicit deny user access to the object.

If the user is granted access and modifies the Object in Active Directory the change can be audited and an event in the security log will be created.

And now to visualize all this information that we got I will show a few pictures and we start with the filesystem.

This is the classic security tab of a folder showing the ACL, DACL and ACEs

If we click the Advanced button we will get more options like inheritance:

And if you add or edit a Security Principal:

And last we have the SACL in the Auditing tab:

In Active Directory we got a lot of more options. The list is so big so I can’t get all of them in the same picture. But If I just show you how it looks in the advanced tab of an Organizational Unit in Active Directory you may get the point of all the extra Object-Specific ACEs.

The first is a list of all Objects you can set permission on and if you want that specific permission to be inherited down.

If you choose all descendant account objects you will see a list of all properties of user objects you could delegate control for a specific Security Principal.