Some advanced uses for security templates
Since the release of Windows 2000, Microsoft has touted security templates as the best solution for automating and enforcing a consistent security policy. Microsoft has released sample security templates for various server roles, such as Web servers and domain controllers (DCs). Other parties, including the National Security Agency (NSA) and National Institute of Standards and Technology (NIST), have published similar templates. Although these templates are good, the full power of security templates remains largely untapped. In particular, file-system and registry security continues to be a largely misunderstood and underused portion of security templates. File-system and registry security plays such a vital role in Web server security that exploring how to read security templates and how to use them to selectively set permissions is well worth the time.
Security templates are text files that drive the implementation of a local or domain security policy. Security templates are a subset of Group Policy, so you can deploy security templates on standalone servers or distribute them as an organizational unit (OU) policy. The safest way to edit security templates is to use the Microsoft Management Console (MMC) Security Templates snap-in, but you can also use any text editor. Because the snap-in is somewhat quirky and inconsistent, I used a text editor to directly modify the security templates for all the examples in this article.
This article assumes you have some knowledge of security templates and a template with which to work. If you don't have a basic template, I recommend that you download Microsoft's security templates (http://download.microsoft.com/download/win2000srv/scm/1.0/nt5/en-us/hisecweb.exe) or NSA's security templates (http://nsa1.www.conxion.com/win2k/download.htm). If you're unfamiliar with security template basics, I recommend that you read Paula Sharick's January 2002 Web-exclusive sidebar "Building a Custom Security Template" (http://www.secadministrator.com, InstantDoc ID 23082).
How to Read Security Templates
If you open the basicws.inf security template that resides in the \%systemroot%\security\templates directory and scroll to the bottom, you'll see a long list of entries such as
"c:\boot.ini",2,"D:P(A;;GRGX;;;PU)
(A;;GA;;;BA)(A;;GA;;;SY)"
(In the basicws.inf file, this entry would be on one line.) This part of the security template sets file-system security. For example, the sample entry I just gave sets permissions for the C:\boot.ini file.
The entries in the file-system security section consist of three parameters. The first parameter is the pathname (e.g., C:\boot.ini). The second parameter (e.g., 2) specifies how you want the Security Configuration Editor (SCE) to propagate the file's ACL. The possible values for the second parameter correspond to the options in the Template Security Policy Setting dialog box, which Figure 1 shows. The values are
- 0—corresponds to the Propagate inheritable permissions to all subfolders and files option
- 1—corresponds to the Do not allow permissions on this file or folder to be replaced option
- 2—corresponds to the Replace existing permissions on all subfolders and files with inheritable permissions option
Most often, you'll use the value of 2.
The last parameter—e.g., "D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"—is a discretionary ACL (DACL) of a Security Descriptor (SD). This cryptic string uses the Security Descriptor Definition Language (SDDL) to specify the DACL in text format, which provides for easy storage of the SD. Although the DACL string might look confusing, with a little practice, you'll find that using this string to set permissions is much easier and more direct than using dialog boxes.
The basic format for a DACL string is D:DACL Flag(ACE Type;ACE Flags;Rights;Object GUID;Inherit Object GUID;Account SID). The string starts with D:, which specifies that you're setting a DACL. The value that follows D: is the DACL flag, which you use to specify whether you want to allow or protect against inheritable permissions. In the sample DACL string, the DACL flag is P, which denotes that you want to protect the DACL against modification by inherited access control entries (ACEs). Web Table 1 (http://www.windowswebsolutions.com, InstantDoc ID 25576) shows the values for the other two DACL flags that you can use.
After the DACL flag is a series of fields enclosed by parentheses. The information in these fields makes up an ACE. Notice that the sample DACL string has three sets of parentheses. Each set represents an ACE, so this boot.ini file has three ACEs.
Inside each set of parentheses, you can include up to six optional fields. The first field is ACE Type. As Web Table 2 shows, the commonly used ACE types include those that allow access to the DACL, deny access to the DACL, and enable auditing. In the sample DACL string, all three ACEs allow access, denoted by the A parameter.
You use the ACE Flag field to specify inheritance or auditing options. Web Table 3 shows a few of the possible values you can use. In the sample DACL string, the ACE Flag field is blank in all three ACEs because the DACL is protected against inheritable ACEs and auditing isn't enabled.
The Rights field assigns access rights to the ACE. Microsoft classifies the available rights into five categories: Directory Service (DS) access, file access, generic access, registry key access, and standard access. Web Table 4 shows the rights in the file access, generic access, and registry key access categories. In the sample DACL string, the first ACE has Generic Read and Generic Execute rights and the other two ACEs have Generic All rights.
If an ACE is object-specific, you can use the Object GUID and Inherit Object GUID fields to specify the object's globally unique identifier (GUID) and inherited object GUID, respectively. In the sample DACL string, these fields are empty in all three ACEs because the ACEs aren't object-specific.