SDDL

Security Descriptor Definition language (SDDL) is a language used for defining the NT Security Descriptor attribute and has been traditionally used to define ACL in windows registry and other NTFS Files. Most of the time the one is not required to understand the cryptic syntax of SDDL as it is manipulated using MMC interface. The syntax was little productive for the power users who may like to manipulate the windows registry using text editor.

However, an understanding of SDDL, gains significance in context to ACL Security Configuration for WCF. The SDDL settings need to used along with httpcfg tool available under Windows Server 2003. For Windows Vista we use alternative new tool called netsh. A discussion about these tools and ACL Security Configuration for WCF is available under a separate article here. This article focuses on SDDL and its various components.

 

Before discussing the SDDL string syntax, let us first have a quick list of what is is an Access control list (ACL).

 

What is an ACL

 

An Access control list (ACL) is a list of Access control entries (ACE). Each ACE defines a trustee and an associated access right – allowed, denied or audited. There are used in two ways in windows security. One is used as a access gate while the other acts as an audit.

DACL (Discretionary Access Control List)

DACL acts the access gate. It describes access right for a trustee in terms of allowed or denied. When a system tries to access a securable object, it tries to check its DACL to decide weather to grant access or not. The system works in the following manner:

  • If their is no DACL; everyone is granted full access.
  • If DACL has not ACE; everyone is denied all access.
  • In other cases ACE list is checked to determine the kind of access allowed or disallowed.
  • For a complete discussion refer How DACLs Control Access to an Object .

SACL (System Access Control List)

SACL acts as an audit for the administrators. It is used for logging attempts to access the secured object. Each ACE in this list defines the type of access attempt by a trustee that causes the system to generate log in security event log. An ACE can generate log for systems attempts – failed, succeeded or both.

 

Format of the Security Descriptor String

 

Each of the SDDL security descriptor string is composed of primarily 5 parts. These parts correspond to these basic headers:

  • Owner sid (O:)
    • Format:  O:<owner_sid>
  • Group sid (G:)
    • Format: G:<group_sid>
  • DACL (D:)
    • Format:  D:(ace_string1)(ace_string2)…
  • SACL (S:)
    • Format: S:(ace_string1)(ace_string2)…
  • Control Information
    • Defines weather the object is blocking the inheritance for SACL and DACL. Possible values include
    • SE_DACL_PROTECTED
    • SE_SACL_PROTECTED

 

//Control information is defined as follows

// excerpt from winnt.h

#define OBJECT_INHERIT_ACE (0x1)

#define CONTAINER_INHERIT_ACE (0x2)

#define INHERIT_ONLY_ACE (0x8)

 

 

The contents of both the primary group and owner parts are simply a single Security IDs. The contents of both the SACL and DACL parts are a string with no fixed length. ACEs make up the contents of these strings. ACEs are enclosed within parenthesis, and there are 6 fields in each ACE. These 6 fields (O,G,D,S and two flags) are separated by a semicolon delimiter. The fields are

  • ACE type (allow/deny/audit),
  • ACE flags (inheritance and audit settings),
  • Permissions (list of incremental permissions),
  • ObjectType (GUID),
  • Inherited Object Type (GUID), and
  • Trustee (SID).

 

ACE Type

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

 

Value Description
“A” ACCESS ALLOWED
“D” ACCESS DENIED
“OA” OBJECT ACCESS ALLOWED: ONLY APPLIES TO A SUBSET OF THE OBJECT(S).
“OD” OBJECT ACCESS DENIED: ONLY APPLIES TO A SUBSET OF THE OBJECT(S).
“AU” SYSTEM AUDIT
“AL” SYSTEM ALARM
“OU” OBJECT SYSTEM AUDIT
“OL” OBJECT SYSTEM ALARM

 

ACE Flags

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

 

Value Description
“CI” CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
“OI” OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
“NP” NO PROPAGATE: ONLY IMMEDIATE CHILDREN INHERIT THIS ACE.
“IO” INHERITANCE ONLY: ACE DOESN’T APPLY TO THIS OBJECT, BUT MAY AFFECT CHILDREN VIA INHERITANCE.
“ID” ACE IS INHERITED
“SA” SUCCESSFUL ACCESS AUDIT
“FA” FAILED ACCESS AUDIT

 

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.

 

Value Description
Generic access rights
“GA” GENERIC ALL
“GR” GENERIC READ
“GW” GENERIC WRITE
“GX” GENERIC EXECUTE
Directory service access rights
“RC” Read Permissions
“SD” Delete
“WD” Modify Permissions
“WO” Modify Owner
“RP” Read All Properties
“WP” Write All Properties
“CC” Create All Child Objects
“DC” Delete All Child Objects
“LC” List Contents
“SW” All Validated Writes
“LO” List Object
“DT” Delete Subtree
“CR” All Extended Rights
File access rights
“FA” FILE ALL ACCESS
“FR” FILE GENERIC READ
“FW” FILE GENERIC WRITE
“FX” FILE GENERIC EXECUTE
Registry key access rights
“KA” KEY ALL ACCESS
“KR” KEY READ
“KW” KEY WRITE
“KX” KEY EXECUTE

 

Object Type and Inherited Object Type

The Object Type is a GUID representing an object class, attribute, attribute set, or extended right. If present it limits the ACE to the object the GUID represents. The Inherited Object Type is a GUID representing an object class. If present it limits inheritance of the ACE to the child entries of only that object class.

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:

 

Value Description
“AO” Account operators
“RU” Alias to allow previous Windows 2000
“AN” Anonymous logon
“AU” Authenticated users
“BA” Built-in administrators
“BG” Built-in guests
“BO” Backup operators
“BU” Built-in users
“CA” Certificate server administrators
“CG” Creator group
“CO” Creator owner
“DA” Domain administrators
“DC” Domain computers
“DD” Domain controllers
“DG” Domain guests
“DU” Domain users
“EA” Enterprise administrators
“ED” Enterprise domain controllers
“WD” Everyone
“PA” Group Policy administrators
“IU” Interactively logged-on user
“LA” Local administrator
“LG” Local guest
“LS” Local service account
“SY” Local system
“NU” Network logon user
“NO” Network configuration operators
“NS” Network service account
“PO” Printer operators
“PS” Personal self
“PU” Power users
“RS” RAS servers group
“RD” Terminal server users
“RE” Replicator
“RC” Restricted code
“SA” Schema administrators
“SO” Server operators
“SU” Service logon user

 

I don’t intend to discuss the detailed meaning of each of these enumeration which can be referred at msdn website under the heading Authorization Structures

Leave a Reply

Your email address will not be published. Required fields are marked *