Access Control Lists (ACLs)
An ACL is a list of ACE. Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. The security descriptor for a Securable object can contain two types of ACLs:
A DACL identifies the trustees that are allowed or denied access to a securable object. When a process tries to access a securable object, the system checks the ACEs in the object's DACL to determine whether to grant access to it.
The system checks the ACEs in sequence until it finds one or more ACEs that allow all the requested access rights, or until any of the requested access rights are denied. However the following are not good terms regarding the DACL:
Each ACE specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log. An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both. In future releases, a SACL will also be able to raise an alarm when an unauthorized user attempts to gain access to an object. ACLs also provide access control to an Active Directory directory service objects. Active Directory Service Interfaces (ADSI) includes routines to create and modify the contents of these ACLs.
Access Control Entries (ACEs)
An ACE is an element in an ACL. An ACL can have zero or more ACEs. Each ACE controls or monitors access to an object by a specified trustee. There are six types of ACEs, three of which are supported by all securable objects. The other three types are Object-specific ACEs supported by directory service objects. All types of ACEs contain the following access control information:
The following table lists the three ACE types supported by all securable objects.
Type |
Description |
Access-denied ACE |
Used in a DACL to deny access rights to a trustee. |
Access-allowed ACE |
Used in a DACL to allow access rights to a trustee. |
System-audit ACE |
Used in a SACL to generate an audit record when the trustee attempts to exercise the specified access rights. |
Table 6 |
Object-specific ACEs
Object-specific ACEs are supported for directory service (DS) objects. An object-specific ACE contains a pair of globally unique identifiers (GUIDs) that expand the ways in which the ACE can protect an object.
GUID |
Description |
ObjectType |
Identifies one of the following:
|
InheritedObjectType |
Indicates the type of child object that can inherit the ACE. Inheritance is also controlled by the inheritance flags in the ACE_HEADER, as well as by any protection against inheritance placed on the child objects. |
Table 7 |
Three types of object-specific ACEs are supported. System-alarm object ACEs are not currently supported.
Type |
Description |
Access-denied object ACE |
Used in a DACL to deny a trustee access to a property or property set on the object, or to limit ACE inheritance to a specified type of child object. Uses the ACCESS_DENIED_OBJECT_ACE structure. |
Access-allowed object ACE |
Used in a DACL to allow a trustee access to a property or property set on the object, or to limit ACE inheritance to a specified type of child object. Uses the ACCESS_ALLOWED_OBJECT_ACE structure. |
System-audit object ACE |
Used in a SACL to log a trustee's attempts to access a property or property set on the object, or to limit ACE inheritance to a specified type of child object. Uses the SYSTEM_AUDIT_OBJECT_ACE structure. |
Table 8. |
Any ACL that contains an object-specific ACE must use the revision ACL_REVISION_DS.
Trustees
A trustee is the user account, group account, or logon session to which an ACE applies. Each ACE in an ACL has one SID that identifies a trustee. User accounts include accounts that human users or programs such as Windows Services use to log on to the local computer. Group accounts cannot be used to log on to a computer, but they are useful in ACEs to allow or deny a set of access rights to one or more user accounts. A logon SID that identifies the current logon session is useful to allow or deny access rights only until the user logs off. A logon SID is a SID that identifies a logon session. You can use the logon SID in a DACL to control access during a logon session. A logon SID is valid until the user logs off. A logon SID is unique while the computer is running; no other logon session will have the same logon SID. However, the set of possible logon SIDs is reset when the computer starts up. To retrieve the logon SID from an access token, call the GetTokenInformation() function for TokenGroups. The access control functions use the TRUSTEE structure to identify a trustee. The TRUSTEE structure enables you to use a name string or a SID to identify a trustee. If you use a name, the functions that create an ACE from the TRUSTEE structure perform the task of allocating the SID buffers and looking up the SID that corresponds to the account name. There are two helper functions, BuildTrusteeWithSid() and BuildTrusteeWithName(), that initialize a TRUSTEE structure with a specified SID or name. BuildTrusteeWithObjectsAndSid() and BuildTrusteeWithObjectsAndName() allow you to initialize a TRUSTEE structure with object-specific ACE information. Three other helper functions, GetTrusteeForm(), GetTrusteeName(), and GetTrusteeType(), retrieve the values of the various members of a TRUSTEE structure. The ptstrName member of the TRUSTEE structure can be a pointer to an OBJECTS_AND_NAME or OBJECTS_AND_SID structure. These structures specify information about an object-specific ACE in addition to a trustee name or SID. This enables functions such as SetEntriesInAcl() and GetExplicitEntriesFromAcl() to store object-specific ACE information in the Trustee member of the EXPLICIT_ACCESS structure.