다음을 통해 공유

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

Comments

  • Anonymous
    April 21, 2008
    PingBack from http://www.ditii.com/2008/04/20/defining-the-security-descriptor-definition-language-part-1/

  • Anonymous
    May 07, 2008
    Hi. Jim here from DS here with a follow up to my SDDL blog part I. At the end of my last post I promised

  • Anonymous
    August 12, 2008
    Mike here again. Today I’m focusing on policy settings for the Event Logging Service. For clarity, these

  • Anonymous
    September 25, 2008
    В прошлом выпуске я рассказал, как строится строка SDDL, так что мы теперь можем что-то прочитать на...

  • Anonymous
    April 03, 2009
    Hi Jim. Great article(s). What does the GUID part of the ACE do? When looking at some objects from my DS I see for example: (OA;;CCDC;bf967a86-0de6-11d0-a285-00aa003049e2;;AO) (This is from the defaultSecurityDescriptor attribute on the Organizational-Unit object in the Schema partition). Also on W2K8 OUs are always created with and ACE for Everyone that denies DELETE and DELETE TREE, but I cannot find those in the defaultSecurityDescriptor. Where do they come from? Thanks. Morgan

  • Anonymous
    April 03, 2009
    Hey Morgan, Thanks for your question. The ObjectType 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 GUID string uses the format returned by the UuidToString function - http://msdn.microsoft.com/en-us/library/aa379352(VS.85).aspx The GUID in your example "BF967A86-0DE6-11D0-A285-00AA003049E2" is the "Schema-Id-Guid" for the Computer class of objects.  The OA indicates - Object Access Allowed which applies to a subset of objects.  The AO indicates this access is granted to "Account Operators". I will get back to you next week on the W2K8 OU question. Jim

  • Anonymous
    April 06, 2009
    The comment has been removed

  • Anonymous
    May 16, 2009
    Nice information on where the information is stored in the registry and how it relates to the tools we use.  I also found the following articles very useful for deciphering the SDDL format and how to use it for administrative purposes.  All you need to know is GR,GW,GA, and GX to grant access rights. http://networkadminkb.com/Shared%20Documents/Understanding%20the%20SDDL%20permissions%20in%20the%20ACE_String.aspx http://networkadminkb.com/kb/Knowledge%20Base/Windows2003/How%20to%20Read%20a%20SDDL%20String.aspx