(2008-03-26) Parsing SDDL Strings
Posted by Jorge on 2008-03-26
You probably know similar output like:
[RFSRWDC1] C:>SC SDSHOW NTDS
But, what the heck does it mean? SDDL parsing tool to the rescue!
[RFSRWDC1] C:>SDDLPARSE D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLORC;;;BO)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Ace count: 3
**** ACE 1 of 3 ****
ACE Type: ACCESS_ALLOWED_ACE_TYPE
Inheritance flags: 0
**** ACE 2 of 3 ****
ACE Type: ACCESS_ALLOWED_ACE_TYPE
Trustee: NT AUTHORITYSYSTEM
Inheritance flags: 0
**** ACE 3 of 3 ****
ACE Type: ACCESS_ALLOWED_ACE_TYPE
Trustee: BUILTINBackup Operators
Inheritance flags: 0
More info about SDDL strings can be found here.
The SDDL parse tool can be downloaded here.
A friend of mine, Willem Kasdorp, wrote a great piece of information about SDDLs. That information was copied from Mark Minasi’s newsletter Issue #44 February 2005 and can be found below. Credits for this information goes to Willem Kasdorp for writing the information and Mark Minasi for publishing it.
Decoding an SDDL string
Where did that SDDL string thing come from, anyway? Well, you need to understand it in order to create the CustomSD entry in the Registry. You’ll also need to understand SDDL strings if you want to use the DSACLS command-line tool to control Active Directory delegations, or to read or modify a security template. All of those things describe permissions in SDDL format. So here’s a basic tutorial on SDDL strings — it’s not complete, but it’ll get you started, make you able to understand most SDDL strings and points you to more references.
Anyone who’s been watching Windows security for the past few years has noticed that Microsoft doesn’t just put permissions on files and folders, it puts them everywhere. You control who’s affected by a group policy with GPO permissions. You control who can turn services on and off with service permissions. You delegate power within an AD with permissions. What kind of permissions a given object can have varies from object to object: for example, the "execute" permission would make sense on a file, but not on a user account, just as the "change password" permission that makes sense on a user account would be meaningless on a file. (And Microsoft doesn’t make things easier to understand when they make the "execute" permission for a file act as the "traverse folder" permission on a directory.)
Objects Have Security Descriptors
But no matter what the nature of the particular permissions are, all objects with permissions have the same four components — an owner, a primary group, a DACL and a SACL. Together, those four things are called the object’s "security descriptor."
You may be familiar with the notion of an owner, but in case you need a refresher, an object’s owner is an account that has one very great power: it can modify permissions on an object. If I were the owner of a file and you, an administrator, were to remove all of my permissions, so that I could not even read the object, then I could still reverse your action and give myself whatever permissions I wanted on that object.
Then there’s a primary group. Most of us are unaware and uncaring about the fact that objects have a primary group that they’re a member of, but that characteristic is there. In my experience it’s really only relevant if you’re running POSIX apps or setting up shares for Macintosh access, which is probably why most folks don’t know that primary groups exist.
DACLs and SACLs
Then there’s the DACL and the SACL, the Discretionary Access Control List and the System Access Control List. Right-click any file or folder on an NTFS-formatted drive and choose Properties, then Security, and you’ll see a list of people and/or groups that have varying levels of access to that file or folder. For example, I’ve got a file on my hard disk called acctinfo.dll, a file that comes with the Resource Kit. (It’s a file that adds information to Active Directory Users and Computers pages, but that’s a story for another day.) If I right-click on that file and choose Properties/Security then I get a dialog box labeled "acctinfo.dll Properties" with General, Version, Security and Summary tabs. If I click the Security tab, then I get a field "Group or user names:" atop a box that can contain one or more entries. On this file, however, there’s only one entry — Everyone, which refers to the Everyone group. Looking in the bottom part of the Security page, I see another section, "Permissions for Everyone" and it appears that Everyone has full control, and can do anything.
In short, I’m looking here at a list — again, a list with just one entry, but a list nonetheless — of permissions on this object. You’ve probably seen something like this before, and probably refer to it in the way that most of us in the Windows world do, as an "ACL," pronounced "ackel," which rhymes with "cackle." ACL means Access Control List and strictly speaking, the list of permissions itself is the ACL. Every entry in it is called an Access Control Entry or ACE. Most of us, however, would look at an access control list with a bunch of entries and say that the object has a "bunch of ACLs on it" or the like. To be precise, however, it’s more correct in Microsoft-ese to say that the entire list is an ACL that contains a number of ACEs. Again, this particular ACL has only a single ACE. For reasons known only to Microsoft, an ACL like this is called a "Discretionary" ACL, or DACL. It has that name to distinguish the DACL from another, optional, access control list, the System Access Control List or SACL.
Objects on your system have SACLs if you’ve enabled object auditing and want to audit some level of access to that particular object. To tell your system, "make a note of every time that Joe reads this item," then you must create an entry in the SACL (I’ve seen them called "AACEs" in some Microsoft literature, as opposed to a "PACE" in a DACL) to that effect. As I’ve not seen too many people actually use object auditing, I’ll skip most discussion of the SACL here.
There isn’t really a single place in the GUI that lets you examine and change all of the security descriptor, but you can see most of it from the Security tab when you click the Advanced button in the Security tab. That’ll give you a property page labeled "Advanced Security Settings for [whatever you’re looking at]." On that page are tabs labeled Permissions, Auditing, Owner, and Effective Permissions. (That last one first appeared in XP, so you won’t see it in 2000.) The Permissions tab lets you view and control the permissions — the DACL entries — on the object. The Auditing tab lets you control the SACL entries on the object. The Owner tab lets you view and change the owner. There’s no Primary Group tab.
Taken together, a security descriptor has a potentially-large amount of stuff in it. Most of us haven’t spent much time thinking about security descriptors until the past few years, though, because until a few years ago almost no one spent much time talking about Windows security, and Microsoft’s default security values in those days were pretty much Everyone/Full Control on just about everything. But now that Microsoft’s a bit more security-conscious, they needed a way to succinctly list everything in an object’s security descriptor. That’s what SDDL does. For example, acctinfo.dll’s SDDL is this:
That’s SDDL-ese for "this object is owned by the local administrator, has ‘local system’ as its primary group, and has granted full control to the Everyone group. It doesn’t have any auditing permissions." Clear as crystal, eh? Well, fear not, it will be, once you know the code.
SDDL strings include four items: the object’s owner, its primary group, its DACL and, if it has one, its SACL. The owner’s name is prefixed by "O:," the primary group’s name is prefixed by "G:," the DACL by "D:" and the SACL by "S:." There are no spaces, and the DACL and SACL are surrounded by parentheses. Referring to my earlier example,
The Owner and Primary Group
Start picking this apart at the O:, which tells us that the owner’s name follows. Keep reading until you see a G: — that’s the end. The owner part of the string, then, is "O:BA," which means that it’s owned by something called "BA." BA is one of a dozen or so pre-defined abbreviations for common accounts and groups; these abbreviations are called "SID strings." A few you’ll find useful are
- AO: account operators
- BA, the local ("Built-in") Administrators group
- DA: domain admins
- DU: domain users
- AU: authenticated users
- EA: enterprise admins
- WD: Everyone
- CG: Creator group
- CO: Creator Owner
- LA: local Administrator account
- SY: the local System account
You can find them all at http://msdn2.microsoft.com/en-us/library/aa379602.aspx or go to http://msdn.microsoft.com and search on "SID strings." This object’s owner, then, is the local Administrators group. You can also specify an actual SID if you don’t have a SID string for a particular account or group. If, for example, this object’s owner had the SID S-1-5-21-33-44-55-1002, then its SDDL string would look like
Next, we can see that its primary group is defined by "G:SY." As "SY" is the local System account, apparently that’s the file’s primary "group."
Cracking the DACL
Now we’re ready for the DACL, the file permissions. It’s the group surrounded by parentheses and starting with the D: prefix, "(A;;FA;;;WD)." That is called an "ACE string," as, recall, all access control lists are made up of access control entries, and (A;;FA;;;WD) is just one ACE. ACE strings have their own strange format, which you can find at http://msdn2.microsoft.com/en-us/library/aa374928.aspx or, if that URL doesn’t work any more, then just Google "ACE string" and "SDDL" and you should find it.
ACE strings have six parts, each separated by a semicolon. They are, in order:
- The first part describes the type of ACE — generally "allow" or "deny," in the case of files. This corresponds to the "allow" and "deny" check boxes that you see in the GUI for security permissions.
- If the object is a container, like a directory, then you may want to say whether this ACE applies to the container itself, or its contents. The second part lets you do this and is called the "ACE flags."
- The third part describes the exact permission conferred by this ACE — read, write, full control, that sort of thing.
- The fourth and fifth parts refer to the GUIDs of the object — first the object, then what inheritance if any this object gets. This appears unnecessary for file and directory operations and appears to only apply to Active Directory delegation, which is a particular form of permissions.
- The sixth part is the name of the account or group that’s getting this permission. It’s either a SID string or a SID in the standard S-1-whatever format.
Note that (A;;FA;;;WD) leaves a number of pieces empty; that’s why you see semicolons next to each other. The six pieces are, then,
- ACE type is "A."
- No ACE flags.
- The permission granted here is "FA."
- No object GUID.
- No object GUID inheritance information.
- The account that gets this permission is "WD."
Now let’s decode that. As the ACE Strings writeup that I referred to says, "A" means that this is an "allow" ACE. The permission "FA" means "all file access rights," which is another way of saying "full control." "WD" is the SID string for the "Everyone" group.
But I chose a pretty easy example — Everyone/Full Control is about as simple as it gets. But what about a somewhat more complex one? Suppose we change the permissions on my acctinfo.dll example to remove the Everyone/Full Control ACE and add two new ones. Let’s give Domain Administrators Full Control, and Domain Users only Read access. That leads to a SDDL string like this:
The O: and G: part hasn’t changed, but now notice two things. First, there are some letters right after the D: but before the parenthesized DACL, and, second, there are two parenthesized DACLs. The PARAI after D: are called DACL flags. They appeared after I changed acctinfo.dll’s permissions. You see, I’d wanted to remove the Everyone/Full Control permission, but it had been inherited from its parent folder. To get rid of it, I had to go into the Advanced Security dialog and un-check the box labeled "Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here." Apparently un-checking that causes the file system’s permissions to enable the three flags P, AR, and AI as defined at http://msdn2.microsoft.com/en-us/library/aa379570.aspx page.
Take a look at the first ACE string, (A;;FA;;;DA). It’s an "allow" ACE because of the "A," and it grants full control because of the "FA." It gives this permission to the Domain Admins group because "DA" is the SID string for the Domain Admins group. Similarly, the second ACE string is an "allow" ACE that grants full read permissions ("FR") to the Domain Users group ("DU.")
You can take the complexity and number of ACE strings as far as you like. Permissions are internally stored as sequences of bits, so if you need some very particular set of permissions then you can first figure out what sequence of bits corresponds to that set of permissions (which is a topic beyond the scope of this article), and then just use the hexadecimal equivalent value in the ACE string. For example, by turning on random sets of low-level permissions on the Domain Users ACE, I got a SID string of "(A;;0x1a00a4;;;DU)."
An SDDL Tool: Subinacl
But how did I create that last ugly ACE? I cheated: I used Subinacl. The version of Subinacl that came with Server 2003 and that you can download, as mentioned above, from Microsoft’s www.microsoft.com/download site. It works on 2000 Server, XP, or Server 2003. Subinacl lets you look at permissions on files, directories, user accounts, groups, cluster shares, Registry keys, services, processes, printers, kernel objects, and IIS metabase items. Subinacl can do many things, but it’s most basic function is the /display option. You can choose to display permission data in several formats, and one is "SDDL" format. I told Subinacl to show me the SDDL form of the file permissions for acctinfo.dll like so:
subinacl /file acctinfo.dll /display=sddl
Used in this way, Subinacl can make your SDDL learning curve a bit less steep. And yes, SDDL is an obscure "language," but we’ve got to be at least a bit familiar with it. (You might think of it as Microsoft’s 21st Century answer to that strange ARC language in boot.ini!)
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########