Security Configuration Wizard

The Security Configuration Wizard (SCW) guides you through the process of creating, editing, applying, or rolling back a security policy. A security policy that you create with SCW is an .xml file that, when applied, configures services, network security, specific registry values, and audit policy. SCW is a role-based tool: you can use it to create a policy that enables services, firewall rules, and settings that are required for a selected server to perform specific roles, such as a file server, a print server, or a domain controller.

The following are considerations for using SCW:

  • SCW disables unnecessary services and provides Windows Firewall with Advanced Security support.

  • Security policies that are created with SCW are not the same as security templates, which are files with an .inf extension. Security templates contain more security settings than those that can be set with SCW. However, it is possible to include a security template in an SCW security policy file.

  • You can deploy security policies that you create with SCW by using Group Policy.

  • SCW does not install or uninstall the components necessary for the server to perform a role. You can install role-specific components through Server Manager.

  • SCW detects role dependencies. If you select a role, it automatically selects dependent roles.

  • All applications that use the IP protocol and ports must be running on the server when you run SCW.

  • In some cases, you must be connected to the Internet to use the links in SCW Help.

Additional references

  • Starting the Security Configuration Wizard

  • Role-Based Service Configuration

  • Network Security

  • Registry Settings

  • Audit Policy

  • Completing the Security Configuration Wizard


Starting the Security Configuration Wizard

In the Welcome to the Security Configuration Wizard section of the Security Configuration Wizard (SCW), you can select which action to take for a security policy, select the server to use, and manage the Security Configuration Database.

  • Configuration Action

  • Select Server

  • Managing the Security Configuration Database


Configuration Action

With the 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 function as expected.

SCW includes a command-line tool, Scwcmd, that you can use to perform various tasks. For more information, see http://go.microsoft.com/fwlink/?LinkId=92612.

Creating a new security policy

You can create a security policy that configures services, Windows Firewall with Advanced Security, audit policy settings, 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 command-line tool. Once you have started SCW, you do not need to complete all sections in the same session. To skip sections, select the Skip this section check box at the beginning of each uncompleted section, save the policy, and use SCW to edit the policy later. If you select the Skip this section check box after configuring part of a section, your changes are not saved or applied. 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 click 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 on a network. You can use SCW to edit policies with an .xml file name extension. Security templates with an .inf extension cannot be edited with SCW.

Manually editing the 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 or to your production environment. You can use the Scwcmd command-line tool to apply the same policy to multiple servers. You can use the scwcmd transform command to create GPOs. Only security policies in .xml format can be applied with SCW.

If the selected server is a member of an Active Directory domain, then the domain-based GPO security policy generally overrides registry settings that were set directly through SCW. To prevent this, you can create a GPO by using scwcmd transform and apply the GPO through Active Directory Domain Services (AD DS).

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.

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 cannot be rolled back and will 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 with Advanced Security, the process of rolling back removes any SCW policy that is currently in place and applies the previous policy that was in place at configuration time.

Additional references

  • Starting the Security Configuration Wizard


Select Server

The Select Server page allows you to choose a server based on your choice on the 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 the 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 the 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 when the policy was most recently edited is selected by default.

The 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 multiple servers that are 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 your organization has multiple file servers, 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.

You must be a member of the local Administrators group on the selected server to apply a security policy.

Additional references

  • Starting the Security Configuration Wizard


Managing the Security Configuration Database

The Security Configuration Database consists of a set of .xml files that list services and ports that are required for each server role that is supported by the Security Configuration Wizard (SCW). These files are installed in %systemroot%\security\ssscw\kbs. After you select a server, 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. SCW displays Main.xml if you click View Configuration Database on the Processing Security Configuration Database page.

Centralizing the Security Configuration Database

You may want to maintain the Security Configuration Database in a central location that can be used throughout your organization. This allows local administrators in multiple locations to use the same Security Configuration Database. SCW.exe accepts a command-line argument for the centralized database location.

To specify a centralized configuration database, run the following command at a command prompt:

scw.exe /kb SCWKBDirectoryLocation

For example, two possible commands are:

scw.exe /kb \\securityserver\scwkb

scw.exe /kb k:\

Note

The local administrator who runs SCW must have at least Read permission to the remote Security Configuration Database directory. In non-domain environments, the local administrator may need to provide credentials in order to access the centralized server. This can be accomplished by first establishing a connection to the server. For example, you might use the following command: Net use k: \\securityserver\scwkb /u:securityserver\User1

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

Additional references

  • Starting the Security Configuration Wizard


Role-Based Service Configuration

In the Role-Based Service Configuration section of the Security Configuration Wizard (SCW), you can configure services based on the roles and features of the selected server.

  • 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. For example, a domain controller performs the Domain Controller server role. Server roles must have role-specific services enabled. The Security Configuration Wizard (SCW) enables services that are necessary for the selected server to perform the server roles that you select on this page. Unnecessary services are disabled.

When you select a role, all dependent roles are selected automatically. You do not have to select dependencies manually.

If a role that you want to select is not available, then consider selecting a broader role that would include the role that you want. The role you want to select might be a client feature or an administration option. Then you can select it on later pages in the wizard. If a role you want is not installed, and it is not in the Security Configuration Database, then it will not appear in any view.

Additional considerations

  • 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 a policy, a selected check box indicates that the associated service will be enabled. A cleared check box indicates that the service will be disabled.

  • The role selections made on this page affect other choices throughout the wizard. For example, if you select the Domain Controller server role, only options that are appropriate for a domain controller will 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 while you are editing the policy. 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 Failover Clustering server role is selected, SCW makes no changes to the startup mode for services that support clusters.

  • 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 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 plan to apply this security policy to other computers that have slight differences in role configuration, in View, click All roles, and then select the appropriate server roles.

Additional references

  • Role-Based Service Configuration

  • Managing the Security Configuration Database


Select Client Features

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

To enable the services that are necessary for the selected server to provide 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 will apply this security policy to other computers that have slightly different role configurations, in View, click All features, and then 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 firewall rules.

Additional references

  • Role-Based Service Configuration

  • Managing the 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.

The Security Configuration Wizard (SCW) enables the services that are necessary for the server based on the roles that you select on the Select Server Roles page. Unnecessary services are disabled, and if you configure settings in the Network Security section of SCW, unneeded firewall rules are removed. Select the administration options and any 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.

Additional references

  • Role-Based Service Configuration

  • Select Server Roles


Select Additional Services

The selected server might perform roles that require 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 you with a list of installed services on the Select Additional Services page. Unlike the previous pages, there is only one view for this page. (This is because the "installed additional services" and "all additional services" views would show the same list.)

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.

Additional references

  • Role-Based Service Configuration


Handling Unspecified Services

Use 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 is 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 in the future.

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

Before you continue, you must decide how you want to handle these services. The following options are available:

  • Do not change the startup mode of the service. 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.

Additional references

  • Role-Based Service Configuration

  • Select Additional Services


Confirm Service Changes

On the Confirm Service Changes page, you can 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 you apply the security policy.

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 indicates the role that requires 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.

Additional references

  • Role-Based Service Configuration


Network Security

In the Network Security section of the Security Configuration Wizard (SCW), you can add, remove, or edit rules concerning Windows Firewall with Advanced Security.

Windows Firewall with Advanced Security

Windows Firewall with Advanced Security combines a host firewall and Internet Protocol security (IPsec). Unlike a perimeter firewall, Windows Firewall with Advanced Security runs on each computer running Windows Server 2008 R2 or Windows Server 2008 and helps provide local protection from network attacks that might pass through your perimeter network or originate inside your organization. It also helps secure computer-to-computer connections by allowing you to require authentication and data protection for communications.

Windows Firewall with Advanced Security is a stateful firewall and inspects and filters all packets for IP version 4 (IPv4) and IP version 6 (IPv6) traffic. By default, incoming traffic is blocked unless it is a response to a request by the host (solicited traffic) or it is specifically allowed (that is, a firewall rule has been created to allow the traffic). You can explicitly allow traffic by specifying a port number, application name, service name, or other criteria by configuring Windows Firewall with Advanced Security settings.

SCW provides support for the new Windows Firewall with Advanced Security but IPsec configuration is not possible through SCW.

Note

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

Additional references

  • Network Security Rules

  • Add or Edit Firewall Rule


Network Security Rules

By using the Security Configuration Wizard (SCW), you can create firewall rules to allow this computer to send traffic to or receive traffic from programs, system services, computers, or users. Firewall rules can be created to take one of three actions for all connections that match the rule's criteria: allow the connection, only allow a connection that is secured through the use of Internet Protocol security (IPsec), or explicitly block the connection.

Use the View list to filter the rules that are displayed. The choices for displaying rules are:

  • All Rules. Rules included in all other categories.

  • Rules from Selected Roles. Rules that exist in the Security Configuration Database and that are installed and selected in SCW. The rules are enabled or disabled as appropriate for the selected roles and options.

  • Rules Added by the User in SCW. Rules that are defined by the administrator in SCW. This list does not include rules from selected roles.

  • Rules Auto-Generated by SCW. Rules that are automatically generated for unknown applications or services.

  • Rules with Additional Restrictions. Rules that have been restricted by using the Edit Rule dialog box. Restrictions can be added to any rule and modified or removed by clicking Edit.

As your IT environment changes, you can change, create, or delete rules.

Click Add to add a new rule, or select a rule and click Edit to edit or remove an existing rule.

Additional references

  • Network Security

  • Add or Edit Firewall Rule


Add or Edit Firewall Rule

By using the Software Configuration Wizard (SCW), you can create firewall rules to allow this computer to send traffic to or receive traffic from programs, system services, computers, or users. Firewall rules can be created to take one of three actions for all connections that match the rule's criteria: allow the connection, only allow a connection that is secured through the use of Internet Protocol security (IPsec), or explicitly block the connection.

Important

Firewall rules allow traffic through the firewall but do not secure that traffic. To secure traffic with IPsec, you can create connection security rules. However, the creation of a connection security rule does not allow the traffic through the firewall. You must create a firewall rule to do this, if the traffic is not allowed by the default behavior of the firewall. Connection security rules are not applied to programs or services; they are applied between two computers. The Windows Firewall with Advanced Security snap-in (FW.msc) must be used to create connection security rules.

General tab

Rules can be created for either inbound traffic or outbound traffic. The rule can be configured to specify the program, service, protocol, or port. As your IT environment changes, you can change, create, or delete rules.

Firewall rules are applied in the following order of priority:

  • Authenticated bypass (rules that override block rules)

  • Block connection

  • Allow connection

Inbound rules

Inbound rules explicitly allow or explicitly block traffic attempting to access the computer that matches the criteria in the rule. For example, you can configure a rule to explicitly allow traffic secured by IPsec for Remote Desktop through the firewall but block the same traffic if it is not secured by IPsec. When Windows is first installed, inbound traffic is blocked; to allow traffic, you must create an inbound rule.

Outbound rules

Outbound rules explicitly allow or explicitly block traffic originating from the computer that matches the criteria in the rule. For example, you can configure a rule to explicitly block outbound traffic to a specific computer through the firewall but allow the same traffic to other computers. Outbound traffic is allowed by default, so you must create an outbound rule to block traffic.

Programs and Services tab

Because Windows Firewall with Advanced Security blocks all incoming unsolicited TCP/IP traffic by default, you might need to configure program, port, and system service rules for programs or services that are acting as servers, listeners, or peers. Program, port, and system service rules must be managed on an ongoing basis as your server roles or configurations change.

Important

The settings for a firewall rule add increasing levels of restriction to the criteria for which connection requests will match the rule. For example, if you do not specify a program or service on the Program and Services tab, all programs and services will be allowed to connect if they match other criteria. Therefore, adding more detailed criteria makes the rule progressively more restrictive and less likely to be matched.

To add a program to the rules list, you must specify the full path to the executable (.exe) file used by the program. A system service that runs within its own unique .exe file and is not hosted by a service container is considered to be a program and can be added to the rules list. In the same way, a program that functions like a system service and runs whether or not a user is logged on to the computer is also considered a program, as long as it runs within its own unique .exe file.

Caution

Adding programs that host services, such as Svchost.exe, Dllhost.exe, and Inetinfo.exe, to the rules list without further restrictions in the rule might expose the computer to security threats. Also, adding these programs might conflict with other service-hardening policies on computers running Windows Server 2008 R2 or Windows Server 2008.

When you add a program to the rules list, Windows Firewall with Advanced Security dynamically opens (unblocks) and closes (blocks) the ports required by the program. When the program is running and listening for incoming traffic, Windows Firewall with Advanced Security opens the required ports; when the program is not running or is not listening for incoming traffic, Windows Firewall with Advanced Security closes the ports. Because of this dynamic behavior, adding programs to the rules list is the recommended method for allowing unsolicited incoming traffic through Windows Firewall with Advanced Security.

Note

You can use program rules to allow unsolicited incoming traffic through Windows Firewall with Advanced Security only if the program uses Windows Sockets (Winsock) to create port assignments. If a program does not use Winsock to assign ports, you must determine which ports the program uses and add those ports to the rules list.

Protocols and Ports tab

In some cases, if you cannot add a program or system service to the rules list, you must determine which port or ports the program or system service uses and then add the port or ports to the Windows Firewall with Advanced Security rules list.

On the Protocols and Ports tab, you can select from a list of the most commonly used protocols and their associated protocol number. If the protocol that you need to add is not in the list, you can select Custom and specify the protocol number.

If you select either the TCP or UDP protocol, you can then specify the local and remote ports to which the rule applies. When you add a TCP or UDP port to the rules list, the port is open (unblocked) whenever Windows Firewall with Advanced Security is running, whether or not there is a program or system service listening for incoming traffic on the port. For this reason, if you need to allow unsolicited incoming traffic through Windows Firewall with Advanced Security, you should create a program rule instead of a port rule.

Scope tab

Use the Scope tab to specify an IP address, a subnet, or a range of IP addresses. You can use both IPv4 and IPv6 IP addresses.

Local IP addresses

Under Local IP Addresses, you can configure the firewall rule to be applied when the target computer is the local computer. You can further identify when the rule applies to the local computer by specifying an IP address or IP address range to apply the rule to computers that reside in a certain branch of your network.

Remote IP addresses

Under Remote IP Addresses, you can configure the firewall rule to be applied when the target computer is a remote computer. You can further identify when the rule applies to remote computers by specifying an IP address or IP address range to apply the rule to computers that reside in a certain branch of your network.

About specifying IP addresses

  • IPv4. If your network uses IPv4 addressing, you can specify a single IP address, such as 172.30.160.169, or a subnet, such as 146.53.0.0/24.

  • IPv6. If your network uses IPv6 addressing, you can specify a single IP address as eight sets of four hexadecimal digits separated by colons (or in an equivalent allowed format) or as a subnet.

  • For both formats, to specify a range of addresses, just specify the first (From) and last (To) IP addresses included in the rule.

Additional references

  • Network Security

  • Restricting Services

  • IP Address


Restricting Services

When creating firewall rules in the Security Configuration Wizard (SCW), you can select which services are restricted by the firewall rule. To use a firewall rule to restrict a service, choose a service from the list of services. Each firewall rule can restrict only one service.

The services list includes the name of services on your server as well as their short name. A service is an application type that runs in the system background without a user interface. Services provide core operating system features, such as Web services, event logging, file services, printing, cryptography, and error reporting.

Additional references

  • IP Address

  • Add or Edit Firewall Rule


IP Address

Use this page to specify an IP address, a subnet, or a range of IP addresses. You can use both IPv4 and IPv6 IP addresses. In the IP Address dialog box, specify which IP addresses this firewall rule will apply to by selecting one of the following options:

  • This IP address or subnet. Select this option to specify a single IP address or subnet.

  • This IP range. Select this option to specify a range of IP addresses by identifying the first (From) and last (To) IP addresses in the range.

Additional references

  • Restricting Services

  • Add or Edit Firewall Rule


Registry Settings

In the Registry Settings section of the Security Configuration Wizard (SCW), you can configure protocols used to communicate with other computers.

  • Require SMB Security Signatures

  • Require LDAP Signing

  • Outbound Authentication Methods

  • 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.

This security setting determines whether packet signing is required by the server message block (SMB) server component.

The SMB protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To help prevent attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB client is permitted.

If this setting is enabled, the Microsoft network server will not communicate with a Microsoft network client unless that client agrees to perform SMB packet signing.

Notes
  • All Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required.
  • If server-side SMB signing is required, a client will not be able to establish a session with that server unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.
  • Similarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
Important

Using SMB packet signing can degrade performance up to 15 percent on file service transactions.

Registry key

  • 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://go.microsoft.com/fwlink/?LinkId=91043).

Additional references

  • Registry Settings


Require LDAP Signing

This page appears when the Domain Controller (Active Directory) role is selected on the Select Server Roles page. On the Require LDAP Signing page, information is gathered about the other computers in the domain controller's domain.

Registry key

  • 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://go.microsoft.com/fwlink/?LinkId=91170).

Additional references

  • Registry Settings


Outbound Authentication Methods

On this page, information is gathered about how to authenticate with remote computers. This security setting determines which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers.

You can choose to authenticate with a combination of the following:

  • Domain accounts

    When you make this selection, you enter information about the domain controllers in the domain and trusted domains of the selected server.

  • Local accounts on the remote computers

    When you make this selection, you enter information about the computers used by the selected server to authenticate to other computers.

Additional references

  • Registry Settings

  • Outbound Authentication Using Domain Accounts

  • Outbound Authentication Using Local Accounts


Outbound Authentication Using Domain Accounts

Using the information provided on this page, the Security Configuration Wizard (SCW) will set the LAN Manager authentication level that is appropriate for your environment and use that authentication level to authenticate domain accounts that are attempting to make outbound connections through the server.

This LAN Manager authentication level determines which challenge/response authentication protocol is acceptable for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers.

The Windows NT 4.0 Service Pack 6a or later operating systems check box is used to ascertain that the clients that connect to this server support NTLMv2 authentication. Computers running Windows NT 4.0 Service Pack 4 (SP4) and earlier do not support NTLMv2. Computers running Windows 95 and Windows 98 do not support NTLM.

The Clocks that are synchronized with the selected server's clock check box also checks if the client meets the requirements for using NTLMv2 authentication. Synchronization is required for NTLMv2. Older systems do not use clock synchronization. If the network contains only computers running Windows 2000, Windows XP, or Windows Server 2003, indicate that your environment uses clock synchronization.

Registry key

  • HKLM\System\CurrentControlSet\Services\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 must have clocks that are synchronized with the selected server's clock.

For more information about this security setting, see "Network security: LAN Manager authentication level" (http://go.microsoft.com/fwlink/?LinkId=91045).

Additional references

  • Outbound Authentication Methods

  • Outbound Authentication Using Local Accounts


Outbound Authentication Using Local Accounts

Using the information provided on this page, the Security Configuration Wizard (SCW) will set the LAN Manager authentication level that is appropriate for your environment and use that authentication level to authenticate local accounts on remote computers that are attempting to make outbound connections through the server.

This LAN Manager authentication level determines which challenge/response authentication protocol is acceptable for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers.

The Windows NT 4.0 Service Pack 6a or later operating systems check box is used to ascertain that the clients that connect to this server support NTLMv2 authentication. Computers running Windows NT 4.0 Service Pack 4 (SP4) and earlier do not support NTLMv2. Computers running Windows 95 and Windows 98 do not support NTLM.

The Clocks that are synchronized with the selected server's clock check box also checks if the client meets the requirements for using NTLMv2 authentication. Synchronization is required for NTLMv2. Older systems do not use clock synchronization. If the network contains only computers running Windows 2000, Windows XP, or Windows Server 2003, indicate that your environment uses clock synchronization.

Registry key

  • HKLM\System\CurrentControlSet\Services\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.

For more information about this security setting, see "Network security: LAN Manager authentication level" (http://go.microsoft.com/fwlink/?LinkId=91045).

Additional references

  • Outbound Authentication Methods

  • Outbound Authentication Using Domain Accounts


Inbound Authentication Methods

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

These security settings will determine which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers.

These security settings will also determine if, at the next password change, the LAN Manager (LM) hash value for the new password is stored. The LM hash is relatively weak and prone to attack, as compared with the cryptographically stronger NTLM hash. Because the LM hash is stored on the local computer in the security database, the passwords can be compromised if the security database is attacked.

Important

This setting can affect the ability of computers to communicate with computers running Windows NT Server 4.0 and earlier over the network. For example, computers running Windows NT Server 4.0 Service Pack 4 (SP4) and earlier do not support NTLM version 2 (NTLMv2). Computers running Windows 95 and Windows 98 do not support NTLM.

Registry keys

  • 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://go.microsoft.com/fwlink/?LinkId=17765)

  • "Network security: Do not store LAN Manager hash value on next password change" (http://go.microsoft.com/fwlink/?LinkId=17766)

For domain controllers only

An additional option appears when the Domain Controller (Active Directory) role is selected on the Select Server Roles page. The following option is specific to domain controllers:

Computers using RAS or VPN to connect to RAS servers that are not running Windows Server 2003 Service Pack 1 or later

Internet Authentication Service (IAS) servers and servers running Routing and Remote Access require Windows Server 2003 Service Pack 1 (SP1) and require support for PEAP-MSCHAPv2–only authentication in order to authenticate users with domain controllers that accept only NTLMv2.

IAS servers and servers running Routing and Remote Access use NTLM to authenticate their clients' domain credentials. This means domain controllers that need to authenticate IAS or Routing and Remote Access 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 NTLM from IAS servers and servers running Routing and Remote Access but only accept NTLMv2 from everyone else. This happens by default for servers running Windows Server 2003 SP1 and IAS or Routing and Remote Access and that use PEAP-MSCHAPv2 because PEAP-MSCHAPv2 offers security protection equivalent to that of NTLMv2. This exemption does not happen by default if the server running Windows Server 2003 SP1 and IAS or Routing and Remote Access uses PPP-MSCHAPv2 to authenticate clients.

To prevent this default exemption for servers running Windows Server 2003 SP1 and IAS or Routing and Remote Access, the following registry value can be set on the domain controller:

HKLM\System\CurrentControlSet\LSA\DisallowMsvChapv2

If this registry value 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 or Routing and Remote Access clients even if all of these servers are running Windows Server 2003 SP1. Therefore, if the DisallowMsvChapv2 registry value has been set on the domain controller and the domain controller needs to authenticate IAS or Routing and Remote Access clients, then the Computers using RAS or VPN to connect to RAS servers that are not running Windows Server 2003 Service Pack 1 or later check box must be selected on the Inbound Authentication Methods page, even if all servers running IAS or Routing and Remote Access are also running Windows Server 2003 SP1. Since selecting this check box prevents the domain controller from being configured to accept NTLMv2 only, it is recommended that the DisallowMsvChapv2 registry value not be set.

Additional references

  • Registry Settings


Registry Settings Summary

The Registry Settings Summary page allows you to view all of the changes that this security policy would make to specific registry settings if applied to the selected server. The 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, view the Registry Value column. The registry value that is modified by your selections is listed on each page of this section. Return to the page on which you configured the setting and make the appropriate changes.

Additional references

  • Registry Settings


Audit Policy

In the Audit Policy section of the Security Configuration Wizard (SCW), you can configure an audit policy for the selected server.

  • System Audit Policy

  • Audit Policy Summary


System Audit Policy

You can use this page 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 the security log. An audit policy defines the types of events that you want to collect.

Collecting and monitoring audit events consumes disk space and other resources. Before selecting an audit policy, review "Auditing Security Events Best Practices" (http://go.microsoft.com/fwlink/?LinkId=92229).

You can use Microsoft Operations Manager (MOM) to collect audit events from multiple servers at a single repository.

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

Audit policy objective Description Audit event type and policy settings

Do not audit

No auditing is performed. CPU cycles and disk space are 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 account logon events: Success, Failure

Audit account management: Success

Audit directory service access: Success

Audit logon events: Success, Failure

Audit object access: Success

Audit policy change: Success

Audit privilege use: Not audited

Audit process tracking: Success

Audit system 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 account logon events: Success, Failure

Audit account management: Success, Failure

Audit directory service access: Success, Failure

Audit logon events: Success, Failure

Audit object access: Success, Failure

Audit policy change: Success, Failure

Audit privilege use: Not audited

Audit process tracking: Success, Failure

Audit system events: Success, Failure

Additional references

  • Audit Policy


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

SCWAudit.inf is the auditing security template that is provided with the Security Configuration Wizard (SCW). SCWAudit.inf defines the system access control lists (SACLs) that help detect the tampering or attempted tampering of the operating system. These SACLs enable the system to record 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. However, applying 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, if you do not want to apply the SCWAudit.inf security template, you can clear the Also include the SCWAudit.inf security template. SCWAudit.inf sets System Access Control Lists (SACLS) in order to audit access of the file system check box on the Audit Policy Summary page.

To view details about the file system and registry SACLs defined in SCWAudit.inf, you can open SCWAudit.inf from the Security Templates snap-in. SCWAudit.inf is located in %WINDIR%\Security\Msscw\Kbs.

Another security template, DefaultSACLs.inf, is also provided. It allows you to reapply the default SACLs, in case SCWAudit.inf does not function as intended. The default SACLs that are applied are those that were installed with Windows, not the SACLs that were in effect before you applied SCWAudit.inf. To apply DefaultSACLs.inf, type the following at a command prompt:

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

Additional references

  • Audit Policy


Completing the Security Configuration Wizard

In the Save Security Policy section of the Security Configuration Wizard (SCW), you can save and apply the security policy created or edited with SCW.

Security Policy File Name

Choose a location and a file name with an .xml extension to save the security policy. You should save the security policy in a location accessible to administrators who will run SCW to apply the policy.

View Security Policy

You can click View Security Policy to open SCW Viewer. SCW Viewer allows you to browse the details of the policy before saving it.

Include Security Templates

You can include policy settings in your security policy in addition to those created with SCW. Click Include Security Templates to include a security template with the additional policy settings. If any template settings conflict with those created in SCW, then SCW takes precedence.

Apply Security Policy

You can apply a security policy immediately after creating or editing the policy by clicking 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, click Apply later. 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 SCW and, on the Configuration Action page, click Apply an existing security policy.

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

  • Application Management

  • Terminal Services or Remote Desktop Services

  • Windows Audio

After the policy is applied, the startup mode for each service is changed to the value specified in the security policy. However, the current status of these services is not changed 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 with Advanced Security was started, the computer will have to be restarted for these applications and services to run properly.

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

Additional references

  • Security Configuration Wizard