I use the Security Configuration Manager (SCM) regularly to refresh my company's user workstation security settings. Recently, the company decided to add file-system access control settings to our SCM workstation template. (I use the Microsoft Management Console—MMC—Security Templates snap-in to administer the SCM workstation template.) When I view the template in Notepad, I can read all security settings except the file-system and registry access control settings, which seem to be encoded. How can I decode them?
To encode the access control settings in the SCM templates, Microsoft uses the Security Descriptor Definition Language (SDDL). Microsoft developed this special-purpose language to represent Security Descriptor components—such as the system ACL (SACL), the discretionary ACL (DACL), the object owner, and the primary group—in text files. In the context of the SCM, SDDL is used to describe registry and file-system DACLs. For a detailed explanation of the SDDL syntax, go to the Microsoft Developer Network (MSDN) Library at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ security/Security_security_descriptor_string_format.asp.
An SCM file-system or registry DACL entry has the following format:
"\[DACL in SDDL format\]"
The entry begins with a description of the object to which the entry applies. For a file-system object, the description contains the object's name and file-system path; for a registry object, the description contains the registry subkey. Next, you see the SCM flag, which determines whether the SCM will apply the security setting defined in the entry the next time the SCM uses the template to execute a security configuration or analysis. Then, you see the DACL, encoded in the SDDL format. The full format of the SDDL-encoded DACL is
\[ACE Mask\];;;\[Security Principal\])"...
where D represents the SDDL type. A set of DACL Flags follows the DACL's SDDL type. For example, a P would indicate that the SE_DACL_PROTECTED flag is set. This flag's purpose is to protect a DACL from the effects of inherited parent object access control settings.
One or more access control entries (ACEs) follow the DACL flags. Each SDDL ACE contains several fields:
- The first field contains the ACE type: allow or deny. An allow ACE is represented by an A, and a deny ACE by a D.
- The second field contains the ACE flags. For example, a set of ACE flags might be CI, indicating that only subcontainers inherit the object's ACE, or CIOI, indicating that both subcontainers and subobjects inherit the object's ACE.
- The third and most complex field contains the ACE mask. The field can contain a hexadecimal representation of the access rights or a concatenation of different predefined two-character access right strings. GA, for example, represents GENERIC_ALL (full control access); GR represents GENERIC_READ (read access); GW represents GENERIC_WRITE (write access); and GX represents GENERIC_EXECUTE (execute access).
- The fourth and fifth fields are empty because they aren't used in the context of the SCM. These fields represent the object globally unique identifier (GUID) and the inherited object GUID.
- The sixth field represents the security principal to which the ACE applies. To represent the built-in NT groups, Microsoft uses a set of predefined two-character strings. For example, AU stands for the Authenticated Users group and CO stands for the Creator Owner group. Microsoft uses SIDs to represent other security principals.
The following SCM template entry
indicates that the file-system security settings defined in the entry apply to the securedfile.doc file-system object, located on the C drive. The 2 indicates that SCM will apply the security setting defined in the entry the next time the SCM executes a security configuration or analysis by using this template. In the SDDL-encoded security descriptor, D indicates a DACL and P indicates that the SE_DACL_PROTECTED DACL flag is set. In the ACE (A;CIOI;GRGW;;;PU), A indicates that the ACE is an allow ACE. CIOI represents the ACE flags that indicate all subcontainers and subobjects of the object inherit the ACE. GRGW indicates that the security principal has read and write access to the object. And PU indicates that this ACE applies to the built-in Power Users group.