Security Configuration Wizard

Security Configuration Wizard (SCW) is an attack surface reduction tool for members of the Microsoft® Windows® Server 2003 family with Service Pack 1 (SP1). SCW determines the minimum functionality required for a server's role or roles, and disables functionality that is not required.

For more technical guidance about SCW, see "Security Configuration Wizard for Windows Server 2003" at the Microsoft Windows Server 2003 Web site. (http://go.microsoft.com/fwlink/?LinkID=42434)

SCW does the following:

  • Disables unneeded services.
  • Blocks unused ports.
  • Allows further address or security restrictions for ports that are left open.
  • Prohibits unnecessary IIS web extensions, if applicable.
  • Reduces protocol exposure to server message block (SMB), LanMan, and Lightweight Directory Access Protocol (LDAP).
  • Defines a high signal-to-noise audit policy.

SCW guides you through the process of creating, editing, applying, or rolling back a security policy based on the selected roles of the server. The security policies that are created with SCW are XML files that, when applied, configure services, network security, specific registry values, audit policy, and if applicable, Internet Information Services (IIS).

Note

  • In some cases, you must be connected to the Internet to use the links in SCW Help. If your computer is not connected to the Internet, you can find the same topic in Help and Support Center by searching for the link text. To open Help and Support Center, click Start, and then click Help and Support Center.

You can install SCW on computers running a member of the Windows Server 2003 family with SP1.

  • For recommendations about how to get the most out of SCW, see Best Practices.
  • For information about how to perform certain tasks, see How To.
  • For general background information, see Concepts.

You do not need to run SCW to help secure your computer running Windows Small Business Server 2003. Instead, Windows Small Business Server 2003 uses the default settings in Setup and in the Configure E-mail and Internet Connection Wizard to help secure your server.

If you have not already run the Configure E-mail and Internet Connection Wizard, you should run it to help secure your server.

To start the Configure E-mail and Internet Connection Wizard on the computer running Windows Small Business Server 2003:

  • Click Start and then click Server Management.
  • In the console tree, click Internet and E-mail.
  • In the details pane, click Connect to the Internet.


Best Practices

This section tells how to get the most out of Security Configuration Wizard (SCW).

Identify and target similar servers

SCW helps to reduce the attack surface of servers by creating a security policy that is specifically designed for their specific roles. Administrators can simplify policy authoring and distribution by identifying groups of servers that perform the same, or similar, tasks. Here are ways you can do this:

  • Author one policy for a group of servers. SCW authors a security policy based on the roles, tasks, and functions performed by a server. Others servers that perform the same, or very similar, functions can be configured with the same security policy. Administrators can use SCW once to author a security policy, save it, and apply it to all servers that perform the job function.
  • Group similar servers in one organizational unit (OU). The SCW transform operation can apply a security policy to a domain or OU by using Group Policy. To simplify policy distribution, an administrator could group servers that perform similar job functions, and use the same security policy, into a single OU. A new security policy can be distributed quickly and easily to the server OU by using the SCW transform operation.
  • Create policies for similar platforms. For services or ports specific to 64-bit computers, create the policies on a 64-bit computer. Then deploy these policies to other 64-bit computers only (not 32-bit computers) to ensure the services are properly identified and configured.

It is highly recommended that the prototype server from which the security policy will be created matches the target servers to be configured at the service level. The security policy disables any service on the server that is contained in the Security Configuration Database but was not present on the prototype server when the policy was created. For example, if the DCOM Server Process Launcher service is listed in the Security Configuration Database, but is not present on the prototype server, the security policy created based on the prototype server will set the DCOM Server Process Launcher state to disabled. When you apply the security policy to other servers, the DCOM Server Process Launcher service will be disabled on those servers. You can configure unnecessary services in SCW (you can disable the service or leave the startup mode of the service unchanged), but only services that are not in the Security Configuration Database, and therefore are not defined in the security policy that you create with SCW.

Test new security policies offline before deployment

  • The settings configured in the new security policies may cause compatibility issues with applications or services. Therefore, thoroughly test new security policies in a test environment before applying the policies to production servers.

Create one complete security policy

  • SCW should be used to author a single security policy that contains all desired security settings for a server. This will simplify configuration, rollback, and analysis. For simple configuration and rollback, a single security policy for a machine, or set of machines, is much easier to understand and update than a series of policies. If a security policy defines all the desired settings for a server, a compliance report can be generated by executing one scan. This makes analysis using the scwcmd /analyze command easy. For more information about scwcmd, see Security Configuration Wizard command-line tool.

Organize similar servers into organizational units (OUs) in Active Directory

  • Grouping servers by OUs in Active Directory domains facilitates the application of security policy through Group Policy.


How To...

  • Install Security Configuration Wizard
  • Install Security Configuration Wizard unattended
  • Start Security Configuration Wizard
  • Create, edit, apply, or roll back a security policy
  • View change logs
  • Remove Security Configuration Wizard from a computer


Install Security Configuration Wizard

Microsoft Windows graphic

To install Security Configuration Wizard

  1. Open Add or Remove Programs.
  2. Click Add/Remove Windows Components.
  3. Select the Security Configuration Wizard check box, click Next, and then click Finish.

Notes

  • Security Configuration Wizard (SCW) is an optional component in Windows Server 2003 SP1. To install SCW, you must first install Service Pack 1 for Windows Server 2003.
  • To perform this procedure, you must be a member of the Administrators group on the local computer. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.
  • To open Add or Remove Programs, click Start, click Control Panel, and then double-click Add or Remove Programs.


Install Security Configuration Wizard Unattended

Microsoft Windows graphic

To install Security Configuration Wizard unattended

  1. Before initiating the unattended installation, add the following entry to the [Components] section of Unattend.txt: SCW=On

    2. To apply an SCW policy during the unattended installation, also carry out the following steps.

  2. Create the policy file on a server that already has SCW installed.
  3. Either create a Cmdlines.txt file (or modify the existing one) so that it has a [Commands] section containing the following line: scwcmd configure /p:SCWPolicy.xml
  4. Copy the Cmdlines.txt file and the previously created policy file to the $OEM$ directory. The $OEM$ directory is specified by the OEMFILESPATH entry in the [Unattended] section of Unattend.txt.

Note

  • For detailed instructions about running unattended installation, see "Automating and Customizing Installations" in the Microsoft Windows Server 2003 Deployment Kit. (http://www.microsoft.com/)


Start Security Configuration Wizard

Microsoft Windows graphic

To start Security Configuration Wizard

  1. Open Administrative Tools.
  2. Double-click Security Configuration Wizard.

Notes

  • To open Administrative Tools, click Start, click Control Panel, and then click Administrative Tools.
  • Security Configuration Wizard (SCW) can be used to author policy and to perform configuration or rollback for one server at a time. The SCW executable is called SCW.exe. To start SCW from the command prompt, type SCW.
  • The SCW command-line tool can be used for multi-machine configuration, analysis, rollback, and Group Policy object (GPO) policy management. The SCW command-line tool is called scwcmd.exe. To start SCW from the command prompt, type SCWcmd. To see SCW command-line help, type scwcmd.exe /?


Create, edit, apply, or roll back a security policy

Microsoft Windows graphic

To create, edit, apply, or roll back a security policy

  1. Start the Security Configuration Wizard.
  2. On the Welcome to the Security Configuration Wizard page, click Next.
  3. On the Configuration Action page, do one of the following:
    • To create a security policy, click Create a new security policy.
    • To edit a security policy, click Edit an existing security policy.
    • To apply a security policy, click Apply an existing security policy.
    • To roll back a security policy, click Rollback the last applied security policy.
  4. If you chose to edit or apply an existing security policy, in Existing security policy file, enter the security policy path and file name, or browse to the security policy, and click Next.
  5. Complete the Security Configuration Wizard.

Notes

  • To perform this procedure, you must be a member of the Administrators group on the local computer. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.
  • For information about how to open Security Configuration Wizard (SCW), see Related Topics.
  • To apply or roll back a security policy that you have created with SCW, SCW must be installed on the selected server. When creating or editing a security policy, you can select a server that does not have SCW installed. In either case, the selected server must always be a computer running a member of the Windows Server 2003 family with Service Pack 1.
  • Do not end the SCW task while policy configuration is in progress as this can leave the server in a partially configured state. A policy should instead be rolled back after it has been applied to the system.

Related Topics


View change logs

Microsoft Windows graphic

To view change logs

  • At the command prompt, type scwcmd view /x:file_name.xml, where file_name is the name of the change log. Example: scwcmd view /x:AnalysisLog10.xml

Note

  • When you use Security Configuration Wizard (SCW) to apply a policy, SCW creates a change log file to document the changes. Change logs are stored in the following directory:

    • %windir%\security\msscw\ChangeConfigurationLogs


Remove Security Configuration Wizard from a computer

Microsoft Windows graphic

To remove Security Configuration Wizard from a computer

  1. Open Add or Remove Programs.
  2. Click Add/Remove Windows Components.
  3. Clear the Security Configuration Wizard check box, click Next, and then click Finish.

Notes

  • To perform this procedure, you must be a member of the Administrators group on the local computer. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.
  • To open Add or Remove Programs, click Start, click Control Panel, and then double-click Add or Remove Programs.
  • When Security Configuration Wizard (SCW) is uninstalled, all files contained in the %Windir%\Security\Msscw folder are removed. This includes all policy files, log files, and rollback files that were created after SCW was installed.


Concepts

  • Security Configuration Wizard overview
  • Security Configuration Wizard command-line tool
  • Extending the Security Configuration Database
  • Rolling back a security policy
  • Understanding Security Configuration Wizard


Security Configuration Wizard overview

Security Configuration Wizard (SCW) is an attack surface reduction tool for computers running a member of the Windows Server 2003 family with Service Pack 1 (SP1). SCW guides you through the process of creating a security policy, based on the roles performed by a given server. Once a policy is created, it can be edited or applied to one or more similarly configured servers. Applied policies can be rolled back in order to undo changes that have caused problems. To edit, apply, or roll back a security policy, the policy must have been created with SCW.

SCW can only be installed on computers running a member of the Windows Server 2003 family with SP1. Also, the server that you are configuring must be running a member of the Windows Server 2003 family with SP1.

SCW is composed of the following sections:

  • Role-based service configuration
  • Network security
  • Registry settings
  • Audit policy
  • Internet Information Services (IIS)
You will not see the IIS section if you have not selected the Web Server role on the Select Server Roles page of SCW.

SCW helps reduce the attack surface of a configured server, and you can use other security features to further secure your computers. For more information, see Security on the Microsoft Web site.(http://www.microsoft.com/)

The security policy that you create is based on the roles that are installed on the selected server. The selected server can be a server to which you want to apply the security policy, or you can use the selected server to create a security policy, and then apply the security policy to a group of servers that perform similar roles as the selected server. For example, if you want to create a security policy for all of the file servers in your organization, you can choose one representative file server as the selected server, use that server to create the security policy, and then apply the security policy to each file server in your organization. For more information about selecting a server, see Select Server.

While using SCW to configure a policy, if you are not sure of the correct selection for your environment, it is recommended that you skip the associated sections by clicking Next and then configure the rest of the security policy. You can configure the skipped sections later, once you are familiar with the technology. SCW does not configure skipped sections. These sections are left undefined until you edit the policy and configure those sections. However, you cannot skip the Role-Based Service Configuration section.

Deploying SCW security policies by means of Group Policy

SCW policies are XML files that can contain settings for services, Windows Firewall, Internet Protocol security (IPsec), registry values, audit policy, IIS, and other settings that are imported from existing security templates. These SCW XML policy files are not natively supported by the Group Policy infrastructure. Instead, SCW XML policy files must be transformed into formats that the various Group Policy extensions understand. The SCW command line tool, Scwcmd.exe, provides the Transform operation. For help with this tool, at a command prompt, type scwcmd transform. In short, the administrator provides the Transform operation with the name of the SCW policy file to be transformed, along with the name of a Group Policy object (GPO) to be created. The Transform operation then creates the GPO and defines the settings for these Group Policy extensions:

  • Security Settings contains service settings, registry values, audit policy and security template settings that were imported into the SCW XML policy.
  • IP Security Policies contains the IPsec configuration that is defined in the SCW policy.
  • Windows Firewall contains Windows Firewall settings that are defined in the SCW policy.

After the GPO is created, the administrator must manually link the GPO to the target organizational unit (OU) by using Active Directory Users and Computers, or by using the Group Policy Management Console.

Notes

  • For more information about Group Policy, see Group Policy. For more information about scwcmd.exe, see Security Configuration Wizard command-line tool. For more information about OUs, see Organizational Units. For the latest information about Windows Firewall performance considerations, see Windows Firewall (http://www.microsoft.com/).
  • You must be logged on with an account that is a member of the Domain Admins group in order to perform the Transform operation.
  • The Transform operation must be performed from a server that is joined to the domain where the Group Policy object will apply.
  • Any IIS settings that are defined in the SCW policy will be lost during the Transform operation because Group Policy does not have an IIS extension.
  • The OU hierarchy in Active Directory must be organized along server roles in order to take advantage of SCW-generated policies. There should be a separate OU for each server role supported by your organization.
  • Applying SCW-generated policies to servers running versions of Windows earlier than Windows Server 2003 with SP1 is not supported. Use the WMI filtering capabilities of Group Policy to ensure that SCW-generated policies do not apply to servers running versions of Windows earlier than Windows Server 2003 with SP1. Alternatively, place only servers running Windows Server 2003 with SP1 into the OUs where the transformed SCW policies will apply.

Roles

Server roles are the main functions performed by the servers in your organization. Examples of server roles are file server, domain controller, and Web server roles. Client features use services provided by other servers. Examples of client features are the domain member and Dynamic Host Configuration Protocol (DHCP) client.

A role is defined by the services, ports, and IIS requirements that are necessary to perform the role. The specific services, inbound ports, and settings that are required vary for each role. As a result, security policies created by SCW are specific to servers that perform the same roles as the selected server. If you apply a file server security policy to a Web server, the services, inbound ports, and settings that are required to perform the Web server role are disabled and the file server security policy settings are enabled. In some cases, security policies are specific to the selected server and must be modified before applying them to other servers.

To determine which services are required for a server to perform a certain role, on the Select Server Roles, Select Client Features, and Select Administration and Other Options pages, click the triangle between the check box and the role name. Information about the role appears below its name, including a brief description and the required services.

SCW analyzes the selected server to determine which roles it performs. The scanning and analysis process is guided by the Security Configuration Database. The Security Configuration Database also contains information about services that are required to perform a role, as well as ports that must be open, if applicable.

For more information about the Security Configuration Database, see Security Configuration Database.

By using the information in the Security Configuration Database, SCW determines which roles the selected server is capable of performing with the software that is currently installed and which roles the server is currently configured to perform. If a server is currently configured to perform a specific role, that role is automatically selected by default, and the role appears in the Installed server roles view on the Select Server Roles page, and the same is true for the Select Client Features and Select Administration and Other Options pages. If a server is likely performing a specific role, then that installed role is automatically selected by default.

Selecting roles from the All roles view will have no effect on the selected server with the software that is currently installed. These views are useful if you plan to install other roles on the selected server or if you plan to apply the security policy to multiple servers that perform similar roles, but have slight differences. For example, if you want to configure a security policy for all file servers in your organization, and some file servers are also Audit Collection Services (ACS) servers, you can create a security policy that selects both file and ACS server roles and apply the security policy to all file servers, without having to determine if a file server is also an ACS server.

For more information, see Security Configuration Wizard.


Security Configuration Wizard command-line tool

Security Configuration Wizard (SCW) includes the Scwcmd.exe command-line tool. You can use Scwcmd for the following tasks:

  • Configure one or many servers with an SCW-generated policy.
  • Analyze one or many servers with an SCW-generated policy.
  • View analysis results in HTML format.
  • Roll back SCW policies.
  • Transform an SCW-generated policy into native files that are supported by Group Policy.
  • Register a Security Configuration Database extension with SCW.

When you use scwcmd to configure, analyze, or roll back a policy on a remote server, SCW is required to be installed on the remote server.

Getting command-line help for Scwcmd

To get basic help on the Scwcmd tool, at a command prompt, type scwcmd.

Viewing formatted analysis results with the scwcmd /view command

The directory %windir%\security\msscw\transformfiles contains .xsl transform files. These are applied to the .xml policy file for the rendering process when you view analysis results through the scwcmd /view command.


Extending the Security Configuration Database

This is an advanced topic for developers with XML expertise and for IT professionals.

You can create a new Security Configuration Database file or custom applications in your environment.

Caution

  • When customizing the Security Configuration Database, do not make changes to W2K3.xml or to any other XML files that are included with Security Configuration Wizard (SCW).

You can create a new Security Configuration Database so that it is customized for your environment. For example, you may be creating a security policy and your organization uses custom applications that require specific services to be enabled or ports to be open. You can customize the Security Configuration Database to contain this information. For more information about the Security Configuration Database, see Security Configuration Database.

Caution

  • When customizing the Security Configuration Database, do not make changes to W2K3.xml.

Create your own XML file and save it to %Systemroot%\Security\Msscw\KBs. To customize an existing role, in your custom Security Configuration Database, create a new role with the same role type and name as the role in W2K3.xml. For example, if you want to customize the file server role, in your custom XML file, you would create a role with Server and File. You can customize the entries for <Selected>, <Services>, and <Ports>. Then, open KBReg.xml and replace <Custom /> with <Custom>Custom_KB_Name.xml </Custom>.

For more information about the Security Configuration Database, see Security Configuration Database.


Rolling back a security policy

You can use Security Configuration Wizard (SCW) to roll back a security policy after it is appled.

You are not limited to one rollback. However, to avoid administrative overhead, do not roll back a policy more often than you must. Make multiple changes during each SCW session, rather than running through SCW several times and creating a separate policy each time.

If, after you roll back a security policy, some services do not behave as expected, check whether services that were started manually were stopped. If you apply a security policy that disables manually-started services and then roll back this policy, those services might need to be restarted manually.


Understanding Security Configuration Wizard

This section provides additional information about the policy settings configured in Security Configuration Wizard.

  • Starting Security Configuration Wizard
  • Role-Based Service Configuration
  • Network Security
  • Registry Settings
  • Audit Policy
  • Internet Information Services
  • Completing Security Configuration Wizard


Starting Security Configuration Wizard

This section provides general background information about Security Configuration Wizard pages.

  • Configuration Action
  • Select Server
  • Security Configuration Database


Configuration Action

With Security Configuration Wizard (SCW), you can create, edit, and apply a security policy. You can also roll back the last security policy that you applied if it does not behave as expected.

SCW includes a command-line tool that you can use for certain important tasks. For more information, see Security Configuration Wizard command-line tool.

Creating a new security policy

You can create a security policy that configures services, Windows Firewall, Internet Protocol security (IPsec) settings, audit policy, and specific registry settings. The security policy is an XML file that can be edited and applied with SCW. The policy can be made into a Group Policy object (GPO) by using the scwcmd.exe command-line tool. For more information about Scwcmd.exe, see Security Configuration Wizard command-line tool.

Once you have started SCW, you do not need to complete all sections in the same session. To skip sections, select Skip this section at the beginning of each uncompleted section, save the policy, and use the Security Configuration Wizard to edit the policy later. If you select Skip this section after configuring part of a section, your selections are not saved, nor does SCW configure the section for you. Settings in skipped sections remain undefined until you edit the security policy and configure those settings.

Editing an existing security policy

You can edit a security policy that you have already created with SCW. You must select Edit an existing security policy before you can browse to the location of the security policy that you want to edit. The policy that you edit can be stored locally or in a network shared folder. SCW can edit policies with an .xml file name extension. Security templates with an .inf extension cannot be edited with SCW.

Manually editing the XML security policy is not supported. You must use SCW to edit a security policy that you have created with SCW.

Applying an existing security policy

Once you create a security policy with SCW, you can apply it to a test server for testing purposes or to your production environment. The Scwcmd.exe command-line tool lets you apply the same policy to multiple servers. You can use the scwcmd transform command to create GPOs. SCW can apply XML security policies, but does not recognize any other file types.

If the selected server is a member of an Active Directory domain, then domain-based GPO security policy generally overrides registry settings set directly through SCW. If you do not want that to happen, create a GPO by using scwcmd transform and apply it through Active Directory.

For more information about the registry values configured with SCW, see Registry Settings.

Important

  • It is highly recommended that you test a newly-created or modified security policy before applying it to your production environment. Testing minimizes the possibility that the new policy might cause unexpected behavior, such as compatibility issues, in your production environment.
  • It is recommended that you create policies that include services or ports specific to 64-bit computers on a 64-bit computer, and then deploy these policies to other 64-bit computers only. To ensure that the services are properly identified and configured, do not deploy policies created on 64-bit computers to 32-bit computers, or vice-versa.

Rolling back the last applied security policy

If you applied a security policy with SCW that causes decreased functionality for a server or other undesirable results, you can roll back the security policy so that it is no longer applied to the server. However, if the policy is edited in Local Security Policy after you apply it, the changes are not be rolled back to their pre-application state. They remain in their current configuration.

For services and registry values, the process of rolling back restores settings that were changed during the configuration process. For Windows Firewall and IPsec, the process of rolling back unassigns any SCW policy that is currently in place and reassigns the previous policy that was in place at configuration time.

Do not end the Security Configuration Wizard task while policy configuration is in progress as this can leave the server in a partially configured state. A policy should instead be rolled back after it has been applied to the system.

Related Topics


Select Server

The Select Server page allows you to choose a server, based on your choice on the preceding Configuration Action page.

If the configuration action was... | Then the server you select is...
Create a new security policy. | The server whose settings are the baseline settings. By default, this is the local server (the server running Security Configuration Wizard).
Edit an existing security policy. | The server that was used as a baseline.
Apply an existing security policy. | The server to which policy should be applied.
Roll back the last applied security policy. | The server from which you want to roll back the last applied policy.

If you are creating a new security policy, the local computer is selected by default. If you are editing an existing policy, the server that was used during the last edit is selected by default.

Security Configuration Wizard (SCW) helps you create a security policy based on the installed roles for the selected server. To do so, SCW checks the selected server for installed roles to determine how to configure services and ports in the security policy. If you are applying a security policy, it will be applied to the selected server.

If you have more than one server that is configured in a similar way, you can create one security policy and apply it to each server. Select one server to use as a configuration baseline, use that server to create the security policy, and then apply that policy to each of the other servers. For example, if you have multiple file servers in your organization, you can create one security policy for file servers by choosing one representative file server, creating the policy, and then applying the policy to each file server.

SCW does not change the configuration of the selected server until you apply the security policy. Also, the security policy is not saved until SCW is finished. If you cancel SCW before you save the policy, the settings are not saved.

Selecting a server that does not have SCW installed on it

You can configure policy for multiple similar servers by selecting one of the servers as a prototype. If the selected server does not have SCW installed, then less information about the server will be available.

The differences in SCW behavior are as follows:

SCW cannot determine whether an unknown service is listening on a port.

Behavior with SCW installed | Behavior with SCW not installed
All unknown services are available for approval. Only the services that are found to be listening are selected by default. | All unknown services are available for approval. None are selected by default. A pull-down description indicates that, because SCW was not installed, SCW could not determine whether the service listens or not, and the user should select the service if they know that it listens.

SCW cannot determine whether an approved application exists on the remote server.

Behavior with SCW installed | Behavior with SCW not installed
If the application does exist, then it is not marked Not Found. If the application does not exist, it is marked Not Found. | The application is marked Not Found whether or not it exists.

SCW cannot get the list of named pipes.

Behavior with SCW installed Behavior with SCW not installed
SCW will set the Named Pipe Firewall if all three of the following conditions are true:
  • The user configures registry values.
  • No non-default pipes exist.
  • Only the File Server or Print Server role is selected.
 SCW will make no change to the Named Pipe Firewall value.

SCW cannot determine whether customer-defined IPsec policy is in place.

Behavior with SCW installed Behavior with SCW not installed
SCW will show a warning on the Network Summary page if both of these conditions are satisfied:
  • IPsec is not required by the policy.
  • There is an existing customer-defined IPsec policy in place.
The warning says that the existing IPsec policy may conflict with the newly created firewall policy. 		No warning is provided on the Network Summary page.

Notes

  • You must be a member of the local Administrators group on the selected server to apply a security policy. If you are not logged on as an Administrator on that computer, click Specify User Account and type the user name and password of an account that is a member of the local Administrators group.
  • If you want to apply a security policy to a remote server or roll back a security policy from a remote server, SCW must be installed on the remote server. However, if you simply want to create or edit a security policy for the remote server, SCW does not need to be installed on the remote server.


Security Configuration Database

The Security Configuration Database consists of a set of XML documents that list services and ports that are required for each server role that is supported by Security Configuration Wizard (SCW). These files are installed in %Systemroot%\Security\Msscw\KBs. After you select a server, on the Processing Security Configuration Database page, the server is scanned to determine the following:

  • Roles that are installed on the server
  • Roles that are likely being performed by the server
  • Services that are installed but not part of the Security Configuration Database
  • IP addresses and subnets that are configured for the server

SCW combines this server-specific information into a single XML file named Main.XML. The Security Configuration Wizard displays Main.XML if you click View Security Configuration Database on the Processing Security Configuration Database page.

Centralizing the Security Configuration Database

You might want to maintain the Security Configuration Database in a central location that can be used throughout the organization. This allows the Security Configuration Database to be maintained by security experts in one location while allowing administrators in multiple locations to run SCW. SCW.exe accepts a command-line argument for the centralized database location. For example, here is one possible command:

scw.exe /kb \\securityserver\scwkb

The local administrator who runs SCW must have at least read-only access to the remote Security Configuration Database directory. In non-domain environments, the local administrator might need to provide credentials in order to access the centralized server. This can be accomplished by first making a connection to the server. For example, you might use the following command:

Net use k: \\securityserver\scwkb /u:securityserver\User1 * scw.exe /kb k:\

For more information about selecting server roles, see Select Server Roles. For information about extending the database, see Extending the Security Configuration Database.


Role-Based Service Configuration

This section provides general background information about the Role-Based Service Configuration section of Security Configuration Wizard.

  • Select Server Roles
  • Select Client Features
  • Select Administration and Other Options
  • Select Additional Services
  • Handling Unspecified Services
  • Confirm Service Changes


Select Server Roles

Server roles describe the main function or functions performed by a server in your organization. Server roles must have role-specific services enabled. Security Configuration Wizard (SCW) enables services that are necessary for the selected server to perform the server roles that you select on this page and disables and unnecessary services for those roles.

By selecting a role, you automatically select all of its dependent roles.

You can use the Back and Next buttons throughout SCW to look ahead or go back and change a setting. If a role you want is not installed, and it is not in the Security Configuration Database, then it will not appear in the All roles view or any other view.

Notes

  • It is not recommended to select the Routing and Remote Access Server (RRAS) role, Internet Security and Acceleration (ISA) role, and Internet Connection Sharing (ICS) task to be enabled on the same server when configuring the SCW policy. At most, one of the three roles should be selected to ensure conflicts do not arise with the resultant network security policy.
  • If an SCW security policy is applied to a server before Internet Information Services (IIS) is installed, the server will be configured with the Hypertext Transport Protocol (HTTP) Secure Sockets Layer (SSL) service disabled, as HTTP SSL is not required on a computer that is not a Web server. In order for IIS to be active, the HTTP SSL service must first be started, as IIS cannot run without the HTTP SSL service. The Administrator must first ensure that both the HTTP SSL and IIS services have been started in order for SCW to detect IIS.
  • To see services and other server roles that are required for a specific role, click the triangle next to the server role. SCW lists a description of the role, required services, and dependent server roles.
  • When you edit an existing policy, the settings are determined by the policy that is being edited, not by the state of the computer running SCW.
  • When you are using SCW to apply policy, a selected check box means the associated service will be enabled and ports may be opened. You may block them later in SCW. A cleared check box means the service will be disabled, and the ports will be blocked.
  • The role selections made here affect other choices throughout SCW. For example, if you chose a domain controller server role, only options that are appropriate for a domain controller appear later.
  • If you create a policy and select an uninstalled role, and you subsequently edit that policy and the role is still not installed, then the previously selected role will not be selected during edit mode. You will have to select that role again from the list of uninstalled roles if you want it to be selected. This design facilitates the common task of editing a policy that was originally created on a server that has since been reconfigured.
  • When the cluster server role is selected, SCW makes no changes to the startup mode for cluster-aware services.
  • When you configure servers in an environment where redirection is used, as in a server cluster, you should use IP addresses rather than Domain Name System (DNS) names to specify servers.
  • When you create a policy for servers that require the Distributed Transaction Coordinator (DTC) service, the Middle-Tier application server role should be selected on the Select Server Roles page of SCW.

You can change the view in which server roles are presented. By default, installed server roles are shown. These are server roles that the selected server can perform without installing additional components. If you are creating a new security policy, the roles that the server currently performs are selected by default. If you are editing an existing security policy, the roles enabled by the policy are selected by default. You can view all server roles in the Security Configuration Database by changing the view to All server roles. To enable the services that are necessary for the selected server to perform its installed server roles, select the appropriate server roles in the list. If you plan to install other server roles on the selected server or if you are going to apply this security policy to other computers that have slight differences in role configuration, in View, select All server roles and select the appropriate server roles.

For more information about the Security Configuration Database, see Security Configuration Database.


Select Client Features

Servers can be clients of other servers. Client features must have role-specific services enabled. Security Configuration Wizard (SCW) enables services that are necessary for the selected server to perform the client features that you select on this page. Unnecessary services are disabled. By default, only the client features that the selected server can perform without installing additional components are displayed. You can view all client features in the Security Configuration Database by changing the view to All client features.

To enable the services that are necessary for the selected server to perform its installed client features, select the appropriate client features in the list. If you plan to install other client features on the selected server or if you are going to apply this security policy to other computers that have slight differences in role configuration, in View, select All client features and select the appropriate client features.

Note

  • To see the services and ports that are required for a specific role, click the triangle next to the client feature. SCW lists a description of the role and the required services and ports.

For more information about the Security Configuration Database, see Security Configuration Database.


Select Administration and Other Options

On this page, you can choose administration options such as remote administration and backup, as well as other application options and Windows features that use services and ports.

Security Configuration Wizard (SCW) enables those services that are necessary for the server, based on the roles that you select in the Select Server Roles section. Unnecessary services are disabled, and if you configure Network Security, unneeded inbound ports are blocked. Select the administration and other options that the selected server performs, that other servers to which you intend to apply this security policy perform, or that you plan to have the selected server perform.

Any option that depends on roles that were not previously selected is automatically excluded from the list and does not appear.

For more information about server roles, see Select Server Roles.


Select Additional Services

The selected server might perform roles that map to installed services that are not found in the Security Configuration Database, and thus do not appear on any of the previous pages. If this is the case, the Security Configuration Wizard presents a list of installed services on the Select Additional Services page. Unlike the previous pages, there is only one view for this page.

Click the triangle between the check box and the service name for more information about the service. Just as in previous pages, you can examine each additional service and decide if it needs to run for the selected server (or for other servers to which you intend to apply the policy) to perform as desired. If the service is not required, confirm that the check box is cleared. If the service is required, select the check box and click Next.


Handling Unspecified Services

It is recommended to configure services on this page if you intend to do one of the following:

  • Apply the security policy to servers other than the selected server.
  • Apply the security policy to the selected server after the selected server configuration has changed (for example, if new software was installed).

Unspecified services are services that do not appear in the Security Configuration Database and are not currently installed on the selected server, but might be installed on other servers to which you want to apply the security policy. They might also be installed on the selected server at some point in the future.

Any unknown service will appear in Security Configuration Wizard (SCW) under the Unspecified Services page.

Before you continue, you must decide how you want to handle these services. You can:

  • Leave the current startup mode of the service as it is. If you choose this option, unspecified services that are enabled on servers to which you apply this security policy remain enabled, and those that are disabled remain disabled.
  • Disable the service. If you choose this option, all services that are not in the Security Configuration Database or not installed on the selected server are disabled.

Important

  • The security policy disables any service on the server that is contained in the Security Configuration Database but was not present on the prototype server when the policy was created. For example, if the DCOM Server Process Launcher service is listed in the Security Configuration Database, but is not present on the prototype server, the security policy created based on the prototype server will set the DCOM Server Process Launcher state to disabled. When you apply the security policy to other servers, the DCOM Server Process Launcher service will be disabled on those servers. You can configure unnecessary services in the wizard (you can disable the service or leave the startup mode of the service unchanged), but only services that are not in the Security Configuration Database, and therefore are not defined in the security policy that you create with SCW.

For more information, see Select Additional Services.


Confirm Service Changes

On the Confirm Service Changes page, you see a list of all changes that this security policy would make to services on the selected server. The list compares the current startup mode of the service on the selected server to the startup mode defined in the policy. The startup mode can be Disabled, Manual, or Automatic. No changes are made to the selected server until the security policy is applied.

If one or more service changes are incorrect, you can modify these settings by changing your selections on previous pages. To determine which selection you must modify to have the desired result, see the Used by column, which lists the roles that require the service. Return to the page on which you configured that role and make the appropriate changes.

You can also sort the list of services by clicking the heading of the column that you want to sort.

Note

  • You can save, view, and print the entire security policy later on the Security Policy File Name page.

For more information, see Role-Based Service Configuration.


Configuring Network Security

Microsoft Windows graphic

Network Security

This section of Security Configuration Wizard (SCW) configures Windows Firewall. Advanced options in this section configure Internet Protocol security (IPsec).

Important

  • Configuring security using IPsec requires that the client machines also use IPsec.

Select the Skip this Section option if you do not want to change or configure security policy for Windows Firewall or IPsec.

Support for network security

SCW cannot configure network security for servers with the following multiple roles:

  • Internet Connection Sharing (ICS) Server
  • Internet Security and Acceleration (ISA) Server
  • Routing and Remote Access Server (RRAS)
  • Windows Small Business Server

These roles are excluded, by default, in the Security Configuration Database. For information about the Security Configuration Database, see Security Configuration Database.

Windows Firewall

Windows Firewall is the new version of the stateful packet filter in Windows Server 2003 with Service Pack 1. (It was originally introduced in Windows XP Service Pack 2.) The previous version was called Internet Connection Firewall. For more information on the firewall technologies, try both terms when you search in Help and Support Center on the local computer, or when you search the Microsoft Web site.

Note

  • Misconfiguring Windows Firewall can impair the functionality of services by blocking inbound traffic to services on the computer.

Internet Protocol security (IPsec)

Internet Protocol security (IPsec) is a feature that helps to ensure private, secure communications over Internet Protocol networks by using a policy. SCW helps you make remote address restrictions and local interface restrictions by using IPsec, but requires that you have a solid understanding of IPsec and the traffic that you want to secure or block. If you are not familiar with all of these items, then it is not recommended to use the Advanced button on the Open Inbound Ports page of SCW.

Note

  • SCW is not meant to create sophisticated Internet Protocol security (IPsec) policies for secure domain controller-to-domain controller communications, or to provide corporate-wide secure network segmentation or quarantine capabilities. SCW is meant to provide very simple port-level security, primarily on a corporate intranet where IPsec is not currently deployed.

For more information about IPsec, search for "Internet Protocol security" in Help and Support Center on a computer running a member of the Windows Server 2003 family, or see Internet Protocol security (IPSec).(http://www.microsoft.com/)

  • Opening Ports and Approving Applications
  • Adding Ports
  • Approving Applications
  • Restricting Remote Access Using IPsec
  • Restricting Local Interfaces
  • Adding an IP address or subnet
  • Authentication Methods
  • Confirming Port Configuration


Opening Ports and Approving Applications

Ports are virtual connections identified by numbers from 1 to 65535. Some applications or transmission protocols use fixed ports, for example port 22 is used for Secure Shell (SSH). Other protocols can use dynamically allocated ports.

With Security Configuration Wizard (SCW), you can secure or block inbound Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) traffic on a specific port. Alternatively, you can approve one or more applications, which allows those applications to manage their own ports. Approved applications open ports when they need them, and block those ports when the application terminates.

When you click Add on this page, you can either add a port or approve an application.

On the Open Ports and Approve Applications page, under View, you can filter the list of ports. The filter choices are:

  • All ports. Displays only the ports required by all the roles, administration options, and additional services that were selected in the earlier pages of the wizard; it is not merely a list of all ports from 1 to 65535. It also lists all approved applications, which open and close their own ports.
  • Restricted ports. Displays only ports that request or require security (encryption or signing), or have local or remote restrictions on traffic.
  • Unrestricted ports. Displays approved applications and all ports except for restricted ports.
  • Security required ports. Displays ports that only open for secure traffic.
  • Security requested ports. Displays ports that request security, but allow unsecured traffic.

This message Not Found! is shown if SCW cannot verify that an approved application exists at the specified path. This is not necessarily a problem, as you might be configuring a policy for a remote server. If the application will exist at the specified path at the time the policy is applied, the Not Found! message can be ignored. If the targeted remote computer has SCW installed on it, then SCW will find the approved application, and you will not see this message.

Each entry in the ports list is shown with a check box, a triangular arrow that you can click for more information about the port, and either the port number with a description or the application. Initially, the required check boxes are selected because the ports are presumed to be required, but you can clear the check boxes to block the ports. Optional ports, which might be needed for backward compatibility, are not selected by default.

You can add ports, edit port numbers and protocols, or remove ports with the Add, the Edit, and the Remove buttons. The buttons are available or unavailable as appropriate. For example, if port number and protocol are fixed, the Edit button is unavailable.

Use the Advanced button to create, or change, local or remote restrictions on a selected port.

Special ports open for the Domain Controller role

The ports 88/tcp (Kerberos), 88/udp (Kerberos), and 389/udp (LDAP) appear on the Open Ports page when the Domain Controller role is selected. These three ports cannot be secured by using SCW. Kerberos provides the authentication mechanism for IPsec, and LDAP provides the ability to locate the domain controllers that contain the participating accounts.

The multi-select feature

The Opening Ports and Approving Applications page allows you to select multiple ports at a time. This is convenient when you want the ports to have the same local address, remote address restrictions, or both. When you have finished working on the multiple selected ports, they will have the same local interface restrictions and the same remote address restrictions, regardless of their initial state.

If the local interface restrictions are the same for all selected ports, then those local interface restrictions are displayed by default. Otherwise, the local interface restrictions page is blank (having no default settings), indicating that some of the selected ports have different local interface restrictions.

If the remote address restrictions are the same for all selected ports, then those remote address restrictions are displayed by default. Otherwise, the remote address restrictions page is blank (having no default settings) indicating that some of the selected ports have different remote address restrictions.

Settings must be specified for both local interface restrictions and remote address restrictions before the OK button is available.

When you click OK, the specified local interface restrictions and the specified remote address restrictions completely replace any existing local interface or remote address restrictions for the selected ports.


Adding Ports

Complete this page if you want to add a port that is not already listed in SCW.

Usually it is recommended to approve an application rather than to add ports, because approved applications open ports as needed and block them upon exit.

Approve an application, rather than add a port, if the application uses dynamically allocated ports.

Note

  • The Add Port or Application dialog box lets you either add a port or approve an application.


Approving Applications

Fill in the Application path field if you want to approve an application in addition to the applications already approved by SCW. Approved applications can block and unblock their own ports.

The application path should resolve correctly on each targeted computer. An application without a path is accepted, but a warning appears. You can use the Browse button to find the application. In that case, file system paths will be used for the local computer, and Universal Naming Convention (UNC) paths will be used for applications on the network.

Use environment variables to maximize the portability of the application path. Supported environment variables include %PROGRAMFILES%, %WINDIR%, and %SYSTEMROOT%.

Type of path | Application path example
UNC | \\NorthWind\Traders\Nwteb.exe
File system, with environment variable | %PROGRAMFILES%\Nwteb.exe
File system, full | C:\WINNT\System32\Nwteb.exe
No path specified (accepted with a warning) | Nwteb.exe
File system, relative (not recommended) | NWTraders\nwteb.exe

Note

  • The Add Port or Application dialog box lets you either add a port or approve an application.


Restricting Remote Access Using IPsec

You can make security restrictions on inbound TCP or UDP network traffic for each port, based on the IP address that the traffic originates from.

Security restrictions

The security restrictions can be any of the following:

  • Permit all traffic (no restrictions). Removes all restrictions. This is the least secure option.
  • Request signing. Traffic is accepted even if it is not signed.
  • Require signing. This is the safest way to ensure the sender's identity. However, if the sender cannot comply with the protocol, then you cannot receive the message.
  • Request encryption. Traffic is accepted, even if it is not encrypted.
  • Require encryption. This is the safest option for hiding the inbound data stream from unauthorized access. But if the sender cannot comply with the protocol, then you cannot receive the message.
  • Accept unsigned and unencrypted. This option is explained in detail below.

Accept unsigned and unencrypted

The Accept unsigned and unencrypted option is recommended to simplify IPsec deployment on internal corporate networks. When this option is selected, all clients that need to communicate with the server over the secured port can be configured with the same IPsec default response rule. (For information about using the default response rule, see “Default IPSec policies” on the Microsoft Web site (http://www.microsoft.com/).) In this mode of operation, clients initiate communication with the server in the clear. When the server recognizes that the traffic should be secured, the server initiates IKE (Internet Key Exchange) back to the client. If the client has the default response rule active, it automatically creates the necessary IPsec filters to communicate securely back to the server.

The Accept unsigned and unencrypted option is not recommended for servers that are exposed to the internet because it might leave the server vulnerable to denial of service attacks. In this type of attack, anonymous clients on the Internet bombard the server with unsecured requests that cause the server to unsuccessfully try and negotiate security back to the anonymous clients. This wastes resources on the server. A denial of service attack is mitigated if you request or require security only with specific internal addresses or subnets rather than requesting or requiring security with any IP and you have a perimeter filtering router that prevents Internet clients from spoofing your internal corporate IP addresses.

If you do not accept unsigned and unencrypted inbound traffic, then you must create peer IPsec policies on all clients that need to communicate securely with server. For example, if you require encryption for Port 3389 between Server X and an internal management Subnet Y, SCW will establish the following IPsec rule on the server:

Source Address | Destination Address | Source Port | Destination Port | Action | Mirrored
Any | Me | Any | 3389 | Block | No
Subnet Y | Me | Any | 3389 | Negotiate | Yes

If you do not accept unsigned and unencrypted inbound traffic, then each client on management Subnet Y must be configured with the following IPsec rule:

Source Address | Destination Address | Source Port | Destination Port | Action | Mirrored
Me | Server X | Any | 3389 | Negotiate | Yes

This client-side IPsec rule causes security to be established as part of the client’s initial communication to Server X.

If Kerberos is used with the Accept unsigned and unencrypted option, then there must be a bidirectional Kerberos trust between the client’s domain and the server’s domain.

Specifying remote IP addresses

The remote IP addresses can be specified in any of these ways:

  • One static IP address. For example, 172.30.160.169.
  • A range of IP addresses, indicating a subnet. An example might be 10.53.0.0/255.255.0.0.
  • Computer name. This is only an input convenience. The name must resolve immediately to an IP address, or it will not be accepted.
  • All IP addresses. The restrictions you choose apply to all IP addresses.
  • Free form. This is a sequence of static IP addresses and subnets separated by semicolons. An example might be 172.30.160.169;10.53.0.0/255.255.0.0.


Restricting Local Interfaces

If the computer has more than one network adapter, you can open a port on all adapters or only on some. Each adapter is listed by interface name, such as Local Area Connection. SCW displays the IP address that is assigned to each interface and whether the address was assigned by a Dynamic Host Configuration Protocol (DHCP) server.

If you do not want the port opened on all interfaces, select Over the following network interfaces, and then clear the check boxes of the interfaces for which the port should be blocked.

If remote and local address restrictions are specified for a port, then both restrictions will be enforced by IPsec. In this case, the local interface globally unique identifiers (GUIDs) are resolved to the IP addresses assigned to those GUIDs. Therefore, do not set local and remote restrictions when local interfaces have DHCP-assigned addresses.


Adding an IP Address or Subnet

Use the Add IP Address or Subnet dialog box to specify remote address restrictions on this port.

There are five ways of specifying remote addresses:

  • IP address. For example, you can specify 172.30.160.169.
  • Computer name. This is only an input convenience. The name must resolve immediately to an IP address, or it will not be accepted.
  • Subnet. For example, you can specify 10.53.0.0/255.255.0.0.
  • All IP addresses. If you choose this option, any restrictions on the port will apply to all inbound traffic, regardless of the IP address that it came from.
  • Free form. Choose this option if you want to enter a list of IP addresses and subnets separated by semicolons. For example, 10.53.0.0/255.255.0.0;172.30.160.169;172.30.160.170.


Authentication Methods

If you chose to secure communication between trusted servers, you must establish a method. These computers must authenticate to each other to establish trust. You can choose to use:

  • Kerberos authentication. With Kerberos authentication, the selected server and the trusted computer authenticate to each other by using their domain computer accounts. If the selected server and the trusted computer are not members of the same domain, or domains that have a trust relationship, authentication will fail. Kerberos authentication is the most secure option of the three methods.
  • Certificates. With certificate authentication, the selected server and the trusted computer each must have a certificate installed issued by the same certification authority (CA). If you select this option, you must also choose the CA that you want the computers to use. You must choose the same CA on both computers or authentication will fail.
  • Preshared Key. With preshared key authentication, you enter a key in Preshared key value. The same key must be entered for both the selected server and the trusted computer with which you want it to communicate. This is the least secure option and should only be used for testing purposes.

You must select an authentication method before you can continue.


Confirming Port Configuration

This page summarizes Security Configuration Wizard (SCW) input to this point, including the resulting port configuration settings.

The following table describes each column in the list. The list can be sorted by clicking the column headings in SCW.

Heading | Description
Port | The port number with the port name in parentheses or the application if the application is approved.
Protocol | Either TCP or UDP. Two lines are used if both protocols are listed.
Status | Set to Open if the port is explicitly open, Approved if the application is on the approved list, or Blocked if the port is blocked.
Security Options | List of remote address restrictions or blank, if none. For example, Security required on 172.20.0.1, or Security requested on 10.53.0.0/255.255.0.0.
Restrictions | List of local interface restrictions, given in terms of network adaptor name and IP address in parentheses, or blank if none. For example, Accessed over Internal LAN (10.10.1.5), External LAN (172.16.8.1).

After you verify the settings, click Next to continue with the Registry section of SCW.


Registry Settings

This section provides general background information about the Registry Settings section of Security Configuration Wizard.

  • Require SMB Security Signatures
  • Require LDAP Signing
  • Outbound Authentication Methods
  • Outbound Authentication Methods Using Domain Accounts
  • Outbound Authentication using Local Accounts
  • Inbound Authentication Methods
  • Registry Settings Summary


Require SMB Security Signatures

On this page, you supply information about the selected server and the clients with which it communicates.

Registry subkey

  • HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature

Associated security setting

  • Microsoft network server: Digitally sign communications (always)

Providing inaccurate information might disrupt communication between the selected server and other computers on the network.

For more information about this security setting, see Microsoft network server: Digitally sign communications (always).(http://www.microsoft.com/)


Require LDAP Signing

On this page, information is gathered about the other computers in the domain controller's domain.

Registry subkey

  • HKLM\System\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity

Associated security setting

  • Domain controller: LDAP server signing requirements

Providing inaccurate information might disrupt communication between the selected domain controller and other computers on the network.

For more information about this security setting, see Domain controller: LDAP server signing requirements.(http://www.microsoft.com/)


Outbound Authentication Methods

On this page, information is gathered about the accounts used by the selected server to authenticate to other computers.

Clear the check boxes for unneeded authentication methods.

Registry subkey

  • HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel

Associated security setting

  • Network security: LAN Manager authentication level

Providing inaccurate information might disrupt communication between computers on the network.

For more information about this security setting, see Network security: LAN Manager authentication level.(http://www.microsoft.com/)


Outbound Authentication Methods Using Domain Accounts

On this page, information is gathered about the domain controllers in the domain and trusted domains of the selected server.

Registry subkey

  • HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel

Associated security setting

  • Network security: LAN Manager authentication level

Providing inaccurate information might disrupt communication between computers on the network. All domain controllers containing domain accounts used to connect to other computers mast have clocks that are synchronized with the selected server's clock. Domain controllers running Windows 2000 Server with Service Pack 4 or earlier must have clocks within 30 minutes of the selected server's clock.

For more information about this security setting, see Network security: LAN Manager authentication level.(http://www.microsoft.com/)


Outbound Authentication using Local Accounts

On this page, information is gathered about the computers used by the selected server to authenticate to other computers.

Registry subkey

  • HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel

Associated security setting

  • Network security: LAN Manager authentication level

Providing inaccurate information might disrupt communication between computers on the network. All computers that the selected server connects to by using local accounts must have clocks that are synchronized with the selected server's clock. Computers running Windows 2000 with Service Pack 4 or earlier must have clocks within 30 minutes of the selected server's clock. Computers running Windows XP must have clocks within 36 hours of the selected server's clock.

For more information about this security setting, see Network security: LAN Manager authentication level.(http://www.microsoft.com/)


Inbound Authentication Methods

On this page, information is gathered about the computers from which users might try to authenticate to the selected server.

Clear the check boxes for unneeded authentication methods.

Registry subkeys

  • HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  • HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

Associated security settings

  • Network security: LAN Manager authentication level
  • Network security: Do not store LAN Manager hash value on next password change

Providing inaccurate information might disrupt communication between computers on the network.

For more information about these security settings, see

  • Network security: LAN Manager authentication level.(http://www.microsoft.com/)
  • Network security: Do not store LAN Manager hash value on next password change.(http://www.microsoft.com/)

For domain controllers only

An additional option appears when you create policy for domain controllers:

Users with accounts in this domain need to access member servers from: Computers using RAS or VPN to connect to RAS servers that are not running Windows Server 2003 Service Pack 1 or later.

Servers running remote access service and Internet Authentication Service (IAS) require Windows Server 2003 Service Pack 1 (SP1) and, by default, support for PEAP-MSCHAPv2 authentication only in order to authenticate users with domain controllers that accept only NTLMv2.

Servers running IAS (or RADIUS) and Routing and Remote Access use NTLMv1 to authenticate their clients' domain credentials. This means domain controllers that need to authenticate those clients cannot be configured to accept only NTLMv2 authentication. However, starting with Windows Server 2003 SP1, it is possible for a domain controller to accept NTLMv1 from servers running IAS and remote access service but NTLMv2-only for all other authentication requests. This happens by default for servers running remote access service and IAS and use PEAP-MSCHAPv2 and run on Windows Server 2003 with SP1 because PEAP-MSCHAPv2 offers security protection equivalent to that of NTLMv2. This exemption does not happen by default if the server running IAS and remote access service on Windows Server 2003 with SP1 uses PPP-MSCHAPv2 to authenticate clients.

To prevent this default exemption for servers running IAS and remote access service on Windows Server 2003 with SP1, the following registry entry can be set on the domain controller:

HKLM\System\CurrentControlSet\LSA\DisallowMsvChapv2

If this registry entry has been set on the domain controller and the domain controller is configured to accept NTLMv2 only, then the domain controller will not be able to authenticate IAS and remote access clients even if all servers running IAS and remote access service are running on Windows Server 2003 with SP1. Therefore, if the DisallowMsvChapv2 registry entry has been set on the domain controller and the domain controller needs to authenticate IAS and remote access clients, then this option that is specific to domain controllers must be selected, even if all servers running IAS and remote access service are running on Windows Server 2003 with SP1. Because selecting this option prevents the domain controller from being configured to accept NTLMv2 only, it is recommended that DisallowMsvChapv2 registry entry instead not be set.


Registry Settings Summary

The Registry Settings Summary page provides you with the opportunity to see all of the changes that this security policy would make to specific registry settings if applied to the selected server. Security Configuration Wizard (SCW) shows the current setting for each registry value and the setting value defined by the policy. No changes are made to the selected server until you apply the security policy.

If one or more registry setting changes are incorrect, you can modify these settings by changing your selections on previous pages in this section. To determine which selection you need to modify to have the desired result, look at the Registry Value column. The registry value that is modified by your selections is listed on the bottom of each page of this section. Return to the page on which you configured the setting and make the appropriate changes.

Named pipe firewall behavior

Under certain circumstances, SCW will set the following registry value:

Registry subkey:

  • HKLM\System\CurrentControlSet\Services\LanmanServer\ParametersPipeFirewallActive

When PipeFirewallActive is set to 1, the server service will block access to all named pipes except for those listed in the following registry value:

Registry subkey:

  • HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\AllowedPipes

By default, the list of allowed pipes consists of those named pipes that are necessary for the server to function solely as a file or print server: spoolss, browser, wkssvc, and srvsvc.

The circumstances under which SCW sets PipeFirewallActive to 1 are as follows:

  • The registry value section is not skipped.
  • The File Server role or Print Server role was selected.
  • No other role or option that requires the LanmanServer service was selected.
  • There were no non-default pipes discovered on the target server.

To prevent SCW from configuring the PipeFirewallActive registry value, search for the ConfigureNamedPipeFirewall element in the W2K3.xml knowledge base file (%WINDIR%\Security\Msscw\Kbs) and change the value of the ConfigureNamedPipeFirewall element from TRUE to FALSE.


Audit Policy

This section provides general background information about the Audit Policy section of Security Configuration Wizard.

  • System Audit Policy
  • Audit Policy Summary


System Audit Policy

You can use this section to create an audit policy for servers in your organization. Auditing is the process that tracks the activities of users and records selected types of events in an event log. An audit policy defines the types of events that you want to collect. For more information about auditing, see Auditing Security Events on the Microsoft web site. (http://www.microsoft.com/)

Collecting and monitoring audit events consumes disk space and other resources. Before selecting an audit policy, review Best practices for auditing on the Microsoft web site. (http://www.microsoft.com/)

The following table describes each of the three audit policy objectives that you can select with Security Configuration Wizard.

Audit policy objective Description Audit event category settings
Do not audit No auditing is performed. Central processing unit (CPU) cycles and disk space is spared so that other processes can have better performance.

Caution

  • No audit information will be available to detect intruders, to find unauthorized access attempts, or for any other purpose.
None
Audit successful activities Auditing successful activities results in fewer event log entries than auditing both successful and unsuccessful activities. Use this option to record only what users actually access, not what they try to access.

Note

  • If you only audit successful activities, then unauthorized intrusion attempts will not appear in the log. Unauthorized intrusion attempts are characterized by large numbers of unsuccessful activities.

Audit system events: Success, Failure

Audit logon events: Success, Failure

Audit object access: Success

Audit privilege use: Not audited

Audit policy change: Success

Audit account management: Success

Audit process tracking: Success

Audit directory service access: Success

Audit account logon events: Success, Failure

Audit successful and unsuccessful activities This means that you intend to use audit events to track the attempts of users to gain access to areas for which they are not authorized, in addition to tracking successful task completion.

Note

  • Do not select Audit successful and unsuccessful activities unless you review security logs regularly. If users attempt to access a resource for which they are not authorized, they can create so many failure audits that the security log becomes full. When the security log is full, the oldest audit entries are overwritten.

Audit system events: Success, Failure

Audit logon events: Success, Failure

Audit object access: Success, Failure

Audit privilege use: Not audited

Audit policy change: Success, Failure

Audit account management: Success, Failure

Audit process tracking: Success, Failure

Audit directory service access: Success, Failure

Audit account logon events: Success, Failure

For more information, see:

  • Auditing Policy on the Microsoft Web site. (http://www.microsoft.com/)
  • Auditing Security Events on the Microsoft Web site. (http://www.microsoft.com/)


Audit Policy Summary

This page provides a list of all of the changes that will be made to the audit policy on the selected server if you apply the policy. It shows the current setting for each audit policy setting and the setting defined by the policy. No changes are made to the selected server until you apply the security policy.

If you would like to change the resulting audit policy, you can return to the previous page and choose one of the other two audit policy options on the System Audit Policy page.

SACLs and Rollback

In ASCaudit.inf, the auditing security template that is provided with Security Configuration Wizard (SCW), the system access control lists (SACLs) aid in the detection of tampering or attempted tampering to the operating system. These SACLs enable the system to record write access by any user to any executable or configuration files in the Windows directory structure, and changes to the state or configuration of Windows services. The SACLs do not cause Windows to monitor files and directories that are primarily used for other purposes, and they generate as few logged events as possible, so that they do not overwhelm administrators. However, application of a service pack, restoring information from a backup, or changing permissions on all or part of the Windows directory could result in a large number of events being generated.

The SCW rollback feature does not include the ability to roll back SACLs. Therefore, the Audit Policy Summary page gives you the option of not applying the ASCAudit.inf security template.

To get a detailed look at the file system and registry SACLs defined in ASCAudit.inf, you can open it in the Security Templates snap-in. ASCAudit.inf is located in %WINDIR%\Security\Msscw\Kbs.

Another security template, DefaultSACLs.inf, is also provided. It allows you to re-apply the default SACLs, in case ASCAudit.inf causes bad behavior. Note that the original Windows new-installation default SACLs that are applied, not the SACLs that were in effect before you applied ASCAudit.inf. To apply DefaultSACLs.inf, type the following at a command prompt:

secedit /configure /cfg DefaultSACLs.inf /db DefaultSACLs.sdb

For more information, see:

  • System Audit Policy
  • Auditing security events on the Microsoft web site(http://www.microsoft.com/)


Internet Information Services

This section provides general background information about the Internet Information Services (IIS) section of Security Configuration Wizard.

  • Enable your Web server to serve dynamic content
  • Retain existing virtual directories
  • Prevent anonymous access to Web site content
  • IIS Settings Summary

To skip the IIS section, return to the Internet Information Services page and select Skip this section.


Enable Your Web Server to Serve Dynamic Content

On this page, you specify which types of dynamic content can be served by your Web server.

By default, as a security measure, Internet Information Services (IIS) 6.0 serves only static content, for example, .htm or .html files. If your Web server serves dynamic content such as Active Server Pages (ASP) or FrontPage® server extensions, you must enable the appropriate Web service extension to permit that content to be served. For security reasons, IIS 6.0 allows you to enable and disable individual Web service extensions, so only those extensions that are required by your content are enabled.

A Web service extension is a request handler for a specific content type. For example, when a Web server receives a request for Active Server Pages (ASP) content, a Web service extension is called to serve the ASP content to the client's browser.

For security reasons, IIS 6.0 allows you to enable and disable individual Web service extensions, so only those extensions that are required by your content are enabled.

Important

  • It is not recommended to enable all Web service extensions. Although doing so may provide compatibility with existing Web sites and applications, this configuration would increase the attack surface of your Web server. It is recommended to enable only the Web service extensions that are necessary for proper functionality of your Web sites and applications.


Retain Existing Virtual Directories

On this page, you choose whether to retain or remove virtual directories that are configured on your Web server.

A virtual directory is a friendly name or alias, either for a physical directory on your server hard drive that does not reside in the home directory, or for the home directory on another computer. Aliases make it easier for you to move directories in your site. Rather than changing the URL for the directory, you change the mapping between the alias and the physical location of the directory.

Important

  • If you are performing remote scans of IIS 6.0 servers, you must ensure that the IIS 6.0 Common Files are installed on the local computer–that is, the server on which SCW is installed. If these files are not present, you might see the following error when you attempt to scan a remote computer: “Connection to IIS Base Admin COM object could not be established” (error code 0X80070005 in the log), which indicates that access was denied by the remote computer running IIS.

The following table describes the common virtual directories that may be present on your Web server.

Virtual Directory | Description
IISAdmin | Contains scripts for remote administration of Internet Information Services (IIS). You should remove this directory if you do not intend to administer your Web server remotely. If you intend to administer your Web server remotely, you should rename this directory.
IISHelp | Contains help files with sample Web pages and scripts for instructional use only. These files should not be present on a production Web server. If you want to keep these files, install them on a Web server that is used for testing purposes only.
IISSamples | Contains sample Web pages and scripts for instructional use only. These samples should not be present on a production Web server. If you want to keep the samples, install them on a Web server that is used for testing purposes only.
MSADC | Supports Web-based database operations that use Microsoft Advanced Data Connector and Remote Data Services (RDS). Web-based database services can be vulnerable to attack unless they are securely deployed. This virtual directory should be removed unless you use RDS on this server to bridge Web clients to your database server.
Scripts | Contains scripts and is created by default. You should remove this virtual directory if your site does not require scripts. If your site requires scripts, consider moving them to a directory with a unique name to protect against automated attacks that blindly target the Scripts directory.


Prevent Anonymous Access to Web Site Content

On this page, you choose whether to allow anonymous users write access to the content on your Web site.

Anonymous access, the most common Web site access control method, allows anyone to visit the public areas of your Web sites. However, you might configure the site to prevent anonymous users from viewing sensitive information such as employee data.

If you select Deny anonymous users write access to content files now, when the SCW policy is applied, all files in the virtual directories will be denied write access for anonymous users.


IIS Settings Summary

The IIS Settings Summary page provides you with the opportunity to see all of the changes that this security policy will make to specific Internet Information Services (IIS) settings on the selected server. The Security Configuration Wizard shows the current setting for each IIS setting and the setting value defined by the policy. No changes are made to the selected server until you apply the security policy.

If one or more of the IIS setting changes are incorrect, you can modify these settings by changing your selections on the previous pages.


Completing Security Configuration Wizard

This section provides links to information about saving and applying the security policy created or edited with Security Configuration Wizard (SCW).

Saving security policies

Choose a location and a file name with an .xml extension for saving the security policy. You can save it on the local hard disk, or in a network shared folder, in a location accessible to administrators who will run SCW to apply the policy.

  • Include Security Templates
  • Apply Security Policy
  • Troubleshooting


Include Security Templates

Security policies that are created with Security Configuration Wizard (SCW) include some, but not all, possible security policy settings. You can use this dialog box to include a security template with your security policy. This allows you to include settings in addition to those set by SCW. If any template settings conflict with the settings being applied by SCW, then the SCW settings take precedence.

Related Topics


Apply Security Policy

You can apply a security policy immediately after creating or editing by selecting Apply now on this page. If you want to make changes to the policy, or if you do not want to apply the security policy to the selected server, select Apply later on this page. If you choose to apply the policy later, no changes are made to the selected server. When you want to apply the security policy, run Security Configuration Wizard (SCW) and, on the Configuration Action page, choose the Apply an existing security policy option. Alternatively, you can use the Security Configuration Wizard command-line tool to apply the security policy.

Restarting a server (rebooting) after applying security policy

After SCW security policy is applied to a server, it may be necessary reboot that server.

For the following services to be disabled, you must restart the selected server after applying the SCW policy:

  • Windows Audio
  • Application Management
  • Terminal Services

After applying the policy, the startup mode changes. However, these services continue to run until the computer is restarted.

If the security policy configures exceptions for applications or services (that is, the security policy adds them to the allowed exceptions list) and those applications or services were running before Windows Firewall was started, the computer will have to be restarted for these applications and services to run properly. For more information on approving applications, see Approving Applications.

If the security policy applies to services that are not found in the Security Configuration Database, and which therefore were entered in the Select Additional Services or the Handling Unspecified Services pages of SCW, then the selected server must be rebooted for the applied policy to take effect.


Troubleshooting

This section lists some error messages and suggestions for handling them, as well as some basic requirements for using Security Configuration Wizard (SCW).

Running Security Configuration Wizard

SCW is supported on members of the Windows Server 2003 family with Service Pack 1 only.

Applying Security Configuration Wizard security policy

The security policies that are created with SCW should only be applied to servers and groups of servers. They should not be applied to client operating systems such as Microsoft® Windows® XP.

Internet Information Services (IIS) role not being detected by SCW

If an SCW security policy is applied to a server before IIS is installed, the server will be configured with the Hypertext Transport Protocol (HTTP) Secure Sockets Layer (SSL) service disabled, as HTTP SSL is not required on a computer that is not a Web server. If IIS is then installed on the server and SCW is run, the Administrator must first ensure that IIS is started, in order for IIS to be detected by SCW. IIS cannot run without the HTTP SSL service.

Error messages

Cannot Process XML Data

  • The Microsoft XML core services are corrupted or not installed.

Cannot Process Security Configuration Database

  • There is a problem with Main.XML. Check the Application log, which might have more information.

The Security Configuration Wizard cannot continue because the security configuration database processing failed.

  • There is a problem with Main.XML. Check the Application log, which might have more information.

You do not have administrator privileges on the selected server. Click Specify User Account to provide an administrator account on the selected server.

  • You must be an administrator on the local server to run SCW, or you must specify Administrative credentials on a remote server. If you are trying to apply a policy to a server, then the policy must be available on the server running SCW. You must also be authenticated as an administrator on the computer that is receiving the policy.

Cannot Rollback Last Applied Security Policy

  • Check the Application log, which might have more information.

The selected security policy file has a format that is not valid. Select another security policy file and try again.

  • You can receive this message if you browse to, or type in, an XML file that is not a security policy file. If this is a security policy file that you created, try running SCW again to recreate it.

Not Found!

  • In the Network Security section of SCW, this message is shown if SCW cannot verify that an approved application exists at the specified path. This is not necessarily a problem, as you may be configuring a policy for a remote server. If the application will exist at the specified path at the time the policy is applied, the Not Found! message can be ignored.

Cannot determine the IP address from the computer name. The lookup service is not available.

  • In the Network Security section of SCW, the IP address of the computer name you entered must be resolvable, or you cannot continue. If the computer has a static IP address (not assigned by DHCP), then you can enter the IP address instead of the name.