Lesson 1: Planning Microsoft Windows 2000 Security Templates

Security templates allow you to define baseline security for computers that share similar security requirements. Using security templates ensures that security can be applied consistently to multiple computers.

---

After this lesson, you will be able to

• Plan the use of security templates to ensure that consistent security is applied to all computers performing similar roles in your network

Estimated lesson time: 60 minutes

---

Introducing Windows 2000 Security Templates

Windows 2000 has made it easier to apply consistent security by introducing security templates. Security templates define security based on seven categories of configuration. You use each category to apply specific computer-based security settings. These categories include

• Account Policy. Defines account authentication configuration settings. For domain accounts, account policy settings must be consistent across the domain. You can't define individual account policy settings for users within a specific organizational unit (OU). Within account policies, there are three subcategories of configuration:
  • Password Policy. Defines password restrictions. These restrictions include minimum password length, password history maintenance, minimum and maximum password age, password complexity, and the use of reversible encryption for storing passwords.
  • Account Lockout Policy. Defines what action is to be taken when a user enters incorrect passwords. This policy includes the threshold when account lockout takes place, the response to take, and how frequently to reset counters associated with account lockout.
  • Kerberos Policy. Defines Kerberos v5 protocol settings. These settings include lifetimes for Ticket Granting Tickets (TGTs), Service Tickets (STs), maximum clock deviance, and the verification of group memberships and account lockout status.

  NOTE

  ---

  Account policy settings applied at the OU level affect the local Security Accounts Management (SAM) databases but not the user accounts within the OU. This is because the user accounts apply their account policy settings from the Default Domain Policy.

• Local Policy. Defines security settings only for the computer on which the security template is applied. Local computer policies are applied to the local computer account database and are composed of the following three categories:
  • Audit Policy. Defines the events that will be audited. The audited events will be stored in the local computer's security log. You can configure each auditing event to include either success or failure audits (or both if necessary).
  • User Rights Assignment. Defines which security principals will be assigned user rights on the local computer. These user rights supersede any NTFS permissions defined for an object.
  • Security Options. Define a wide variety of settings that are configured in the Windows 2000 registry. Common security options include whether to display the last user name used to log on to a computer or to rename the Administrator's account name.
• Event Log. Defines the properties of the application, security, and system logs. These properties include the maximum log sizes, who can view the logs, retention periods for the logs, and what action to take if the security log reaches the defined maximum size.
• Restricted Groups. Used to define memberships of security groups. The creator of the security template selects the security groups. Common groups that are included in this policy are Power Users, Enterprise Admins, and Schema Admins. Memberships include which security principals can be members of the restricted group. The policy also defines what other groups the restricted group can be a member of.
• Systems Services. Allows you to define restrictions for services installed on a computer. These restrictions include defining whether a service is enabled or disabled and which security principals can start or stop the selected service. For example, you could configure this policy to disable the Routing and Remote Access service on all client workstations to prevent users from configuring their desktop computers as dial-up servers.
• Registry. Allows you to define security for registry keys and their subtrees. For each defined registry key, you can define security settings for the registry key, configure whether the current permissions are replaced, and configure whether subtrees will have their permissions replaced. Security settings for the registry key include defining which security principals can modify security settings and auditing attempts to modify the registry settings.
• File System. Defines discretionary access control list (DACL) and system access control list (SACL) settings for any folders included within this policy. This policy requires NTFS to be used as the file system where the folders exist.

You can define the security template settings by loading the Security Templates Microsoft Management Console (MMC), shown in Figure 8.2.

Figure 8.2 The Security Templates MMC console

The Security Templates MCC console allows you to create new templates or modify existing templates to meet your security needs.

Determining Common Security Requirements

Before defining security templates, you must identify computers on your network that require similar security configurations. You usually do this by determining the specific role that each Windows 2000–based computer will play on the network and by identifying each role's unique security requirements.

Each role will ultimately be associated with a security template that identifies the baseline (or required) security for that class of computer. Some of the more common roles that you can define for computers include

• DCs. These Windows 2000–based computers maintain the Active Directory database. The security requirements for securing Active Directory will be more stringent than any other security requirements on the network.
• Application servers. These Windows 2000–based computers host various client server applications, such as Web–based applications, structured query language (SQL) databases, and Microsoft Exchange mail servers. In some cases you may want to further categorize each application server by its primary application. Within each category you can define the required security baselines for that application.
• File and print servers. These Windows 2000–based computers host data that's shared among network users. Within the security definition, you may have specific DACLs defined for specific data stores.
• Extranet servers. These Windows 2000–based computers aren't members of your Active Directory. While authentication may take place, these servers are most likely located in a Demilitarized Zone (DMZ) and will have only limited access to internal network resources.
• Workstations. Windows 2000–based client computers that won't leave the premises. There might be a further breakdown based on department or business unit.
• Laptops. Windows 2000–based client computers that may be either inside or outside the office network. Users who have laptops might require elevated privileges to accomplish some tasks when disconnected from the corporate network.
• Kiosks. Windows 2000–based computers used in public locations that run a single application for public usage. For example, you might secure kiosks to prevent access to any other applications or network resources. Settings might also include automatic logon using a preconfigured account to run the application.

Making the Decision

When you determine the roles of Windows 2000–based computers within your organization, use the following guidelines:

• Categorize computers into three general categories: workstations, servers, and DCs. This breakdown matches the Default templates included with Windows 2000.
• Within each category, identify groups of computers that require similar security configurations. You can base the subcategories on the applications that the servers host or the resources that the server makes available on the network.
• Have someone else review the categories and identify further subcategories. Be careful not to get too specific. You don't want to identify separate templates for each computer on the network.

NOTE

---

You can apply Windows 2000 security templates only to Windows 2000–based computers. Therefore, consider only Windows 2000–based computers in your role definitions.

Applying the Decision

Based on the information given in this scenario, Market Florist could use the following categories of computers:

• DCs. This group contains all DCs in each of the three domains.

  NOTE

  ---

  Because the marketflorist.tld forest has three separate domains, you have to deploy the security templates in each of them.

• File and print servers. Each file and print server requires similar security configuration. If you use similar file structures on the servers, you can also set NTFS permissions by using security templates.
• Internal SQL servers. The internal SQL servers require unique security configuration based on internal usage only.
• External SQL server. Because one SQL server stores data from the external Web site, you might need additional security configuration for this SQL server.

  NOTE

  ---

  You might be able to use a single security template for all SQL servers. It depends on your analysis of the security requirements for the two roles played by SQL servers. Despite the different data stored on the servers, they may use identical security configuration.

• Web servers. The four Web servers require identical security configuration to ensure that the Web site has consistent security applied no matter which Web server in the NLBS cluster is contacted.
• Client computers. All client computers require the same security configuration. It doesn't matter whether the client computer was upgraded from a previous version of the operating system.
• Laptop computers. All laptop computers have unique security requirements for the deployment of Windows 2000.

Analyzing Default Security in Windows 2000

One of the common complaints about Windows NT 4.0 was that the operating system wasn't secure after a default installation was performed. Windows 2000 addresses this concern by defining default security to increase the security applied to the operating system. These default settings are applied in one of two ways:

• Newly installed computers. A newly installed Windows 2000–based computer will have the default security template applied during installation. This security template defines the security environment and includes elevated security for NTFS permissions and registry permissions.

  WARNING

  ---

  For the default security settings to be fully applied, Windows 2000 must be installed to an NTFS partition.

• Upgraded computers. Upgraded computers maintain their previous Windows NT 4.0 settings. You can apply the Basic template to an upgraded computer to ensure that the default Windows 2000 security settings are also applied to upgraded computers. The Basic template does differ from the default template in that certain security settings aren't modified. For example, any user rights assigned to existing accounts are maintained so that applications that depend on these services continue to operate correctly.

NOTE

---

Windows 2000–based computers that have been upgraded from Microsoft Windows 95 or Microsoft Windows 98 have the default security settings applied, with the exception that all local user accounts are configured to be members of the local Administrators group if the current file system is converted to NTFS. When upgrading from Windows 95 or Windows 98, always review the membership of the local Administrators group to ensure that excess privileges aren't being assigned to the local computer.

Securing Newly Installed Computers

As mentioned earlier, newly installed Windows 2000–based computers will have the Default security template applied during the computer's installation. There are actually three Default security templates, depending on the role the computer plays on the network:

• Defltwk.inf. Applied to all workstations running Windows 2000 Professional
• Defltsv.inf. Applied to all servers running Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Data Center
• Defltdc.inf. Applied to all DCs running Windows 2000

NOTE

---

The Default security templates are stored in the systemroot\inf directory (where systemroot represents the folder where Windows 2000 is installed). Once a Default template is applied to a computer, the applied template is stored in systemroot\security\templates as "Setup security.inf."

Securing Upgraded Computers

When Windows 2000–based computers are upgraded from previous versions of Windows NT, they won't have the Default template applied. In this situation the existing security configuration is maintained. You can still increase the security of the computer by applying the Basic templates. The Basic templates will apply the same settings configured in the default security templates with the exception of restricted groups and user rights. This ensures that any existing user rights (for example, user rights assigned to allow service accounts to operate) aren't removed. You can apply the following Basic templates to upgraded Windows 2000–based computers:

• Basicwk.inf. Can be applied to workstations running Windows 2000 Professional
• Basicsv.inf. Can be applied to servers running Windows 2000 as long as they're not functioning as DCs
• Basicdc.inf. Can be applied to DCs running Windows 2000

NOTE

---

You can find the three Basic templates in the systemroot\security\templates folder.

Making the Decision

Use the design matrix shown in Table 8.2 to ensure that the default settings are applied to all Windows 2000–based computers.

Table 8.2 Applying Windows 2000 Default Security Configuration

If the Computer Is	Do the Following
Upgraded from Windows 95 or Windows 98 to Windows 2000 Professional	Ensure that during the upgrade you choose to convert the file system to NTFS. Do nothing else. The Defltwk.inf security template will be applied automatically.
Upgraded from Windows NT 4.0 Workstation to Windows 2000 Professional	Ensure that the file system is converted to NTFS. Apply the Basicwk.inf security template to ensure that default security is applied.
A member server upgraded from Windows NT 4.0 to Windows 2000	Ensure that the file system is converted to NTFS. Apply the Basicsv.inf security template to ensure that default security is applied.
A DC upgraded from Windows NT 4.0 to Windows 2000	Ensure that the file system is converted to NTFS. Apply the Basicdc.inf security template to ensure that default security is applied.
A new install of Windows 2000	Ensure that the system and boot partitions are configured to use NTFS. Do nothing else. The default security templates will be applied automatically and stored in the Setup Security.inf file.

Applying the Decision

To ensure consistent default security on the Market Florist network, use Table 8.3, which shows whether the Default or Basic security templates are used to apply Windows 2000 default security.

Table 8.3 Ensuring Default Security for Market Florist

DCs	The default DC security template (Defltdc.inf) is automatically applied at installation.
File and print servers	The default server security template (Defltsv.inf) is automatically applied at installation.
Internal SQL servers	The default server security template (Defltsv.inf) is automatically applied at installation.
External Web servers	The default server security template (Defltsv.inf) is automatically applied at installation.
Client computers running Windows 2000 Professional (new installations)	The default workstation security template (Defltwk.inf) is automatically applied at installation.
Client computers running Windows 2000 Professional (upgraded from Windows 95)	The default workstation security template (Defltwk.inf) is automatically applied during the upgrade. The upgrade process must convert the file system to NTFS for all security settings to be applied.
Client computers running Windows 2000 Professional (upgraded from Windows NT 4.0)	The basic workstation security template (Basicwk.inf) must be manually applied as part of the upgrade process to ensure that default security is applied to the upgraded computers.
Laptop computers running Windows 2000 Professional (new installations)	The default workstation security template (Defltwk.inf) is automatically applied at installation.

Additionally, you should inspect the membership of the local Administrators group of the Windows 2000 Professional clients that were upgraded from Windows 95. By default, an upgrade from Windows 95 to Windows 2000 Professional places any existing user accounts into the local Administrators group. You must modify the membership of the local Administrators group to ensure that excess privileges aren't assigned to user accounts.

Using Incremental Security Templates

Although the default Windows 2000 security configurations provide adequate security for many situations, sometimes additional security configuration is required. To help you define additional security, Microsoft has included several incremental security templates. These incremental templates provide security settings that are best applied in specific scenarios, such as when Terminal Services is deployed on a Windows 2000 Server.

NOTE

---

The incremental templates are effective only if the default or basic templates have already been applied.

Windows 2000 provides the following incremental security templates:

• The No Terminal Server Security Identifier (SID) (Nottssid.inf) template. This template removes the Terminal Server Users SID from all DACLs. By default, Terminal Services applies consistent security settings to all Terminal Services users by defining resource access for the Terminal Server Users security group. By removing the Terminal Server Users SID from a DACL, all security is applied based on the individual user's SID and group memberships.
• The Windows NT 4.0 Compatible Security (Compatws.inf) template. With the increased security in Windows 2000, some older applications may not function correctly. These applications generally attempt to write to areas that are now restricted to members of the Administrators or Power Users groups on the computer. A normal user running the applications won't have the permissions to write to the registry or to the file system. The Compatws.inf template weakens default security so that noncertified applications can run under Windows 2000.

  Alternative Methods of Providing Application Compatibility

  When you upgrade to a new operating system such as Windows 2000, some older applications might fail to operate correctly in the new environment. For example, Microsoft Office 97 isn't a Windows 2000–certified application. Under default security, the spelling checker doesn't operate because it attempts to write to folders that aren't accessible to normal user accounts.

  When designing security templates, consider using the following methods to ensure that the applications run in a Windows 2000 environment:

  • Add all users to the Power Users group. In Windows 2000, the Power Users group is the equivalent of the Users group in Windows NT 4.0. Adding all users to the Power User group isn't recommended because membership in Power Users provides some administrative capabilities, such as adding local users or managing NTFS permissions on the local computer.
  • Apply the Compatws.inf security template. As mentioned earlier, the compatible workstation template weakens the default security to match Windows NT 4.0 security. Applying the Compatws.inf security template isn't recommended because default security is very important to a secure network.
  • Use the Apcompat.exe utility included in the Windows 2000 Support Tools. In some cases the reason an application won't run isn't due to security restrictions, but that it doesn't recognize the Windows 2000 operating system. In these cases, use the Apcompat.exe utility to have Windows 2000 emulate a previous Windows operating system, as shown in Figure 8.3.

    

    Figure 8.3 Configuring Apcompat to allow Dragon Naturally Speaking to execute

  • Upgrade to a newer version of the application.Consider upgrading to a Windows 2000–certified version of the application. This may involve an upgrade or may only require the installation of a patch to the application.

• The Initial DC Configuration template (DC security.inf). When a Windows 2000–based server is promoted to a DC, you must apply specific file and registry permissions to ensure security in the new role. These settings are contained within this template.

  NOTE

  ---

  This incremental security template is always applied when a member server is promoted to a DC. This isn't truly an optional security template. You can use this security template to ensure that initial DC security is still applied.

• The Optional Components templates (Ocfilesw.inf and Ocfiles.inf). These templates increase the local security for optional components that might be installed on Windows 2000 Professional or Windows 2000 Server–based computers, including applications such as Microsoft Internet Explorer, Microsoft NetMeeting, and Internet Information Services (IIS) 5.0.
• The Secure templates (Securews.inf and Securedc.inf). These templates provide security beyond DACLs on the registry and the file system. The Secure templates force the operating system to behave more securely and include modifications for account policy. For example, the Secure templates prevent security principals from being members of the Power Users security group. Membership in this group is considered an excess privilege for normal user accounts.
• The High Secure templates (Hisecws.inf and Hisecdc.inf). These templates offer increased security over the Secure templates for higher security networks. While the Secure template only sends NTLM responses for file sessions using the NTLM protocol, the High Secure template only responds using NTLMv2. In addition, a server configured with the High Secure template will ignore all LAN Manager and NTLM requests.

WARNING

---

Implementing the High Secure templates may prevent down-level Windows clients from participating in the network. Only deploy the High Secure templates when all client computers are running Windows 2000.

Comparing the Secure and High Secure Options

Table 8.4 shows the differences between the Secure and High Secure templates.

Table 8.4 Comparing the Secure and High Secure Templates

Setting	Secure Template (Securedc.inf)	High Security Template (Hisecdc.inf)
Additional restrictions for anonymous connections	Don't allow enumeration of SAM accounts and shares	No access without explicit anonymous restrictions
Clear virtual memory pagefile when system shuts down	Disabled	Enabled
Digitally sign client communications (always)	Disabled	Enabled
Digitally sign client communications (when possible)	Enabled	Enabled
Digitally sign server communications (always)	Disabled	Enabled
Digitally sign server communications (when possible)	Enabled	Enabled
Do not display last user name in logon screen	Disabled	Enabled
LAN Manager Authentication Level	Send NTLM responses only	Send NTLMv2 response only \ Refuse LM & NTLM
Secure channel: Digitally encrypt or sign secure channel data (always)	Disabled	Enabled
Secure channel: Digitally encrypt or sign secure channel data (when possible)	Enabled	Enabled
Secure channel: Digitally sign secure channel data (when possible)	Enabled	Enabled
Secure channel: Require strong (Windows 2000 or later) session key	Disabled	Enabled
Unsigned driver installation behavior	Don't allow installation	Don't allow installation
Unsigned nondriver installation behavior	Warn but allow installation	Silently succeed

As you can see, there isn't a great difference between the Secure and High Secure templates. The key differences is the enforcement of server message block (SMB) signing (digitally sign server communications) and secure channel session keys.

Making the Decision

Use the decision matrix shown in Table 8.5 to determine when it's appropriate to use each of the incremental security templates.

Table 8.5 Designing Incremental Security Template Usage

Use This Template	When You Have the Following Security Requirements
No Terminal Services ID	You've deployed Windows 2000 servers with Terminal Services configured to use Application Mode. You wish to secure access to Terminal Services and the resources on the terminal server on a per user basis. You are deploying Terminal Services as a desktop replacement and want to provide maximum security for all users.
Compatible Workstation	Your budget doesn't allow for an immediate upgrade to a Windows 2000–certified version of the application. You don't want to make all users members of the Power Users group. You can't identify which individual NTFS files or registry keys require modified permissions.
Optional Components	You've installed additional components to Windows 2000 and want to maintain the highest level of security.
DC Security	You want to ensure that initial DC security is still applied to a DC.
Secure	You're in a mixed environment of Windows 2000 and down-level clients. You wish to have the strongest security without excluding down-level clients.
High Security	No down-level clients remain on the network. You want to provide the strongest form of security for all data usage.

Applying the Decision

Market Florist has decided that they want to prevent down-level clients from connecting to the network while maintaining the highest level of security on the internal network. By applying the High Security templates to all its Windows 2000–based computers, Market Florist will accomplish both goals.

You must apply High Security templates (Hisecws.inf and Hisecdc.inf) only to computers that have Windows 2000 default security applied, as mentioned earlier. You can apply the Hisecws.inf security template to all client computers, including those upgraded from previous versions of Windows, and you can apply the Hisecdc.inf to all Windows 2000 servers, including both DCs and file and print servers.

Creating Custom Security Templates

While the Default templates meet most security requirements, you may need to create modified templates to define security baselines for some computer roles. If the settings that you require are in the Security Templates interface, you can simply create custom security templates by using an existing template as the starting point for your custom security template.

When defining a custom security template, be careful to avoid applying too many settings. The security template should meet, but not exceed, the required security baseline.

Making the Decision

When designing custom security templates, consider the following points:

• Identify an existing security template to be your starting point. You can save an existing security template under a new name in the Security Templates console. By saving an existing template with a different name, you ensure that you don't miss any settings that you may not be aware of in the initial template.
• Configure any additional settings. Add the additional settings that required you to define a custom security template. Document any additional settings so that you will know the reason for using the additional settings if you review them.
• Test the newly created security template against a new installation. This process ensures that you haven't missed any settings in your security template.

Applying the Decision

Market Florist must create a custom security template for the Web servers hosting the ww.marketflorist.tld Web site and the Flower Power application. You must include the following items in the custom security template:

• Disabling of nonrequired services. You must analyze the Web servers to determine exactly which services must be present on the Web servers. Some of the services that you can disable include the FTP Publishing service, Telnet Service, Simple Mail Transfer Protocol (SMTP) service, and the Server service, which are common services that are exploited by attackers.

  NOTE

  ---

  Disabling the Server service would prevent Windows 2000 SMB file connections to the Web server from both the internal and external networks. An alternative would be to configure IPSec to protect connections to the server from the internal network. This would require defining IPSec on the Web servers. For more information, see Chapter 12, "Securing Data at the IP Level."

• Custom NTFS permissions for the Flower Power folder structure. You must determine what are the NTFS permissions required for the Flower Power folder structure to restrict access to the data to only authorized access. By applying the permissions through a security template, you can ensure that the required permissions are enforced.
• Custom Registry permissions for the Flower Power application. You must determine what security principals can modify registry settings related to the Flower Power application.

Extending the Security Configuration Tool Set

Although you can create custom security templates from existing settings, sometimes the settings you require might not be included in the Security Configuration Tool Set (SCTS). For example, you may want to use Group Policy to prevent Windows 2000 client computers from attempting to register the Host (A) and Pointer (PTR) resource records with Domain Name System (DNS) by using dynamic updates. You can extend the SCTS to include the registry entry to prevent dynamic updates for all network adapters.

NOTE

---

The registry value to prevent Windows 2000 client computers from performing dynamic update of the A and PTR resource records is HKEY_Local_Machine \System\CurrentControlSet\Services\TcpIp\Parameters\DisableDynamicUpdate. By setting this REG_DWORD to a value of 1, you can prevent the client computer from performing dynamic updates. This is useful in a network where the dynamic updates are restricted to DHCP servers.

To add registry entries, complete the following steps:

1. Identify the required registry settings including the registry path, the registry data type, and the acceptable values for the registry setting.
2. Edit the systemroot\inf\sceregvl.inf file. This is the source file used by the Security Templates console for all available security options.
3. Reregister the security configuration client dynamic link library (Scecli.dll) by running REGSVR32 SCECLI.DLL. This reads the changed Sceregvl.inf file and creates a compiled version that alters the Security Options settings listed in Security Templates.

WARNING

---

The next section is relevant if you wish to extend security templates to include additional registry values in the Security Options settings. You won't have to know the parameters within the Sceregvl.inf file for the 70–220 exam.

The Sceregvl.inf File

The Sceregvl.inf file is a setup file provided with Windows 2000. The Sceregvl.inf file is split into three distinct sections:

• Version. Defines the version of the file. Any time you edit the file, you should change the last edited date. This isn't required, but it's useful when you're trying to audit or manage changes to the file.
• Register Registry Values. Contains all registry values that are listed in Security Options with the Security Templates console. For each entry, you have to define the following:
  • Registry path. The full path indicating where the value is set in the Windows 2000 registry.
  • Data type. The data type of the new registry path. Supported types include REG_SZ (1), REG_EXPAND_SZ(2), REG_BINARY(3), REG_DWORD(4), REG_MULTI_SZ(7).
  • Display name. The name that's displayed in the listing of Security Options in the Security Templates console.
  • Display type. Indicates how the user interface appears in order to allow the registry value to be manipulated within the Security Templates console. Display type options include Boolean(0), Number(1), String(2), and Choices(3).

  NOTE

  ---

  Choices is commonly used for registry values that allow specific entries. The Choices data type allows for any number of options and their display string to be included for a security option.

• Strings. Used to expand any variables that may have been used in the [Register Registry Values] section. Strings are commonly used when display names or value lists contain strings that include spaces " ".

The best way to show the syntax is to show the specific entries for one of the security options. A commonly set security option is to suppress the last user's logon name from the Windows 2000 security box. This prevents a user from knowing who previously used the console. For this option, the following values exist in the [Register Registry Values] and [Strings] section of the Sceregvl.inf file:

 [Register Registry Values] MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System      \DontDisplayLastUserName,4,%DontDisplayLastUserName%,0 [Strings] DontDisplayLastUserName = Do not display last user name in logon screen 

The line in the [Register Registry Value] section can be broken down as follows:

• The path to the registry value is HKEY_LOCAL_MACHINE\Software\Microsoft \Windows\CurrentVersion\Policies\System\DontDisplayLastUserName.
• The DontDisplayLastUserName value is a REG_DWORD value type.
• Within the list of security options in the Security Templates console, this option is listed as "Do not display last user name in logon screen." The value %DontDisplayLastUserName% indicates that the expanded string is found within the [Strings] section of the Sceregvl.inf file.
• The 0 indicates that the dialog box presented to an administrator when the administrator configures this option should be for a Boolean setting. This means that the dialog box gives the user the choice of either enabling or disabling the option.

NOTE

---

When you're adding a custom registry entry to the Sceregvl.inf file, it's a good idea to copy an existing registry value within the text file and modify as required to reduce the possibility of incorrect syntax being applied.

Making the Decision

When designing custom registry values to be included in the Security Templates console, use the decision matrix shown in Table 8.6.

Table 8.6 Extending the Security Configuration Tool Set

To	Do the Following
Determine what registry values need to be added	Identify registry values that are commonly modified at Windows 2000–based computers for security configuration as part of the installation process. The registry values may be defined in documentation or knowledge base articles.
Identify the properties of the registry value that must be added to the Sceregvl.inf file.	Identify the properties for a specific registry value by reviewing the Regentry.chm compressed help file included with the Microsoft Windows 2000 Resource Kit, or by reading knowledge base articles or the software documentation.
Protect the original Sceregvl.inf file	Save a copy of the original Sceregvl.inf file in a secure location before making any modifications.
Register the changes in the Security Templates console	Run REGSVR32 SCECLI.DLL at the command prompt. Ensure that the modified Sceregvl.inf file is located in the systemroot\inf folder.
Verify the configuration changes	Open the Security Templates console and verify that the new entry appears in the Security Options settings. Also attempt to apply the setting by using the Security Configuration And Analysis console.
Ensure that all required stations see the modified entries	Register the modified Sceregvl.inf file at all Windows 2000–based computers where the security template will be modified.

Applying the Decision

You must extend the security templates to allow the listening port for the Flower Power application to be changed. This change requires modification of the Sceregvl.inf file at any Windows 2000–based computers where the security templates will be modified.

You must make the following modifications to the Sceregvl.inf file to allow the listening port to be modified:

 [Register Registry Values] Machine\Software\MarketFlorist\FlowerPower\Parameters      \Port,4,%ListenPort%,1   [Strings] ListenPort= Configure the Flower Power Listening Port 

Once you've made the modifications to the Sceregvl.inf file, you must reregister the file by running the command REGSVR32 SCECLI.DLL at the computer with the modified Sceregvl.inf configuration file. You must repeat this process at any workstations where the security template will be defined.

Lesson Summary

Windows 2000 has increased the base security settings from previous versions of Windows NT. By using security templates, you can ensure that consistent security is applied to all Windows 2000–based computers.

When planning the use of security templates, be sure to include decisions on applying default security to all Windows 2000–based computers, when to use the incremental security templates included with Windows 2000, and when to create custom security templates to meet your security goals. The creation of custom security templates may also require extending the Security Configuration Tool Set.