70-240 in 15 minutes a week: Fault Tolerance, Security Configuration and Analysis, and IPS

Thursday May 10th 2001 by ServerWatch Staff

Welcome to article number 12 in my 70-240 in 15 minutes a week series. This weeks article is the final installment in the Windows 2000 Server portion of the series, and covers fault tolerance options, security configuration and analysis, and IPSec and associated policies.

by Dan DiNicolo

Welcome to article number 12 in my 70-240 in 15 minutes a week series. This week's article is the final installment in the Windows 2000 Server portion of the series, and covers fault tolerance options as well as security configuration and analysis. The good news is that this week's article is a little shorter than usual, since we're just tying up loose ends. Next week we'll begin our look at material relating to the Implementing and Administering Active Directory portion of the series, which should last approximately six to seven articles. 

The material that this article will cover includes:

- Windows 2000 Fault Tolerance options
- Security Configuration and Analysis
- Security Template overview
- Introduction to IPSec and associated policies

Windows 2000 Fault Tolerance options

Windows 2000, like Windows NT 4.0, still supports what is commonly referred to as software RAID, or Redundant Array of Independent Disks. In software RAID, the OS handles all RAID functions, and the system does not require a separate RAID controller card. Although the software method is less expensive, it is certainly slower and less reliable than traditional hardware RAID. Windows 2000 supports three types of RAID as described below. Note that all RAID configuration is handled via the Disk Management MMC tool. 

RAID 0 - now referred to as a 'striped volume', this is usually used to speed up access to data. In this configuration, which supports between 2 and 32 physical disks, data is striped evenly across the disks, which act as a single logical volume. Although the name suggests redundancy, there is in fact no redundancy in a RAID 0 configuration. Should a single volume in the striped volume fail, access to data on that volume will be lost. In Windows 2000, new striped volumes can only be created on dynamic disks, although existing stripe sets from NT 4.0 can continue to exist on basic disks in the case of an upgrade. Essentially that means you can have stripe sets if you upgraded, but cannot create new RAID 0 until you upgrade all hard disks that you wish to be part of the new configuration to dynamic disks. Note that neither the system nor boot partitions can reside on RAID 0 volumes.

RAID 1 - referred to as a 'mirrored volume', in this configuration data is mirrored between 2 physical hard disks for the purpose of redundancy. In this configuration (which is very popular for the system or boot partitions) everything written to the first volume in the mirror set is also written to the second by the fault tolerant driver ftdisk.sys. In the event that the first volume in the mirror should fail, the data will still be accessible via the second disk. As with RAID 0 in Windows 2000, new implementations can only be done on dynamic disks. However, mirror sets from NT 4.0 can exist and function (and be repaired) if you performed an upgrade to Windows 2000. RAID 1 implementations do have a cost associated with them, using up twice as much disk space as would normally be necessary.

RAID 5 - referred to as a RAID 5 volume in Windows 2000, it is also commonly known as a stripe set with parity. In this configuration, which can utilize between 3 and 32 physical disks, not only data but also associated parity information is striped across the disks. Data and its associated parity information are always stored on different disks, which ensures that data can be rebuilt (and thus still accessed) in the event of a single disk failure. Again, new RAID 5 volumes can only be created on dynamic disks, although NT 4 stripe sets with parity can continue to exist if you performed an upgrade. As with stripe sets, the system and boot partitions cannot reside on a RAID 5 volume. Also note that there is an overhead associated with RAID 5 volumes - 1/X of the disk space will be used by parity information, where X is the number of disks in the set. 

Security Configuration and Analysis

Windows 2000 provides an MMC snap-in tool for analyzing the security configuration of a system. The Security Configuration and Analysis snap-in allows you to compare the current configuration of a system with settings found in security template files, pointing out inconsistencies between the two settings. Although a system can be configured using this tool, it is usually better to export settings to a template file, which can then be deployed to multiple systems using Group Policy in an Active Directory environment. However, settings can be configured on a system-by-system basis if required. 

The Security Configuration and Analysis tool requires a working database in which to store system configuration information for the purpose of the comparison. This file has an .sdb extension, and must be opened (or created if starting from scratch) prior to importing a security template for the purpose of comparison. After the .sdb file has been created, one of the pre-defined security templates provided with Windows 2000 can be imported, as can any templates that you have created. Imagine that you wanted to check and see whether a certain system on your network met the requirements of your pre-defined enterprise-wide security settings that you have stored in a template. You could simply open a new .sdb file, and then import the template and compare the security settings to those on the system. The analysis will literally show which settings meet, do not meet, or are not defined in the template you imported. As shown below, the password policy on my system does not meet many of the requirements mapped out in a provided template called securews.inf (more on templates coming up). 

The Database Setting section maps out the requirements of the template, while the Computer Setting section shows my current configuration. The green checkmarks indicate that my system meets or exceeds the requirements, while the red circles with the X indicate that my system does not meet the requirement. If neither icon is shown, it simply means that the imported template doesn't have settings for that area configured. You should note that you can import multiple templates, with settings in each template imported overwriting the database settings where conflicts exist, in the order of import. Once you do import a number of templates (or actually make changes to the database settings) you can then export those changes as templates as well. 

As I mentioned earlier, you can also use this tool to configure a system. For example, if you right-click the Security Configuration and Analysis icon as shown below, you have the option to Configure Computer Now. However, the settings that are exported to a template file can also be imported into the Security Settings section of Computer Configuration section of Group Policy, which would allow you to distribute a common configuration to client systems in a centralized manner. Templates can also be imported into the Local Security Configuration. In both cases, the tools refer to importing a template file as 'Import Policy...'

Security Templates

Another MMC snap-in, Security Templates, allows you to view and configure template settings, as well create new templates. Templates files are in an .inf format, readable in any text editor. A small example of the password policy settings of a template file are shown below:

[System Access]
;Account Policies - Password Policy
MinimumPasswordAge = 0
MaximumPasswordAge = 42
MinimumPasswordLength = 0
PasswordComplexity = 0
PasswordHistorySize = 0
RequireLogonToChangePassword = 0
ClearTextPassword = 0

Windows 2000 provides a number of templates by default. You should have an understanding on the provided template files and why you would use them. The names of templates provide an idea of when/how they are to be used. The last two letters in the template file name (before the .inf extension) usually tell you which type of system a template is meant for - WS for a workstation, DC for a domain controller, SV for a server. For example, the hisecws.inf identifies the template as applying highly secure settings to a workstation. Beyond this, there are five main security levels outlined in the default templates, with each outlined below:

Basic*.inf - Basic. These templates apply the default security configuration to a system. These would be useful if you set too high a level of security on a system and wanted to return settings back to the default.

Compat*.inf - Compatible. Windows 2000 gives members of the Users group more strict security settings than in NT 4.0. As such, some applications (such as those certified for NT 4 but not Windows 2000) may not function correctly (or potentially at all) on Windows 2000. When this template is applied, applications run under the Power Users level of privilege, even though the user may not have that level of access.

Secure*.inf - Secure. Contains settings recommended for securing a system except for those relating to files, folders, and registry keys, which are configured securely by default.

Hisec*.inf - Highly Secure. Provides settings to provide a much higher level of protection, including network security. In this configuration, a system can only communicate with other Windows 2000-based systems, for example. 

Dedica*.inf - Dedicated Domain Controller. Contains recommended security settings for a domain controller that is not also acting as an application server.

Template files are stored in %systemroot%\security\templates by default.


Windows 2000 supports IPSec, which can provide for secure network communication between clients by encrypting IP-based data and using Kerberos for authentication. The beauty of IPSec is that is not application-based encryption (which would require that an application on both the sending and receiving computer supported encryption) but rather network-stack based. As such, any TCP/IP-based application is capable of utilizing IPSec, because encryption (and decryption) actually happens in the protocol stack. As such, the encryption is completely application-independent and totally transparent to the user. A diagram of IPSec with relation to the TCP/IP protocol stack is shown below:

Windows 2000 supports IPSec in two modes - transport mode and tunnel mode. In tunnel mode, two endpoints (IP addresses) must be defined, and IPSec will encrypt data (it can also be used for authentication of systems only) that travels through the tunnel. This setup is commonly used in connecting remote offices via VPNs over the Internet. Note that the systems communicating need not necessarily be Windows 2000-based, since IPSec is an open standard. In transport mode, policies can defined which designate when and how IPSec encryption should be used on the network. For example, you could specify that only traffic moving from a client to TCP ports 80 or 23 on a server must be encrypted, and that all other traffic need not be. Similarly, you could specify that a client must initiate encrypted communication with a server or the server will not respond. The level and degree of IPSec use on your network is only dictated by your own needs (don't forget that any encryption will create CPU overhead).

IPSec is controlled on Windows 2000-based system via security policies. Again, these can be configured either locally or via group policy (recommended). At any given time, only one IPSec policy can be assigned to a system. Although you can create custom IPSec policies, three are provided by default (as shown below) and you should be aware of their purposes. 

Client (Respond Only) - When this policy is assigned, a client will never initiate a secure connection with a server, but will use IPSec if requested to do so by a server.

Secure Server (Require Security) - When this policy is assigned, a server will drop any request that is made to it that does not use IPSec. 

Server (Request Security) - When this policy is assigned, a server will request that a client has made an unsecured connection use IPSec. If the client is not capable (for example a Windows 98 system), the server will allow the connection to proceed, without requiring IPSec to be used.

Note that none of the default policies if assigned by default, and that right clicking and choosing 'Create IP Security Policy' can create customized policies. The IP Security policy wizard will walk you though the steps of creating a custom policy, but you must be aware of the filters you are going to configure, including which port numbers are used by applications and so forth. Note also that Windows 2000 provides an application for troubleshooting and monitoring IPSec-based communications, The IP Security Monitor (ipsecmon.exe) as shown below.

And finally the Windows 2000 Server section of the series is complete. Remember that in order to save time, much of the material from the Server and Professional portions of the exam were not repeated. As such, if you are studying for either exam individually, you sure be sure to read all of the Server and Professional articles instead of either section individually. Next week begins the Active Directory Administration and Implementation portion of the series. I'm probably as happy as you are to be finally done with the Server and Professional stuff. I want to again thank everyone for your support of the series - it has been great. Please be sure to visit my website http://www.win2000trainer.com to check out my free practice exams, with now over 25 available. Also, please consider posting technical questions to my message board instead of emailing them to me directly - this way many people will benefit from both the questions and answers provided. As usual, feel free to email me with your questions and comments; I look forward to hearing from you! Best of luck with your studies this week.


Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved