Windows uses Security Descriptor Definition Language (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 - http://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.

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.

Auditing Tab

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:

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.

This section will dissect the SDDL output returned by running the CACLS with the /S switch on tools share as follows:

Here is the output exported to a .txt file:

"D:AI(D;OICI;FA;;;BG)(A;;FA;;;BA)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;SY)(A;OICIIOID;GA;;;CO)(A;OICIID;0x1200a9;;;BU)(A;CIID;LC;;;BU)(A;CIID;DC;;;BU)"

Let’s examine the first segment more closely: "D:AI(D;OICI;FA;;;BG)(A;;FA;;;BA)

Now the second ACE segment: (A;:FA;;;BA)

You get the picture. There is a chart provided at the end which contains all the acronyms in addition to the ones illustrated in this output.

At this point you may be asking why there are there two different ACE entries for Built-in Administrators. The first ACE indicates the ACE applied directly to the object (In this case TOOLS for the BA’s). The second ACE indicates the ACE’s for this object that flow down from TOOLS via inheritance.

This is illustrated in the Permissions tab of Advanced Security Settings for the TOOLS share:

Now you may well be wondering “Jim, how can I use this SDDL wonderment to make my administrative tasks less tedious?"

Well here is an example on how you can do just that.

Scenario: Its Friday at 3pm. You have to deploy 10 printers to the call center. Every single printer should have the exact same security settings for access (oversimplified yes, but you get the point). You need to get this done expediently so as not to miss happy hour. All the printers are IP’d and are installed on your print server. You have applied the necessary security on one printer as follows:

Using the SETPRINTER utility you can view the security applied in SDDL format as follows:

Here is the command as well as the output:

C:\>setprinter -show \\2003dom-member\printer1 3

pSecurityDescriptor="O:BAG:DUD:(A;;LCSWSDRCWDWO;;;BA)(A;OIIO;RPWPSDRCWDWO;;;BA)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2604)(A;CIIO;RC;;;CO)(A;OIIO;RPWPSDRCWDWO;;;CO)(A;CIIO;RC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;OIIO;RPWPSDRCWDWO;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;LCSWSDRCWDWO;;;PU)(A;OIIO;RPWPSDRCWDWO;;;PU)"

Now create yourself a .CMD file containing the following parameters remembering of course to substitute your Print server name and your printer names where indicated. Also be sure NOT to wrap your SDDL parameters as below. This is done here purely for readability. The entire command should be on one line: 

You may add as many similarly configured printers as you like.

Included below are charts for the acronyms of the SDDL taken directly from MSDN2. These can also be viewed here:

http://msdn2.microsoft.com/en-us/library/aa374928.aspx

ACE Type

The ACE type designates whether the trustee is allowed, denied or audited.

INHERITANCE Flags

ACE Flags The ACE flags denote the inheritance options for the ACE, and if it is a SACL, the audit settings.

Permissions

The Permissions are a list of the incremental permissions given (or denied/audited) to the trustee-these correspond to the permissions discussed earlier and are simply appended together. However, the incremental permissions are not the only permissions available. The table below lists all the permissions. 

Object Type and Inherited Object Type 
Trustee The Trustee is the SID of the user or group being given access (or denied or audited). Instead of a SID, there are several commonly used acronyms for well-known SIDs. These are listed in the table below:

I hope you have found this entertaining and informative!

-       

The ObjectType is a GUID that Identifies a type of child object, a property or property set or an extended right.  If present it limits the ACE to the object the GUID represents.  For a more verbose explanation of this please visit the following link - 

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsce_ctl_iunu.mspx?mfr=true

Inherited Object Type contains a GUID that identifies the type of child object that can inherit the ACE. Inheritance is also controlled by the ACE's Inheritance Flags and by any protection against inheritance placed on the child object in its Security Descriptor Control Flags.