Planning and Implementing Role-Based Security Using Security Templates


As discussed in the beginning of this chapter, security is best achieved through careful planning and attentive administration.

Realizing that you, as a network administrator, may not have the time or detailed knowledge required to create complex security policies on your own, Microsoft has given you a leg up on the bad guys by providing several preconfigured security templates with Windows Server 2003. These preconfigured security templates can be used to implement security settings on servers and workstations quickly and easily. You can think of them in one of two ways: either as a starting point from which to make your own customized security template or as a solution in and of themselves . Neither thought is more correct than the other.

In addition to the preconfigured security templates provided within Windows Server 2003, Microsoft has also done security-minded network administrators everywhere a favor by providing additional role-based security templates in the Windows Server 2003 Security Guide, a free download that you can acquire from http://go.microsoft.com/fwlink/?LinkId=14845. We discuss these role-based security templates later in this chapter.

In simple terms, a security template is little more than a specially formatted flat text file that can be read by the Security Configuration Manager tools. These preconfigured templates have an .inf extension and can be located in the %systemroot%\security\templates folder on your Windows Server 2003 computer. You can use the Security Configuration and Analysis console, the secedit.exe tool, or the Local Security Policy console to apply these templates to a local computer. You can apply templates to an Organizational Unit or domain by importing them into the Security Settings section of the applicable Group Policy using the Group Policy Editor. You also can use these preconfigured templates as a baseline to compare an unknown system against a known set of configuration settings by using the Security Configuration and Analysis console or the secedit.exe tool.

We examine the security templates included with Windows Server 2003 in the next section and then move forward into how they are configured and used after that.

Introducing the Windows Server 2003 Security Templates

Table 1.3 details the preconfigured security templates that ship with Windows Server 2003.

Table 1.3. The Preconfigured Security Templates in Windows Server 2003

Template (Filename)

Description

Default security

( Setup security.inf )

This template is created during the installation of Windows Server 2003 on the computer. This template is variable between one computer to the next, depending on whether the installation was performed as a clean install or an upgrade. Setup security.inf represents the default security settings that the computer started with and thus can be used to reset portions of security as required. This template can be applied to both workstations and member servers, but not to domain controllers and should never be applied via Group Policy due to the large amount of data it contains; it can result in performance degradations.

Default DC security

( DC security.inf )

This template is automatically created when a member server is promoted to domain controller. It represents the file, Registry, and system service default security settings for that domain controller and can be used later to reset these areas to their default configuration.

Compatible

( compatws.inf )

The compatible workstation/member server template provides a means to allow members of the Users group to run applications that do not conform to the Windows Logo Program. Applications that do conform to the Windows Logo Program can be, in the majority of cases, successfully run by members of the Users group without any further modifications required. For applications, that do not conform, two basic choices are available: make the users members of the Power Users group or relax the default permissions of the Users group. The compatible template solves this problem by changing the default file and Registry permissions that are granted to the Users group to allow them to run most applications that are not part of the Windows Logo Program.

As a side effect of applying this template, all users are removed from the Power Users group because the basic assumption is that the template is being applied in an effort to prevent the need for Power Users. This template should not be applied to domain controllers, so be sure not to import it into the Default Domain Policy or the Default Domain Controller Policy.

Secure

( securews.inf , securedc.inf )

The secure templates are the first ones to actually begin the process of locking down the computer to which they are applied. The two secure templates are securews.inf , which is for workstations and member servers, and securedc.inf , which is for domain controllers only.

The secure templates prevent the use of the LAN Manager (LM) authentication protocol. Windows 9 x clients need to have the Active Directory Client Extensions installed to enable NT LAN Manager (NTLM) v2 to allow them to communicate with Windows 2000 and later clients and servers using these templates. These templates also impose additional restrictions on anonymous users, such as preventing them from enumerating account and share information.

The secure templates also enable server message block (SMB) signing on the server side. By default, SMB signing is enabled on client computers. When this template is applied, SMB packet signing is always negotiated between clients and servers.

Highly Secure

( hisecws.inf , hisecdc.inf )

The highly secure templates impose further restrictions on computers they are applied to. Whereas the secure templates require at least NTLM authentication, the highly secure templates require NTLM v2 authentication. The secure templates enable SMB packet signing; the highly secure templates require SMB packet signing.

In addition to the various additional security restrictions that are imposed by the highly secure templates, these templates also make several changes to group membership and the login process. All members of the Power Users group are removed from this group. Also, only Domain Admins and the local administrative account are allowed to be members of the local Administrators group.

When the highly secure templates are used, it is assumed that only Windows Logo Programcompliant applications are in use. As such, there is no provision in place for users to use noncompliant applications because the compatible template is not needed and the Power Users group has no members. Members of the Users group can use applications that are Windows Logo Program compliant. Additionally, members of the Administrators group can use any application they want.

System root security

( Rootsec.inf )

This template defines the root permissions for the root of the system volume. Should these permissions be changed, they can be reapplied using this template. This template also can be modified to apply the same permissions to other volumes . Explicitly configured permissions are not overwritten on child objects when using this template.

No Terminal Server use SID

( Notssid.inf )

This template is used on servers that are not running Terminal Services to remove all unnecessary Terminal Services Security Identifiers (SIDs) from the file system and Registry. This, however, does not increase the security of the server.

WARNING

Templates are incremental All the preconfigured security templates are incremental, meaning that they have been designed to be applied to computers that are using the default security settings. These templates do not implement the default security settings before applying their security settings.


Using the Security Configuration Manager Tools

Plan security for servers that are assigned specific roles. Roles might include domain controllers, Web servers, database servers, and mail servers.

  • Deploy the security configuration for servers that are assigned specific roles.

  • Create custom security templates based on server roles.

Now that you've seen the security templates available for your use, let's take a brief look at the tools available to you for the design, testing, and implementation of these (and other) security templates. The Security Configuration Manager is not one console or tool per se, but instead is actually a collection of tools and utilities that you can use to implement security solutions across your network.

The components of the Security Configuration Manager include

  • The Security Configuration and Analysis snap-in

  • The Security Templates snap-in

  • Group Policy security extensions

  • The secedit.exe command

Each of these tools is examined in the following sections as they relate to implementing security solutions using the preconfigured security templates that are supplied in Windows Server 2003. At this point you need to construct a customized Microsoft Management Console (MMC) that you can use to work with these security templates, as outlined in Step by Step 1.1.

STEP BY STEP

1.1 Creating a Customized Security Console

  1. Open an empty MMC shell by selecting Start, Run and entering MMC in the Open field. Click OK. An empty MMC shell appears, as shown in Figure 1.2.

    Figure 1.2. Starting with an empty MMC shell, you can build any number of customized configuration and management consoles.

  2. Select File, Add/Remove Snap-in to open the Add/Remove Snap-in dialog box. Click Add to open the Add Standalone Snap-in dialog box, shown in Figure 1.3.

    Figure 1.3. You can add a number of snap-ins from here.

  3. Scroll down the Snap-in list and select the Security Configuration and Analysis and Security Templates snap-ins by double-clicking each of them.

  4. Click Close and then click OK to return to the MMC, shown in Figure 1.4.

    Figure 1.4. The customized console is not as empty as it was.

  5. Save the console by selecting File, Save. A standard save dialog box appears. Specify the filename and location to save the console to. By default, the console is saved into the Administrative Tools folder of the currently logged-in user .


Armed with a custom security console, let's move forward and examine how the tools are put to work.

The Security Configuration and Analysis Snap-in

The Security Configuration and Analysis snap-in is an important tool in any administrator's security template toolbox. By using the Security Configuration and Analysis snap-in, you can create, configure, test, and implement security template settings for a local computer. Therein lies its one real weakness: It can be used to work only with the settings of a local computer. You can, however, find ways to get around this limitation by using the other tools that are at your disposal, including secedit.exe and the security extensions to Group Policy, both of which are discussed later in this chapter.

The Security Configuration and Analysis snap-in can be used in two basic modes, as its name suggestsconfiguration and analysisalthough not necessarily in that order. When you're using the Security Configuration and Analysis snap-in to analyze the current system security configuration, no changes are ever made to the computer being analyzed . The administrator simply selects a security template to compare the computer against (either a preconfigured template or a custom created template). The settings from the template are loaded into a database and then compared to the settings currently implemented on the computer. It is possible to import multiple templates into this database, thus merging their settings into one conglomerate database. In addition, you can specify that existing database settings are to be cleared before another template is imported into the database. When the desired security templates have been loaded into the database, any number of analysis actions can be performed, both by the Security Configuration and Analysis snap-in and by the secedit.exe command, as discussed later in this chapter.

After the database has been populated and an analysis scan has been initiated, the Security Configuration and Analysis snap-in examines each configurable Group Policy option and then reports back to you the results of the analysis scan. Each setting is marked with an icon that denotes one of several possible outcomes , such as that the settings are the same, the settings are different, or the settings do not apply. Table 1.4 outlines the possible icons that you might see and what they indicate .

Table 1.4. The Preconfigured Security Template Icons in Windows Server 2003

Icon

Description

Red circle with White X

The item is defined in the analysis database and on the computer but does not match the currently configured setting.

Green check mark

The item is defined in the analysis database and on the computer and matches the currently configured setting.

Question mark

The item is not defined in the analysis database and was not examined on the computer.

Exclamation point

The item is defined in the analysis database but not on the computer.

No special icon

The item is not defined in the analysis database or the computer.

NOTE

Not all computers are created equal You can expect that not every computer has the same security settings initially. Your results, when performing this process, may vary depending on the initial state of the computer being used for the analysis.


The best way to begin to understand the Security Configuration and Analysis snap-in is to work with it. Step by Step 1.2 presents the process of comparing the security configuration of a Windows Server 2003 member server to that of the securews.inf template.

STEP BY STEP

1.2 Using the Security Configuration and Analysis Snap-in to Analyze Settings

  1. From the customized security console you created in Step by Step 1.1, select the Security Configuration and Analysis node. Notice that Security Configuration and Analysis actually provides you with some instructions as to how to proceed.

  2. Right-click the Security Configuration and Analysis node and select Open Database from the context menu. The Open Database window appears, as shown in Figure 1.5.

    Figure 1.5. You can either load an existing database or create a new one.

  3. Because you do not have an existing database, create a new one by entering the name security1 into the File Name field and click Open to open it.

  4. On the Import Template page, shown in Figure 1.6, select the security template you are loading into the database. In this exercise, you should use the securews.inf template. If this is an existing database that you want to clear out before starting the analysis, be sure to select the Clear This Database Before Importing option. Click Open after you make your selections. The Security Configuration and Analysis snap-in appears again.

    Figure 1.6. You need to select a template to load into the database.

  5. To perform the analysis operation, right-click the Security Configuration and Analysis node and select Analyze Computer Now to start the analysis. The Perform Analysis dialog box appears.

  6. Provide a pathname and filename for an error log. In most cases, the default pathname and filename, as shown in Figure 1.7, are suitable, but you can change this as required. Click OK to start the analysis process. You briefly see the Analyzing System Security dialog box, shown in Figure 1.8.

    Figure 1.7. The error log keeps track of any errors encountered during the analysis process.

    Figure 1.8. The Analyzing System Security dialog box keeps you apprised of the computer's progress in the analysis.

    When the analysis is complete, you are returned to the Security Configuration and Analysis snap-in, except that now it has been populated and looks similar to what you might expect to see in the Group Policy Editor, as shown in Figure 1.9.

    Figure 1.9. The analysis output resembles the information shown in the Group Policy Editor.

  7. Open the Account Policies\Password Policy node, as shown in Figure 1.10, and you can see that some items are not in agreement between the database settings and the computer settings.

    Figure 1.10. You can quickly determine the status of the computer against the settings of the security template.


As shown in Figures 1.9 and 1.10, you can analyze and configure several areas by using the Security Configuration and Analysis snap-in:

  • Account Policies This node contains items that control user accounts. In Windows NT 4.0, these items are managed from the User Manager for Domains. This node has two subnodes: Password Policy and Account Lockout Policy. The Password Policy node deals with account password- related items, such as minimum length and maximum age. The Account Lockout Policy node contains options for configuring account lockout durations and lockout reset options.

  • Local Policies This node contains policies that are applied to the local machine. This node has three subnodes: Audit Policy, User Rights Assignment, and Security Options. The Audit Policy node is relatively self-explanatory: It offers options for configuring and implementing various auditing options. The User Rights Assignment node contains miscellaneous options that deal with user rights, such as the ability to log in to a computer across the network. The Security Options node contains many other optionssuch as the option to set a login banner or allow the system to be shut down without being logged in firstthat previously could be edited only in the Windows NT 4.0 Registry or by using System Policies.

  • Event Log This node contains options that allow you to configure the behavior and security of the event log. In this node, for example, you can include maximum log sizes and disallow guest access to the event logs.

  • Restricted Groups This node allows you to permanently configure which users are allowed to be members of specific groups. For example, company policy may provide the ability to perform server backups to a specific group of administrators. If another user who is not otherwise authorized with these privileges is added to this group and not removed after he or she has performed the intended function, you have created a security problem because the user has more rights than normally authorized. By using the Restricted Groups node, you can reset group membership to the intended membership.

  • System Services This node allows you to configure the behavior and security assignments associated with all system services running on the computer. Options include defining that a service is to start automatically or be disabled. In addition, you can configure the user accounts that are to have access to each service.

  • Registry This node allows you to configure access restrictions that specify who is allowed to configure or change individual Registry keys or entire hives. This option does not provide you with the means to create or modify Registry keys, however; that must still be done by using the Registry Editor.

  • File System This node allows you to set folder and file NTFS permissions. This is especially handy if you need to reset the permissions on a large number of folders or files.

After a security settings analysis is completed and you have examined the results, you can begin the process of determining what changes need to be made. You can configure your changes directly into the database by using the Security Configuration and Analysis snap-in, or you can create or edit a security template by using the Security Templates snap-in, as discussed in the next section. When you use the Security Configuration and Analysis snap-in to make changes, your changes reside only in the database until you do one of two things: export the database to a security template file or apply the database settings to the computer. When you work with the Security Templates snap-in, you actually make changes directly to the template and need to save it when you're finished. The result is the same no matter which way you go about it.

EXAM TIP

For the Local Computer Only Remember that the Security Configuration and Analysis snap-in can be used only to apply the settings to the local computer. You need to export the database to a security template if you want to apply the settings to another computer or to a larger scope of computers, such as a domain or an OU.


The second part of the Security Configuration and Analysis snap-in is configurationthe process of actually applying the settings contained in the database to the local computer. Before you apply the settings to the computer, you should have first completed the analysis as detailed in Step by Step 1.2. After you do so and are happy with the configuration (or have edited the configuration to suit your needs), you can apply the settings by right-clicking the Security Configuration and Analysis node and selecting Configure Computer Now from the context menu. You are again asked for the pathname and filename of the error log. After you provide this information, the settings in the database are applied to the computer. Running the analysis again confirms this by showing that all items are now in agreement.

As mentioned previously, if you need to get the database settings out and into the form of a security template, you need to simply right-click the Security Configuration and Analysis node and select Export Template from the context menu. The Export Template To window appears, as shown in Figure 1.11, prompting you to enter the path and filename of the security template. You should be sure to use a unique name; in other words, do not save over one of the preconfigured security templates because you might need it again in the future.

Figure 1.11. Be sure to specify a unique name for your exported template to avoid overwriting a preconfigured security template.

The Security Templates Snap-in

The Security Templates snap-in, shown in Figure 1.12, might at first seem to have no real purpose. However, this is not the case at all. You can use this snap-in to modify existing templates or create new ones from scratch without the danger or possibility of accidentally applying the template to the computer or GPO.

Figure 1.12. The Security Templates snap-in allows you to work with existing and new templates.

To customize an existing template, you simply begin making changes to it to suit your requirements. When you are done, you should save it with a new name by right-clicking on it and selecting Save As from the context menu. The standard save dialog box that allows you to specify the path and filename of the template appears.

To start with a completely empty templatein which no settings are preconfiguredyou can right-click the template location and select New Template, as shown in Figure 1.13.

Figure 1.13. You can easily create a new (blank) template if you desire .

GUIDED PRACTICE EXERCISE 1.1

In this exercise, you create your own security template to meet the following requirements:

  • You want to require all users to configure passwords that are at least 10 characters long. Additionally, the users' passwords must contain characters other than letters and numbers .

  • You want to prevent users from reusing the same password in the next 24 passwords they enter. You also want to force users to change their passwords after 30 days have passed.

  • You want to prevent users from cycling through a list of passwords to get back to their favorite one.

  • You want to lockout user accounts after five incorrect login attempts. These user accounts are to be locked out for 45 minutes, and the lockout counter also should be reset after 45 minutes.

You should try this exercise on your own first. If you get stuck, or you would like to see one possible solution, follow these steps:

  1. Open or create an MMC that contains the Security Templates snap-in.

  2. Right-click on the template location (that is, C:\WINDOWS\Security\Templates ) and select New Template from the context menu.

  3. Provide a descriptive name such as Account Security Policy and a longer description as desired; then click OK.

  4. In the Security Templates snap-in, double-click the newly created security template to expand its top-level nodes.

  5. Expand the Account Policies node and open the Password Policy node.

  6. Double-click the Minimum Password Length item. Select the Define This Policy Setting in the Template option. Change the numerical value to 10 and click OK.

  7. Double-click the Passwords Must Meet Complexity Requirements item. Select the Define this Policy Setting in the Template option. Select the Enabled radio button and click OK.

  8. Double-click the Enforce Password History item. Select the Define This Policy Setting in the Template option. Change the numerical value to 24 and click OK.

  9. Double-click the Maximum Password Age item. Select the Define This Policy Setting in the Template option. Change the numerical value to 30 and click OK.

  10. When prompted to accept changes to the Minimum Password Age item, click OK.

  11. Double-click the Minimum Password Age item. Ensure the Define This Policy Setting in the Template option is selected. Change the numerical value to 5 and click OK.

  12. Open the Account Lockout Policy node.

  13. Double-click the Account Lockout Threshold item. Ensure the Define This Policy Setting in the Template option is selected. Change the numerical value to 5 and click OK.

  14. When prompted to accept changes to the Account Lockout Duration and Reset Account Lockout Counter After items, click OK.

  15. Double-click the Account Lockout Duration item. Ensure the Define This Policy Setting in the Template option is selected. Change the numerical value to 45 and click OK.

  16. Double-click the Reset Account Lockout Counter After item. Ensure the Define This Policy Setting in the Template option is selected. Change the numerical value to 45 and click OK.

  17. Right-click on the security template name on the left side of the window and select Save from the context menu.


Group Policy Security Extensions

Using the Security Configuration and Analysis snap-in is certainly not the only way to apply a security template to a computer. Imagine the amount of time and effort involved in applying a security template locally at each computer using the Security Configuration and Analysis snap-in. As difficult and time-consuming as that process would be, try to imagine using this approach on several different types of computers to implement a role-based security solution. In this case, you would have the added hassle of trying to remember which template goes on what computer.

Fortunately, you can easily and quickly import security templates into GPOs by using the Group Policy Editor. Step by Step 1.3 outlines this process.

STEP BY STEP

1.3 Importing a Security Template into a GPO

  1. Open the Active Directory Users and Computers console by selecting Start, Programs, Administrative Tools, Active Directory Users and Computers.

  2. Locate the domain or OU to which you want to apply the security template. In this example, we apply the securews.inf template to the Sales OU.

  3. Right-click the Sales OU and select Properties from the context menu. The Sales Properties dialog box appears. Switch to the Group Policy tab, as shown in Figure 1.14.

    Figure 1.14. You need to create a new GPO if no GPOs exist already.

  4. To create a new GPO, click the New button. Supply a name for the new GPO and press Enter.

  5. Click the Edit button to open the Group Policy Editor for the selected GPO.

  6. Expand the nodes as follows : Computer Configuration, Windows Settings, Security Settings. Right-click the Security Settings node and select Import Policy from the context menu, as shown in Figure 1.15.

    Figure 1.15. You can import a security template into the Group Policy Editor.

  7. The Import Policy From dialog box, shown in Figure 1.16, appears, providing a list of the preconfigured security templates. You can navigate to another location if desired to use another security template.

    Figure 1.16. You select the security template that you want to import into the GPO.

    The settings configured in the template are now applied to the GPO and will be applied during the next Group Policy refresh cycle.


Note that you can also perform this process at the domain level to apply security settings to all computers within the domain. As previously discussed, you should apply the most generic settings at the domain level and then at the OU level apply specific settings that pertain to the computers in that OU.

GPO PROCESSING

Group Policy Objects (GPOs) are the basic building blocks of Group Policy. As you've seen several times in this chapter already, GPOs can be applied at several different levels within your network. Additionally, any settings that are applied to a parent object are, by default, passed along to all child objects through inheritance. Group Policy is applied and processed by Windows Server 2003 in the following order:

  • Local The local GPO (there can be only one) is applied first to a computer. It can be overwritten by the GPOs at the remaining processing levels.

  • Site GPOs linked at the site level are applied next and will, by default, be applied to objects contained within the site.

  • Domain GPOs linked at the domain level are applied next and will, by default, be applied to all objects contained within that domain.

  • OU GPOs linked at the Organizational Unit level are applied next and will, by default, be applied to all objects contained within that OU.

As mentioned, by default the GPO settings that are applied later will override the GPO settings that were applied earlier. This default behavior can be modified, however, if desired to produce different results. For a more in-depth discussion on Group Policy processing, see MCSE 70-294 Training Guide: Planning, Implementing, and Maintaining a Microsoft Windows Server 2003 Active Directory Infrastructure by Eric Rockenbach and Don Poulton (2003, Que Publishing; ISBN: 0789729490).


secedit.exe

We have spent a good amount of time so far in this chapter examining the ways you can work with security templates by using the Windows GUI. But what about the command line? As you might have guessed, there is a command-line alternative to the Security Configuration and Analysis snap-in, and it comes in the form of the secedit.exe command.

You can use secedit to perform the same functions as the Security Configuration and Analysis snap-in, plus a couple of additional functions not found in the snap-in. The secedit command has the following top-level options available for use:

  • /analyze This option allows you to analyze the security settings of a computer by comparing them against the baseline settings in a database.

  • /configure This option allows you to configure the security settings of the local computer by applying the settings contained in a database.

  • /export This option allows you to export the settings configured in a database to a security template .inf file.

    EXAM TIP

    Viewing the Results of a Security Analysis You need to view the results of a security analysis in the Security Configuration and Analysis snap-in by opening the database created during the analysis. At first, you might feel that running the analysis from the command line and then viewing the results in the GUI is counterproductive. In reality, the opposite is the case. Say you run secedit from a script on multiple computers. You can then view the databases, one for each computer, in the GUI at your leisure to determine what changes need to be made to the security settings on the computers. You can use the % computername % variable when creating the database and log files to create one set of results for each computer being scanned.


  • /import This option allows you to import the settings configured in a security template .inf file into a database. If you will be applying multiple security templates to a database, you should use this option before performing the analysis or configuration.

  • /validate This option validates the syntax of a security template to ensure that it is correct before you import the template into a database for analysis or configuration.

  • /GenerateRollback This option allows you to create a rollback template that can be used to reset the security configuration to the values it had before the security template was applied.

Of the available options, you will most often make use of the /analyze and /configure switches. Examples and explanations of their usage are provide here.

To analyze the current security configuration of the local computer, you issue the secedit command with the following syntax:

 
 secedit /analyze /db  FileName  /cfg  FileName  /overwrite /log  FileName  /quiet 

The secedit /analyze parameters are explained in detail in Table 1.5.

Table 1.5. The secedit /analyze Parameters

Switch

Description

/db FileName

This switch specifies the pathname and filename of the database to be used to perform the analysis.

/cfg FileName

This switch specifies the pathname and filename of the security template that is to be imported into the database before the analysis is performed.

/overwrite

This switch specifies that the database is to be emptied before the security template is imported.

/log FileName

This switch specifies the pathname and filename of the file that is used to log the status of the analysis process. By default, a log named scesrv.log is created in the %windir%\security\logs directory.

/quiet

This switch specifies that the analysis process should take place without further onscreen comments.

For example, suppose that you want to analyze the settings on a computer compared to the settings contained in the securews.inf template. You could issue the following command to perform this function:

 
[View full width]
 
[View full width]
secedit /analyze /db c:\sectest.sdb /cfg C:\WINDOWS\security\templates\securews.inf /log c:\sectest.log

To configure the current security configuration of the local computer, you issue the secedit command with the following syntax:

 
[View full width]
 
[View full width]
secedit /configure /db FileName /cfg FileName /overwrite /areas Area1 Area2 ... /log FileName /quiet

The secedit /configure parameters are explained in detail in Table 1.6.

Table 1.6. The secedit /configure Parameters

Switch

Description

/db FileName

This switch specifies the pathname and filename of the database to be used to perform the analysis.

/cfg FileName

This switch specifies the pathname and filename of the security template that is to be imported into the database before the analysis is performed.

/overwrite

This switch specifies that the database is to be emptied before the security template is imported.

/areas

This switch specifies the security areas that are to be applied to the system. By default, when this parameter is not specified, all security areas are applied to the computer. The following options are available:

GROUP_MGMT This area is the Restricted Group settings.

USER_RIGHTS This area is the User Rights Assignment settings.

REGKEYS This area is the Registry permissions settings.

FILESTORE This area is the File System permissions settings.

SERVICES This area is the System Service settings.

/log FileName

This switch specifies the pathname and filename of the file that is used to log the status of the analysis process. By default, a log named scesrv.log is created in the %windir%\security\logs directory.

/quiet

This switch specifies that the analysis process should take place without further onscreen comments.

For example, suppose that you want to configure the settings on a computer with the settings in the securews.inf template. You could issue the following command to perform this function:

 
[View full width]
 
[View full width]
secedit /configure /db c:\sectest.sdb /cfg C:\WINDOWS\security\templates\securews.inf /log c:\sectest.log

Using Role-Based Security Templates

Configure security for servers that are assigned specific roles.

Plan security for servers that are assigned specific roles. Roles might include domain controllers, Web servers, database servers, and mail servers.

  • Deploy the security configuration for servers that are assigned specific roles.

  • Create custom security templates based on server roles.

Now that you have seen the preconfigured security templates provided with Windows Server 2003 and also the tools of the Security Configuration Manager, you are ready to move forward and implement role-based security solutions for your network. Looking back again at Figure 1.1, you can see how security policies are applied at several nested levels in the sample network.

Referring specifically to servers, you thus apply security policies (via security templates and GPOs) at the three following hierarchical levels:

  • Domain The most common security requirements, such as password and account lockout policies, are applied at the domain level. These policies are applied to all computersservers and workstations alikewithin the domain.

  • Baseline This policy contains security configuration items that apply to all member servers, such as auditing policies and user rights assignments. In the example shown in Figure 1.1, baseline policies are applied through the Domain Controller Policy, Client Computer Policy, and Member Server Policy.

  • Role-specific To address the specific security needs of each specific server role, member servers are divided into role-based groups using OUs and have specific, individual security policies applied to them. In the example shown in Figure 1.1, the role-specific policies are applied through the File Servers Policy, Print Servers Policy, and so on.

As you can see, the first step in successfully establishing role-based security is dividing computers by role. After that task has been accomplished, the Domain and Baseline Policies must be implemented by importing them into the applicable Group Policy Objects. Because these security templates are incremental in nature, you are expected to have applied these higher-level policies before attempting to subsequently apply the role-specific security policy. Also, to achieve the best results from a role-based security plan, your member servers should be performing only one specific function, such as print server, file server, IIS server, and so on. When member servers perform multiple functions, the level of complexity increases rapidly in regards to managing, maintaining, and securing them.

As discussed earlier in this chapter, the Windows Server 2003 Security Guide (located at http://go.microsoft.com/fwlink/?LinkId=14845) contains several excellent security templates that can be used to quickly and uniformly create a role-based security solution for your Windows Server 2003 network. This guide actually includes the following three sets of security templates:

  • Legacy Client The least secure environment, these security polices are designed for networks using Windows Server 2003 or Windows 2000 Server domain controllers and member servers. Clients run Windows 98 or Windows NT 4.0, Windows 2000, or Windows XP Professional.

  • Enterprise Client A fairly secure environment where the network uses Windows Server 2003 domain or Windows 2000 Server controllers and member servers. Clients run Windows 2000 or Windows XP Professional.

  • High Security An extremely secure environment where the network uses Windows Server 2003 or Windows 2000 Server domain controllers and member servers. Clients run Windows 2000 or Windows XP Professional. Due to the extremely restrictive settings contained in these security policies, many applications may fail to function properly. Network useability will decline, and management of workstations and servers becomes very difficult.

WARNING

Test before deployment Although Microsoft thoroughly tested the default security templates provided with Windows Server 2003 and the additional security templates provided in the Windows Server 2003 Security Guide in a lab environment, this does not alleviate you of the same responsibility. It is nothing short of foolish to blindly apply any security template to a production environment without thorough testing and evaluation in a lab environment that closely mimics your actual production network.


Table 1.7 outlines the typical Windows Server 2003 server roles and the security templates supplied for each of these respective roles.

Table 1.7. The Windows Server 2003 Server Roles

Server Role

Security Template

Domain Controller

Enterprise Client - Domain Controller.inf

Member Servers

Enterprise Client - Member Server Baseline.inf (applied to all member servers)

Certificate Services servers

Enterprise Client - CA Server.inf

File servers

Enterprise Client - File Server.inf

Infrastructure servers (DHCP, WINS)

Enterprise Client - Infrastructure Server.inf

Internet Authentication Server (IAS) servers

Enterprise Client - IAS Server.inf

Internet Information Services (IIS) servers

Enterprise Client - IIS Server.inf

Print servers

Enterprise Client - Print Server.inf

Bastion Hosts (DMZ servers)

High Security - Bastion Host.inf

NOTE

No DNS Server Security ? Notice that DNS servers are not listed anywhere among the possible Windows Server 2003 server roles. The reason is that, in the most secure environment, all domain controllers are also DNS servers, thus providing for the best security and replication possible.


The specifics associated with the security settings applied to each server role are far too numerous to lend themselves to discussion here; however, as you might expect, they are specifically crafted for each role.



MCSE Windows Server 2003 Network Infrastructure (Exam 70-293)
MCSE 70-293 Exam Prep: Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (2nd Edition)
ISBN: 0789736500
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Will Schmied

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net