First things first; this string of characters is known as Microsoft’s Security Descriptor Definition Language (SDDL). It is used for Access Control Entries (ACEs) in Access Control Lists (ACLs). These ACLs control access to registry keys, files & folders, and of course Active Directory objects. Since this series is about auditing AD we will focus on SDDL in that context.

Microsoft describes SDDL as:

“The security descriptor definition language (SDDL) defines the string format that the ConvertSecurityDescriptorToStringSecurityDescriptor and ConvertStringSecurityDescriptorToSecurityDescriptor functions use to describe a security descriptor as a text string. The language also defines string elements for describing information in the components of a security descriptor.”

What is SDDL and why should I even care?

Short answer; it’s the old, pre PowerShell way of enumerating ACLs.

Long answer; Microsoft introduced SDDL back in Windows 2000. PowerShell wasn’t introduced until 2006, so enumerating, auditing, or being able to just actually read ACLs was a lot rougher back then. In 2022 there’s not much reason to bother with SDDL. If you really want to see it then just query:

Get-Acl (Get-ADDomain).DistinguishedName | Select-Object SDDL | Format-List

(Get-Acl (Get-ADDomain).DistinguishedName).sddl

How to read SDDL

The best way is with an example. Our sample ACE in the ACL of the domain root is, from this vendor’s question:

(A;CI;RPWDLCLO;;;WD)

So let’s break this down.

A = Allow (ACE type)

CI = Container Inherit (means child CNs inherit as an explicit ACE)

RP = Read Property, WD = Modify Permissions, LC = List Contents, LO = List Object (list of privileges granted by this ACE)

;;; = no ObjectType or Inherited Object Type specified, essentially the same thing as ObjectType set to all 0s in PowerShell

WD = SDDL_EVERYONE, aka ‘Everyone’ in AD

Therefore, (A;CI;RPWDLCLO;;;WD) gives Everyone ‘Modify Permissions’ or WriteDACL in PowerShell parlance. It also gives them ReadProperty, ListChildren, & ListObject. The WriteDACL though is obviously very bad for security. It means that any Domain User could change the ACL on the domain root, give themselves the rights required to execute DCSync, pull the krbtgt hash, and start forging tickets.

That’s it, that’s the answer to this vendor’s question.

SDDL vs PowerShell’s method

As a comparison, pull the SDDL as mentioned above:

(Get-Acl (Get-ADDomain).DistinguishedName).sddl

You can copy/paste the entire ugly thing into Notepad and Ctrl + F ‘WD)’ to see any ACEs that apply to Everyone. You will see (D;;DC;;;WD) & (A;;RP;;;WD), which means Deny DeleteChild & Allow ReadProperty

Or if you prefer to get human readable output immediately and not Google up a cheatsheet for SDDL, just query

(Get-Acl (Get-ADDomain).DistinguishedName).Access | Where {$_.IdentityReference -like “*Everyone*”}

All you have to do is remember that if the ObjectType is set to all 0s it means all Properties. Simple, easy, legible.

Cheatsheet for SDDL

There are 6 fields in an ACE in SDDL:

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

The ACE type are:

The ACE flags are:

The ACE permissions are:

Please note that while not technically the same thing, GenericWrite and WriteProperty with ObjectType 00000000-0000-0000-0000-000000000000 will essentially grant the same rights.

Please note that PowerShell easily supports the ability to give only specified Extended Rights and writing to only specified AD attributes via specifying ObjectTypes. Just use the handy cheatsheet at http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm and Ctrl + F.

For example, below we see that a user has been given only the two Extended Rights required to execute DCSync.

Trustee (SID):

Summary

I found snippets of info from several different sources on Google and put it together to enumerate ACLs in SDDL. I didn’t see a table mapping SDDL to GUI to PowerShell rights anywhere, so I put one together using Microsoft documentation.

SDDL information is not all that hard to find once you know what you are looking for. It is simply outdated and not readily legible, nor is it simple to query.

Caveat

However I would not doubt that some attackers out there are using SDDL in their tools to run queries. After all, as Will Shroeder, Andy Robbins, and Lee Christensen so aptly stated:

“As an offensive researcher, if you can dream it, someone has likely already done it … and that someone isn’t the kind of person who speaks at security cons [conferences].”

Hence it is something to be aware of. More knowledge is always good.

SDDL is also still used in a few acrane places in Windows, for example logs as seen here.

By the way, if you copy/paste the SDDL the vendor listed here into

ConvertFrom-SddlString -Sddl $SDDL -Type ActiveDirectoryRights

You’ll get an error, probably because it doesn’t start with the owner.

Huh, that’s exactly why.

Maybe they didn’t want you to consider the impact of ownership on their examples.

If you need to query who can ‘Modify Permissions’ in GUI terminology or WriteDACL in PowerShell’s terms on the domain root, then just:

(Get-Acl ‘dc=corp,dc=local’).Access | Where {($_.ActiveDirectoryRights -like “*WriteDACL*”) -and ($_.AccessControlType -eq “Allow”)}

It really is that simple. You don’t need to dig up info on arcane SDDL from Windows 2000 to see who has privileges in AD.

References:

https://www.cyber-security-blog.com/2020/01/who-needs-wmds-today.html

https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-definition-language

https://clan8blog.wordpress.com/2016/08/08/sddl-explained/

https://web.archive.org/web/20150810083345/http://networkadminkb.com/KB/a152/how-to-read-a-sddl-string.aspx

https://blogs.msmvps.com/alunj/2006/02/13/sddl-easier-to-read-except-when-its-not/

https://docs.microsoft.com/en-us/dotnet/api/system.directoryservices.activedirectoryrights?view=dotnet-plat-ext-6.0

http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/20504d60-43ec-458f-bc7a-754eb64446df

https://www.varonis.com/blog/the-difference-between-everyone-and-authenticated-users

https://zflemingg1.gitbook.io/undergrad-tutorials/privilege-escalation/privilege-escalation

https://devblogs.microsoft.com/oldnewthing/20220510-00/?p=106640

SDDL, what is it, does it matter?

Written by Rich