Securing client operating systems

The following excerpt, courtesy of APress, is from Chapter 4 of the book "Active Directory Field Guide" written by Laura E. Hunter. Click for the complete book excerpt series or purchase the book.

Securing Client Operating Systems

Another useful item in the Group Policy bag of tricks is that you can use it to create a standard security configuration across your entire network, without needing to visit individual machines to repeatedly perform the same configuration. (We all know how tedious that is, not to mention error-prone.) By using security templates, you can create a security policy for your entire network or for a smaller group of similarly configured computers. You can do this using one of the predefined security templates included in the Windows 2000 or 2003 OS, or you can modify one of these templates or even create a brand new one containing the specific security settings that you need. Security templates can be used to define the following components:

Account policies

Password policies

Account lockout policies

Kerberos policies

Local policies

Audit policies

User rights assignments

Security options

Event log settings

Restricted groups settings

System services: startup modes and permissions

Registry key permissions

File and folder permissions

In this section, we'll look at the steps for implementing security templates on an Active Directory network. The process begins with analyzing the current security settings on various machines on your network, creating or modifying a security template containing your desired settings, and then importing that template into Group Policy so that it can be rolled out to your entire network.

Analyzing Current Security

You can analyze the security settings on any machine in one of two ways: either by using the MMC, or through the secedit command-line utility. The Security Configuration and Analysis console (which I'll refer to as SCA from this point on) isn't one of the default consoles installed in your Administrative Tools folder; you'll need to open a blank MMC console in author mode (enter mmc /a from the Run line) and use the File ➤ Add/Remove Snap-in menu command.

NOTE: Since you'll probably be using this tool fairly often, I'd recommend that you save a custom console to your Administrative Tools folder for easy access.

Using SCA is pretty intuitive since the opening screen provides you with instructions to get started. In order to work with SCA, you'll need to create a database that will store the security template values that you're comparing or applying. If you have an existing database, simply right-click the SCA node and select Open, and then browse to the database file you need. If you're creating a new database, you'll need to do the following:

1. Right-click the SCA node and select Open Database. (I know it seems counterintuitive to open a database that doesn't exist yet. Trust me, it works.)
2. Enter the path and name of the SCA database that you want to create, and then click Open.
3. You'll then need to select the template that you want to compare your current settings against. We'll go into detail about what the different templates do in a later section, but for now the file names should look fairly intuitive:

compatws.inf: Used for workstations that need backwards compatibility with legacy applications or networks.

dcsecurity.inf: This is created by the operating system when a member server is promoted to domain controller status.

iesacls.inf: Allows you to lock down Internet Explorer settings.

hisec*.inf: Used for a high-security configuration; hisecdc.inf corresponds to a domain controller, hisecws.inf is for a secure workstation.

notssid.inf: Used to remove the Terminal Server user SID from a server that isn't being used for Terminal Services connections.

rootsec.inf, setup security.inf: Ignore these for now, we'll discuss them in the "Using Security Templates" section in a moment.

secure*.inf: Used for situations where you want a secure configuration, but the settings in the hisec*.inf templates are a bit over-the-top. Sufficient for most environments.

4. Once you've selected a template, you'll then analyze your computer's security settings compared to those within the template. (The instructions that you see in the SCA GUI at this point describe the steps to configure your computer before the steps needed to analyze it: please, oh please, don't take this literally. You always want to analyze a computer's settings before blindly applying a new template.)
5. Right-click the SCA node again and select Analyze Computer Now. You'll be prompted for a location to store the analysis results as a .LOG file. Select a location, and then click OK to begin the analysis.

Once you've analyzed your computer's settings, you can browse through the SCA console to see where your settings differ from those within the template. You'll see a screen similar to Figure 4-5 with three columns: Policy, Database Setting, and Computer Setting. A red X will be displayed if a defined setting doesn't match the setting specified in the template, versus a green check mark if your settings are consistent.

Figure 4-5

You can also perform a security analysis from the command line, using the secedit command with the following syntax:

secedit /analyze /db FileName.sdb [/cfg FileName] [/overwrite]
[/log FileName] [/quiet]

Command-line arguments:
/db FileName specifies the database file used
to perform the analysis

/cfg FileName specifies the security template to
import into the database prior to performing
the analysis. Security templates are created
using the Security Templates snap-in.

/log FileName Specifies a file in which to log the
status of the configuration process. If not
specified, configuration data is logged in
Scesrv.log, which is located in the
%windir%SecurityLogs folder.

/quiet Specifies that the analysis process should
take place without further comments.

NOTE: The /quiet option comes in quite handy if you want to perform a security analysis on all of the workstations in your network: simply add a command like secedit /analyze /db hisecws.sdb to a batch file or login script, and you can collect information from your client workstations with very little effort.

Using Security Templates

So you've already seen a glimpse of security templates in action, but what are they really about? Just as a template for a word processor can help you create a document according to certain standards, a security template is simply a premade file that simplifies the process of comparing your computer's existing security settings against a predefined list. There are dozens (if not hundreds) of options available to you when securing a server, and the number of possible combinations is enough to make even a security expert's head spin. Templates allow you to quickly create a secure baseline for your network clients and servers and make it easier to control how configuration changes occur.

Windows 2000 and 2003 both come with a number of default security templates installed in the %SystemRoot%SecurityTemplates folder. Nine default templates are installed with the operating system, and numerous others can be downloaded from the Microsoft website. Each of the default templates has specific characteristics, described as follows:

compatws.inf: Provides the ability for members of the local Users group to run software that typically requires Power User or local Administrator access. This relaxes the permissions that are normally assigned to the Users group so that you don't need to add your users to these more powerful security groups.

DC security.inf: This template is applied when a 2003 server is promoted to domain controller status. The template contains modifications specific to domain controller security, including file system rights and registry permissions.

securedc.inf: Designed to increase security for domain controllers, including settings for passwords, account lockout, and auditing policies. This template also increases restrictions for anonymous users.

securews.inf: Similar to the settings in securedc.inf, but designed for workstations and member servers.

hisecdc.inf: Provides additional security (over and above that provided by the securedc.inf template) for domain controllers.

hisecws.inf: Increases security for member servers and workstations.

iesacls.inf: Increases the default security configuration for Internet Explorer.

notssid.inf: By default, Windows 2000 and 2003 add file system permissions and user rights for Terminal Services users on each server. If you know for certain that the server you're installing will not be used as a Terminal Server, you can apply this template to remove the unnecessary entries.

rootsec.inf: Defines permissions for the root of the system drive; you can use it to reapply the root directory permissions if they are inadvertently changed. You can also modify this template to apply a specific set of permissions to the root of different volumes. This template doesn't overwrite any permissions that you've explicitly defined on any child objects below the system root; it merely propagates the permissions that are configured to be inherited by child objects.

Setup security.inf: This template is actually created individually whenever you install a new Windows 2000 or 2003 computer; it allows you to revert the configuration of the machine back to its original settings at any time. This should obviously be used with extreme caution, since you'll be overwriting any configuration changes that you've made since the machine was initially installed.

Creating or Customizing a Security Template

If one of these preexisting templates meets your needs, you can apply it directly to your servers and workstations. You can also modify some of the settings to customize the template to address the specific requirements of your organization; however, it's a good idea to make a copy of the default template before making any changes to it. This way if you make a mistake or change your mind, it's easy to roll back to the default settings. To create a copy of a default template, do the following:

1. Open an MMC console in Author Mode (mmc /a from the Run line), and add the Security Templates snap-in.
2. Drill down to Security Templates → C:Windowssecuritytemplates.
3. Right-click the template you want to copy, click Save As, and enter a new name for the copy.

NOTE: To create a blank template from scratch, right-click the C:Windowssecurity templates node and select New Template.

Once you have the new template in place, you can manually edit its settings by browsing through the various nodes in the Security Templates console. Alternatively, you can copy a specific group of settings from one template to another. For example, to copy the account policies settings from the hisecws.inf template into a blank one, follow these steps:

1. Navigate to C:Windowssecuritytemplates → hisecws.inf.
2. Right-click the Account Policies node and select Copy.
3. Navigate to the Account Policies node in your new policy, right-click, and select Paste. This will add the account policies from the hisecws.inf template while leaving the other nodes undefined.

Importing a Template into Group Policy

Once you've created a template containing the security settings you need, you'll import the template's settings into a Group Policy Object in order to propagate those changes to the machines on your network.

UNDERSTANDING DOMAIN-LEVEL POLICIES

It's important to keep in mind that certain Windows security policies can be set only at the domain level. These include the settings in the Account Policies node: account policies, account lockout policies, and Kerberos policies. This means that an Active Directory domain can have only one of these policies in effect at any given time: all users within a single domain will be bound to a single policy for things like password length and complexity, frequency of password changes, PKI policies, and Kerberos settings. The only exception to this is if you create a separate account policy on an Organizational Unit (OU) containing member servers. In this case, the local user accounts on machines within a given OU can have a different account policy apply to them. However, any domain accounts, even within a separate OU, will adhere to the domain account policy. If you have a significant portion of your user base that requires very different policies for account passwords, lockouts, etc., then you should consider creating a separate domain. Because of the transitive trusts created by Windows 2000 and Windows Server 2003, managing multiple domains isn't nearly as tedious as it was under Windows NT. However, maintaining separate domains will still add a level of complexity to your Active Directory environment; be sure when planning your AD infrastructure that you carefully consider these domain-level policies before creating an unworkable Active Directory structure.

To import a security template into a Group Policy, you'll need to do the following:

1. Open the GPO you wish to edit from the Group Policy MMC or the GPMC console.
2. Navigate to Computer Configuration ➤ Windows Settings ➤ Security Settings.
3. Right-click the Security Settings node and select Import Policy. You'll be prompted to browse to the .INF file that you want to import.

CAUTION: A bit of Group Policy weirdness: importing a security template does not register as a "change" to a GPO. This means that the new settings won't be detected by your clients or servers when they query Active Directory for any changes to the GPOs. In order to resolve this, you should manually change a setting within the GPO, even if it's one you intend to change back later. This will ensure that your new security settings will be transmitted to your network machines in a timely fashion.

Click for the next excerpt in this series: Configuring software deployment