Analyzing, Configuring, and Monitoring Windows NT 4.0 Security

This chapter is from the book 

The Security Configuration Manager

Analyze and configure the operating system environment and the user environment by using Security Configuration Manager.

Beginning with Service Pack 4, the Security Configuration Manager (SCM) has been made available to Windows NT administrators. This configuration and auditing utility is available both as a snap-in to the Microsoft Management Console (MMC) as well as a standalone command-line utility. The GUI (MMC) version of this utility provides you with the ability to create configuration databases, which can then be used to audit the configuration of servers or workstations and can also be used to apply uniform configurations to the same machines. The command-line version does not enable you to create configuration databases, but it does give you a slim profile application that you can use to collect security audit data from Windows NT machines and to configure them using databases that have been created. There are two advantages to using the Security Configuration manager (SCM):

• The SCM enables you to audit your current settings against preconfigured (and customizable) configurations to see whether you have missed any critical settings.

• The SCM enables you to easily make configuration settings that, in the past, were adjustable only by way of Registry edits.

Installing the Security Configuration Manager

The Security Configuration Manager is available as a value- added component on the CDs for all the service packs from 4 onward. This software is in a folder called VALUEADD. If you download the service pack, you do not get this folder. If that is the case, you can directly download this add-on from the Microsoft web site at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/scm. At that location, you will find two executables, one for the Intel platform and one for Alpha. Each which, when run, will unzip itself into the folder of your choice.

To install the GUI version of the SCM (that is, the snap-in that can be added to an MMC console), just double-click the file MSSCE.EXE, and it will install with little interaction. To install only the command-line version, open a command prompt and run mssce /c. It also installs with little interaction from you; the command-line version automatically installs when you install the GUI version.

Regardless of how you get the installation files (from the CD or the download), you can then install the SCM by double-clicking the file called MSSCE.EXE and, provided you have the MMC installed, this file will install itself.

After you have installed the GUI version of the SCM, you can then add it as a plug-in to the MMC by following Step by Step 4.11.

STEP BY STEP

4.11 Creating a Standalone Security Console

1. From the Start menu, choose Run and type MMC.

2. From the Console menu in the MMC, select New. This creates a new console in which to install the snap-in.

3. From the Console menu, choose Add/Remove Snap-in.

4. From the Add-Remove snap-in dialog box, click the Add button.

5. From the Add Stand Alone Snap-in dialog box, choose Security Configuration Manager, click Add, and then click Close (see Figure 4.14).

Figure 4.14. The SCM is added as a snap-in to the MMC.

6. From the Add/Remove Snap-in dialog box, click OK.

7. Save the new console by choosing the menu Console, Save, and then entering a meaningful console name to save it (for example, SCM Console). The resulting file (with an .MSC extension) can now be placed as a shortcut in a menu or toolbar for ease of access in the future.

Using the GUI Security Configuration Manager

The SCM has three primary functions. It enables you to do the following:

• Create, edit, and save security configurations.

• Apply security configurations to any computer running Windows NT 4.0.

• Audit the configuration of a Windows NT machine by comparing its settings against that of a predefined security configuration.

To apply a security configuration or to audit a Windows NT machine, you must first have a security database. To create a security database, you must begin with a security configuration template. This template could be one of the templates supplied when you install the SCM or, more likely, it is one that has been created specifically for your organization's security needs (perhaps based on one of the supplied templates). This template is then used to create a security database that can then be used to audit Windows NT machines or to apply consistent configurations to NT machines.

Security Configuration Templates in the SCM

To make configuring a security database easier, the SCM comes with 10 predefined security templates. These templates can be modified and then used to create one or more security databases. These templates are, by default, installed in the path Systemroot\Security\Templates. However, you can choose to move them if that is not a convenient location. The templates are listed in Table 4.4 with a brief description of each.

Table 4.4. Supplied Configuration Templates

Name	Security Level	Platform	Description
BASICWK.INF	Default	NT4.0 Workstation	Default settings for most security attributes. Applies to Windows NT Workstation only.
BASICSV.INF	Default	NT4.0 Server	Default settings for most security attributes. Applies to Windows NT server only.
BASICDC.INF	Default	NT4.0 DC	Default settings for most security attributes. Applies to Windows NT domain controllers only.
COMPWS4.INF	Compatible	NT4.0 Workstation/Server	Software-compatible settings for security attributes. Software compatibility trades off high security for better application functionality by allowing applications to use more and varied system resources without special configuration. Applies to Windows NT workstation and server.
COMPDC4.INF	Compatible	NT4.0 DC	Software-compatible settings for security attributes. Software compatibility trades off high security for better application functionality by allowing applications to use more and varied system resources without special configuration. Applies to Windows NT domain controllers.
SECURWS4.INF	Secure	NT4.0 Workstation/Server	Secure settings for security attributes. Secure settings will err on the side of security when balancing software functioning with software compatibility, thus making this setting higher security than the compatible settings. Applies to Windows NT workstation and server.
SECURDC4.INF	Secure	NT4.0 DC	Secure settings for security attributes. Secure settings will err on the side of security when balancing software functioning with software compatibility, thus making this setting higher security than the compatible settings. Applies to Windows NT domain controllers.
HISECWS4.INF	Highly secure	NT4.0 Workstation/Server	Highly secure settings for security attributes. High security applies ideal security without regard for the proper functioning of applications. Most applications will not function adequately using this setting. Applies to Windows NT workstation and server.
HISECDC4.INF	Highly secure	NT4.0 DC	Highly secure settings for security attributes. High security applies ideal security without regard for the proper functioning of applications. Most applications will not function adequately using this setting. Applies to NT Windows domain controllers.
OFF97SR1.INF	Compatible	NT4.0 Workstation/Server	This template is designed to be used in conjunction with (applied after) a compatible template to provide optimal functioning of Office 97 SR1. Applies to Windows NT machines that have already had Office 97 SR1 installed.

These templates (and the databases that result) consist of seven sections: Account Policies, Local Policies, Event Log, Restricted Groups, System Services, Registry, and File System. Each of these is used to define configuration settings in system and file areas that affect security.

The Account Policies section enables you to configure all the settings that can be adjusted in the Account Policies dialog box accessible from User Manager for Domains. (For more information, see the section ""Account Policies"" in this chapter.) In addition to these settings, there is also the option to turn on the complexity requirements for passwords. This property implements a feature that was available only through a Registry setting prior to SP4. Complexity requirements ensure that passwords in the domain not only have a certain length, but also conform to a specific character pattern as specified by a component called PASSFILT.DLL. When activated, this filter requires that passwords meet the following requirements:

• Must contain three of the following four character types: capital letters, small letters, numbers, and symbols

• Must not contain the user's name as defined in the account definition

The Local Policies section enables you to specify settings for audit policy, user rights, and miscellaneous security settings. The audit policy and user rights duplicate the settings accessible from the User Manager for Domains. Some of the security settings are accessible from Policy Editor and some could only be set through the Registry in the past. For example, there is a setting for shutting down the system when the security log becomes full. In the past, this could be set only using a Registry setting, but it can now be set via a security database.

The Event Log section enables you to configure settings for the three event logs (application, security, and system) in one convenient location.

The Restricted Groups section enables you to define the membership of groups. This would enable you to ensure that, as part of your security configuration, certain people were in certain groups and certain people were not.

The System Services section enables you to define startup and logon properties for each of the system services. This enables you to configure these services without having to go to the service applets in the Control Panel.

The Registry section enables you to define security on certain Registry locations. This enables you to define which users can make modifications to which Registry locations. This section will wreak havoc with the installation and operation of applications if not set up properly.

The File System section enables you to define access control list (ACL) settings for any files or folders on your system. By default this includes file and folders in the system root (WINNT) and the configuration files found on the system partition. However, you can add any files or folders you want to this list. For this section to function properly, the system folder must be placed on an NTFS partition.

Modifying a Security Configuration Template

Microsoft recommends that before applying the settings from a predefined template to your production environment, you should audit the contents of the template to ensure that its settings conform to your particular environment. To expand on that, you should make a copy of the template that most closely conforms to your requirements and then modify it. Although you can copy the supplied templates at the operating system level, the easiest way to do it is through the SCM console. Step by Step 4.12 shows you how to create a copy of a security template.

STEP BY STEP

4.12 Copying a Security Configuration Template

1. Start the SCM console that you created in Step by Step 4.11.

2. Expand the tree Console Root, Security Configuration Manager, Configurations, C:\WINNT\Security\Templates. This path may be different if your system root is not C:\WINNT (see Figure 4.15).

Figure 4.15. Locate the template that you want to copy.

3. Locate the template that you want to copy, right-click it, and from the menu that appears choose Save As.

4. From the Save As dialog box, type in a name that accurately describes the template you are creating and click Save. When you return to the SCM console, the new template will appear in the list along with the other templates.

After you have created your own template, you can then modify the individual settings in that template to conform to your requirements. This is done by locating the specific attributes you want to change and then double-clicking that attribute in the right-hand panel in the SCM. When you do so, a dialog box opens, giving you the configuration options available. Figure 4.16 shows the configuration dialog box for Minimum Password Length.

Figure 4.16. This is the Minimum Password Length configuration dialog box.

The changes that you make to the template you are editing are not automatically saved. You must manually save as you go (by right-clicking the template name and choosing Save); otherwise, you will be prompted on exit to save the changes.

Creating a Security Configuration Database

To actually use a configuration, you must create a configuration database. This is generally done either by loading an existing database or by creating a new database by importing the settings from a security configuration template.

When the SCM is brought up for the first time, the database is defined as "Not Loaded". This just means that no security database has been specified for this SCM. If you have defined one already for the current machine, you can load it (to use it) by right-clicking the Database entry (under the SCM root) and choosing Open. This will attempt to load the database called SECEDIT.SDB in the path Systemroot\Security\Database. If this database does not exist in this path, an Open Database dialog box displays and prompts you to browse for the database you want to load.

If you have a security database, but it is either not called SECEDIT.SDB or it is in another location other than default (Systemroot\Security\Database), you can choose Open Database from the pull-down menu that appears when you right-click the Database entry in the SCM.

If you do not have a security configuration database, you will have to create one by importing a template. Note that the database created is not permanent. You must perform a system analysis before you will be allowed to save the configuration database on disk. In addition, you also must note that these databases are not trivial in size. Even a minimally configured machine will create a database of approximately 25MB.

Step by Step 4.13 describes how to create a database from a template.

STEP BY STEP

4.13 Creating a Security Configuration Database from a Template

1. Start the SCM console that you created in Step by Step 4.11.

2. Expand the tree Console Root, Security Configuration Manager.

3. Right-click the Database entry and choose Import Configuration from the menu that appears.

4. In the Select Configuration to Import dialog box, double-click the template you want to use as the basis for the database. This will return you to the SCM and will create a configuration database called SECEDIT.SDB.

Auditing a Windows NT Machine with a Security Configuration Database

After a security configuration database has been created, you might want to check current machine configurations against the configuration setup in the database. To do this, you begin by opening a configuration database. Once this is complete, you can then perform a security audit. Step by Step 4.14 shows how to perform an audit of a Windows NT machine using a security configuration database.

STEP BY STEP

4.14 Auditing a Windows NT Machine Using a Security Configuration Database

1. Open the security console that you created in Step by Step 4.2.

2. Expand the Security Configuration Manager tree.

3. Right-click Database and choose Import Configuration from the menu that appears.

4. In the Select Configuration to Import dialog box, double-click the template that you want to use as the basis for your audit.

5. Right-click Database and choose Analyze System Now.

6. In the Perform Analysis dialog box, accept the path to the error log shown or enter your own. Press OK to continue.

7. When the SECEDIT.LOG file opens, you may browse its contents to see what the Perform Security Analysis process did. Then exit Notepad to close the file.

8. Check which settings on the local computer do not conform to the security template by expanding the Database section (on the left side). On the right, you will either see icons with green check marks in them indicating that a specific attribute conformed to the security standard in the template, or you will see red circles with white "X''s to indicate that an attribute did not conform (see Figure 4.17). Icons with neither checks nor "X''s were not eligible for audit by the security database.

Figure 4.17. An 'X' indicates an audited property that did not conform to the specifications in the security database.

9. Examine any nonconforming settings to see why they do not conform and, if desired, change the configuration so that they are not flagged in the future (see Figure 4.18).

Figure 4.18. By double-clicking a setting you can see why it was flagged and then change the configuration database if appropriate.

The security database created from an audit will help you to determine where you may need to change configuration on specific machines if they are to conform to a specific security standard. The process of changing them is made simple, especially if you want to apply all the template settings to a particular machine. If you want to apply these settings to more than one machine, it is advisable to save the result as a configuration database that can be loaded into another SCM at another time (or can be used by the command-line SCM). To save the security database, right-click it and choose Save from the menu that appears. (You will be prompted for a filename at that time.)

The next section describes how to take a security database and apply the settings from that database to a local Windows NT machine.

Applying Security Settings to a Windows NT Machine

You can apply the settings from a security configuration database to a local Windows NT machine. These settings are often obtained by doing a security audit, but also can be obtained from a database created on another Windows NT machine. By applying settings from a database, all settings from the security database will overwrite the settings in the local machine unless the database settings are defined not to overwrite the local machine's settings. By doing this, you can ensure that the security policy you have established is being implemented uniformly across all Windows NT machines in your organization. This can be done as shown in Step by Step 4.15.

STEP BY STEP

4.15 Applying Security Configurations to a Windows NT Machine Using a Security Configuration Database

1. Open the security console that you created in Step by Step 4.11.

2. Expand the Security Configuration Manager tree.

3. Right-click Database and choose Open Database from the menu that appears.

4. In the Open Database dialog box, navigate to the database you want to open and double-click it.

5. In the SCM, right-click Database and choose Configure System Now.

6. In the Configure System dialog box, accept the path to the error log shown or enter your own. Press OK to continue. At this point, a process will begin and you will see an indicator to tell you what has been changed. When it is complete, you will be returned to the SCM.

Having shown the theory and practice of the GUI tool for configuring workstations, it is useful to note that the individual configuration of machines using this tool would be very resource intensive (especially in a large organization). As a result, a command-line utility is available for remote (and batch) configuration of machines.

Using the Command-Line Security Configuration Editor

On most systems in your environment, it would be redundant (and possibly dangerous) to install the GUI Security Configuration Editor (SCE) just to audit a machine or to apply configuration settings. As a result, a command-line-based version of the SCE is available. This version cannot be used to create or edit templates or to analyze audit results, but it can be used to initiate audits and to apply security configuration from configuration databases. Because this is a command-line utility, you can execute this remotely by using a remote administration tool (such as SMS) or you can execute it on a schedule by using a scheduling program.

The command-line SCE has four functions:

• Configure a system from a database.

• Analyze a system using a database.

• Export the settings from a security database to create a security template.

• Validate the syntax of a configuration template.

System Configuration Using the Command-Line SCE

You can use the command-line SCE to configure a Windows NT system from a security configuration database. The following is the command-line syntax to perform system configuration:

secedit /configure [/cfg filename] [/areas Areas] [/overwrite]
 [/db filename] [/log LogPath] [/verbose] [/quiet]

In the command-line syntax, those entries surrounded by square brackets ([]) are optional. Table 4.5 defines the options in this syntax.

Table 4.5. Parameters for Command-Line SCE Configuration

Option	Function
/cfg filename	Defines the path to the configuration file that will be loaded into the database (/db) prior to performing the configuration.
/areas Areas	Specifies the security areas to be processed. The default is all areas. Each of the following areas should be separated by a space: SECURITYPOLICY. Local policy and domain policy for the system, including account policies, audit policies, and so on GROUP_MGMT. Restricted group settings (only for groups specified in the profile) USER-RIGHTS. User logon rights and privilege granting DSOBJECTS. Security on directory objects REGKEYS. Security on local Registry keys FILESTORE. Security on local file storage SERVICES. Security configuration for all defined services
/overwrite	Specifies that the contents of the database (/db) should be overwritten by the contents of the configuration file (/cfg).
/db filename	Specifies the path to the database that SCE will use to configure the system. If this parameter is not specified, the last configuration/analysis database is used. If there is not a previous database, Systemroot\Security\Database\SECEDIT.SDB is used.
/log LogPath	Specifies the path to the log file for the process. If not provided, progress information is output to the console.
/verbose	Generates detailed progress information.
/quiet	Suppresses screen and log output.

System Analysis Using the Command- Line SCE

You can use the command-line SCE to analyze a Windows NT system from a security configuration database. The following is the command-line syntax to perform system configuration:

secedit /analyze [/cfg filename] [/db filename] [/log LogPath]
 [/verbose] [/quiet]

In the command-line syntax, those entries surrounded by square brackets ([]) are optional. Table 4.6 defines the options in this syntax.

Table 4.6. Parameters for Command-Line SCE Analysis

Option	Function
/cfg filename	Define path to configuration file that will be appended to the database (/db) prior to performing the analysis
/db filename	Specifies path to database that SCE will use to perform the analysis against. If this parameter is not specified, the last configuration/analysis database is used. If there is not a previous database then systemroot\security\database\secedit.sdb is used.
/log LogPath	Specifies the path to the log file for the process. If not provided, progress information is output to the console.
/verbose	Generates detailed progress information
/quiet	Suppresses screen and log output

Template Generation using the Command-Line SCE and a Configuration Database

The command-line SCE can be used to generate a security configuration template from a security configuration database. The following is the command-line syntax to create a template:

secedit /export /cfg filename [/areas Areas] [/db filename] [/log LogPath]
 [/verbose] [/quiet]

In the command-line syntax, those entries surrounded by square brackets ([]) are optional. The options for /export are exactly the same as the options for /configure. Table 4.5 explains the parameters for command-line SCE template generation.

Configuration Template Validation Using the Command-Line SCE

You can use the command-line SCE to verify the syntax of a configuration template. The following is the command-line syntax to verify a template:

secedit /validate FileName

In this syntax, a filename (and path) are required to define the template being checked for validity.