The Security Descriptor Definition Language of Love (Part 1)

Hi. Jim from DS here to tell you more than you ever wanted to know about the Security Descriptor Definition Language (SDDL). Windows uses SDDL in the nTSecurityDescriptor. The SDDL defines string elements for enumerating information contained in the security descriptor. You may want to grab some coffee now.

Before we explain SDDL , let me explain what SDDL describes – a security descriptor. A security descriptor is a binary data structure of changeable length that contains security information associated with a protected (securable) object. This includes information about the object’s owner and who can access the object and in what way. The security descriptor also includes information on how access to the object is audited . Windows uses security descriptors to control access to resources. Examples of resources to which security descriptors apply are files, folders, registry keys, network shares, printers and Active Directory objects like OU’s and DNS zones.

A security descriptor contains two access control list’s (ACL) for each resource, Discretionary Access Control List (DACL) and System Access Control List (SACL). An ACL is a list of ordered Access Control Entries (ACE) that specify allowed, denied or audited access rights. The DACL identifies users and groups who are allowed or denied access to an object and in what way the object is accessed. The SACL defines how access is audited on an object.

What we are talking about here at the core is permissions and auditing. Each permission for a securable object granted to a user or group is stored as an ACE within a DACL that is a part of…

You guessed it! The security descriptor. Can you feel the love? Try to contain your excitement as we press onward.

The access token is linked to the security descriptor. An access token contains security information about an authenticated user. Windows performs an access check when a user or service attempts to access a resource. During the access check, Windows compares the access token of the requesting account to the objects DACL. This bit of wonderment is discussed in great detail here - https://blogs.technet.com/askds/archive/2007/11/02/what-s-in-a-token.aspx

If auditing is enabled for an object, the objects Security Descriptor will also contain a SACL that controls how attempts to access the object are tracked by the security subsystem.

Just for fun let’s view the security descriptor for shares on a server by traversing the registry. The following screen shot illustrates the security descriptor on a share named Tools as REG_BINARY data on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSEt\Services\lanmanserver\Shares\Security key of a 2003 DC. This key contains all the information I spoke about earlier (DACL, SACL, etc.) Good luck deciphering that data format.

clip_image002

Of course you are all familiar with the GUI representation of the security descriptor as shown in the following screenshot of the very same TOOLS share.

clip_image004

Auditing Tab

clip_image006

Now that you understand what a Security Descriptor “is”, we can explore the language used to describe what the security descriptor contains. This language is useful for developers and administrators alike to understand and utilize the administrative functionality as well as the portability of the security descriptor.

It is possible to use the SDDL to simplify some administrative tasks in regard to setting ACL’s on objects. What follows is a cursory overview on what can be contained in an nTSecurityDescriptor SDDL string. Here is an example of a SDDL string extracted from the aforementioned TOOLS share:

O:BAG:SYD:PAI(D;OICI;FA;;;BG)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BU)S:AI(AU;OICINPFA;RPDTSDWD;;;BU)(AU;OICINPSA;CCSWRPDTLOSD;;;BU)

Each nTSecurityDescriptor SDDL string is composed of 5 parts which correspond to:

The Header - The header contains flags that designate whether the object is allowing or blocking inheritance for the SACL and DACL. If inheritance is allowed, permissions flow down from a parent object. If inheritance is blocked the permissions do not flow down from a parent container or object.

DACL (D:) – The Discretionary Access Control List denoted by the (D:)

SACL (S:) – The System Access Control List denoted by the (S:)

Primary Group (G:) – This value is still in the security descriptor for compatibility reasons. Windows 2000/2003 does not rely on this part of the security descriptor unless you are using services for UNIX and/or Macintosh with tools and utilities applying thereto.

Owner (O:) – Indicates which trustee owns the object. A trustee is the user account, group account, or logon session to which an access control entry (ACE) applies. Each ACE in an access control list (ACL) has one security identifier (SID, also called a principal) that identifies a trustee. The value is represented in SID string format. A security identifier (SID) identifies a user, a group, or a logon session. Each user has a unique SID, which is retrieved by the operating system at logon.

SIDs are issued by an authority such as the operating system or a domain server. Some SIDs are well-known and have names as well as identifiers. For example, the SID S-1-1-0 identifies Everyone (or World).

The contents of both the primary group and owner parts are a single SID. The contents of both the SACL and DACL parts are a string with varying length. ACE’s are contained within these strings.

ACE’s are enclosed within parenthesis. There are 6 fields in each ACE. These 6 fields are separated by a semicolon delimiter.

The fields are as follows:

ACE type (allow/deny/audit)

ACE flags (inheritance and audit settings)

Permissions (list of incremental permissions)

ObjectType (GUID)

Inherited Object Type (GUID)

Trustee (SID)

By using CACLS you see below in SDDL format the security descriptor for the ACL’s on the very same Tools share:

clip_image008

Here is the output exported to a .txt file:

"D:PAI(D;OICI;FA;;;BG)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BU)"

In part II of my SDDL Blog series I will dissect the SDDL format in the previous extraction and from other securable objects to further explain the descriptor language and its usefulness.

- Jim Tierney