Step-by-Step Guide to Using the Security Configuration Tool Set

The Security Configuration Tool Set allows you to configure the following security areas:

Area
Configurable Items
Account Policies Password, lockout, and Kerberos settings.
Local Policies Audit, user rights, and security options.
Event Log Settings for system, application, security and directory service logs.
Restricted Groups Policy regarding group membership.
System Services Startup modes and access control for system services.
Registry Access control for registry keys.
File System Access control for folders and files.

Administrators can use the following components of the Security Configuration Tool Set to configure some or all of the security areas described above:

Security Templates snap-in. The Security Templates snap-in is a stand-alone Microsoft Management Console (MMC) snap-in that allows the creation of a text-based template file that contains security settings for all security areas.
Security Configuration and Analysis snap-in. The Security Configuration and Analysis snap-in is a stand-alone MMC snap-in that can configure or analyze Windows 2000 operating system security. Its operation is based on the contents of a security template that was created using the Security Templates snap-in.
Secedit.exe. Secedit.exe is a command-line version of the Security Configuration and Analysis snap-in. It allows security configuration and analysis to be performed without a graphical user interface (GUI).
Security Settings extension to Group Policy. The Security Configuration Tool Set also includes an extension snap-in to the Group Policy editor to configure local security policies as well as security policies for domains or organizational units (OUs). Local security policies only include the Account Policy and Local Policy security areas described above. Security policies defined for domains or OUs can include all security areas.
This step-by-step guide describes how to use the snap-ins, command-line tool, and Security Settings extension to view, configure, and analyze local security policy and local security settings.

Requirements and Prerequisites
This guide assumes that you have run the procedures in the two-part "Step by Step Guide to A Common Infrastructure for Windows 2000 Server Deployment." The common infrastructure documents specify a particular hardware and software configuration. If you are not using the common infrastructure, you need to make the appropriate changes to this document. The most current information about hardware requirements and compatibility for servers, clients, and peripherals is available at the Product Compatibility Web site.

Viewing and Modifying Local Security Policy
Local security policy is exposed through the Security Settings extension to Group Policy. Local security policy includes the Account Policy and Local Policy areas only. The Account Policy area contains password and lockout information. The Local Policy area contains audit, user rights, and security options information.

To view local security policy:

Log on to a Windows 2000-based computer as a user with administrative privileges. In our example, we log on as Administrator to the server named HQ-RES-SRV-01.
To open the Group Policy console, click Start, click Run and type Gpedit.msc. Click OK.
Click the + next to Computer Configuration, then Windows Settings, then Security Settings, and then Local Policies to expand these folders.
Click the Security Options folder under Local Policies. Your window should be similar to the one shown below in Figure 1.

Figure 1. Security Options

For each security setting, notice that the Security Settings extension displays the local policy and an effective policy. Local Policy describes policy settings as they are defined on the local computer. Effective policy describes the combined local, domain, and organizational unit policies for each setting. This distinction is made because local policy settings can be overwritten by domain or OU policy settings. The order of precedence for policies is from lowest to highest:

Local Policy
Domain Policy
OU Policy
Local Policy has the least precedence and the OU that directly contains the computer has the highest precedence. The effective policy column displays the security policy in effect based on these precedence rules.

Modifying local security policy
To modify a local security policy setting, double-click the security item of interest and revise the policy. For example, to change the minimum password age defined by the local password policy:

Click the + next to Account Policies in the left pane (under Security Settings) to expand it.
Click Password Policy.
Double-click Minimum Password Age in the right pane.
Set a Minimum Password Age of 1 day, and click OK.
When you OK the policy change, policy propagation is triggered, which causes an effective policy to be computed (based on any overriding domain or OU policies) and applied to the system. Status regarding this policy propagation is available in the application event log.

Right-click Security Settings (in the left pane), and then click Reload.
Reloading the local policy updates the effective policy in the user interface. Depending on domain or OU password policies that are in effect, the effective policy may or may not have changed on your computer.

Close the Group Policy console.

Working with security templates
The Security Templates snap-in allows you to create a text-based template file that can contain security settings for all of the security areas supported by the Security Configuration Tool Set. You can then use these template files to configure or analyze system security using other tools.

You can import a template file into the Security Settings extension to configure local, domain, or OU security policy.
You can use the Security Configuration and Analysis snap-in to configure or analyze system security based on a text-based security template.
You can use the Secedit.exe command-line tool directly or in conjunction with other management tools such as Microsoft Systems Management Server or Task Scheduler to deploy a security template or trigger a security analysis.
To load the Security Templates snap-in:

Click Start, click Run, and then type MMC /s into the text box and click OK. (Note: there is a space between the C and the /s).
Click Console (under Console1 in the upper right of the window), click Add\Remove Snap-in, and click Add.
From the list of available Standalone Snap-ins, select Security Templates, as shown in Figure 2 below.

Figure 2. Adding the Security Templates snap-in

Click Add, then click Close.
Click OK.
Click the + next to Security Templates in the left pane to expand it.
Click the + next to C:\WINNT\security\templates to expand it. (Note: if you installed Windows 2000 in a different drive and/or directory, that path will display instead of C:\WINNT.)
Windows 2000 ships with several predefined security templates. Please see the section, Predefined Security Templates, in this paper for more information.

Modifying a Security Template
You can create your own security template by right-clicking the default templates folder (C:\WINNT\security\templates) under Security Templates and selecting New Template. (Note: If you installed Windows 2000 in a different drive and/or directory, that path will display instead of C:\WINNT.) However, in this guide you are going to modify the predefined secure workstation or server template (Securews.inf) that is included with Windows 2000.

To view the settings defined by Securews.inf:

In the left pane, scroll down and then Click the + next to Securews to expand it. Notice in Figure 3 below that (unlike the local security policy covered in the previous two sections) all security areas are configurable when you define a security template.

Figure 3. Reviewing settings defined by Securews.inf

Browse the Account Policies and Local Policies defined by Securews by expanding those folders, selecting the different areas and viewing the Stored Template settings in the right pane.
Displaying a Custom Logon Message
You can modify the Securews to display a custom message to all users who log on.

Click the Security Options node under Local Policies.
In the right pane, scroll down and then double-click Message Text for Users Attempting to log on.
Type a message that will be displayed to all users when they log on, and click OK.
Creating a Restricted Group Policy
A Restricted Group Policy allows you to define who should and should not belong to a specific group. When a template (or policy) that defines a restricted group is applied to a system, the Security Configuration Tool Set adds members to the group and removes members from the group to ensure that the actual group membership coincides with the settings defined in the template (or policy). In this procedure, you will define a restricted group policy for the Local Administrators group in addition to the restricted group policy that is already defined for the local Power Users group in Securews.inf.

To create the restricted group policy:

In the left pane, right-click Restricted Groups, and select Add Group.
Type NewAdmins as the group name and click OK. The local Administrators group is added as a restricted group in the right pane of the Security Templates snap-in.
Double-click Administrators in the right pane.
You can now define who should be a member of the Administrators group and specify other groups that the Administrators group can be a member of.

Click Add and then click Browse. The Select Users or Groups dialog appears as shown in Figure 4 below.
Select the Administrator user in the Select Users or Groups dialog. Click Add.

Figure 4: Select Administrator

Click OK, and then click OK twice more.
This restricted group policy states that only the local administrator user can belong to the Administrators local group when the Securews template is used to configure a Windows 2000 system. During configuration, the tool set removes all other users that belong to the Administrators group at the time of configuration. Similarly, if (at the time of configuration) the Administrator user does not belong to the Administrators group, the Security Configuration Tool Set adds the Administrator user to the Administrators group.

If the Members list is empty–If no users are specified as members of a defined restricted group (the top box is empty), the Security Configuration Tool Set removes all current members of that group when the template is used to configure a system.
If the Member of list is empty–If no groups are specified for a restricted group to belong to (the bottom box is empty), no action is taken to adjust membership in other groups.
Configuring Permissions for a File System Directory
You can use Securews to configure permissions for file system directories as well.

Right-click File System in the left pane, and click Add File.
Click the %systemroot%\repair directory as shown in Figure 5 below. Click OK.

Figure 5. Configuring file system permissions — selecting the repair directory

The Access Control List (ACL) Editor shown in Figure 6 below appears. This allows you to specify permissions for the %systemroot%\repair directory in the Securews.inf template.

Figure 6. Using the ACL Editor to specify permissions

Select the Everyone group in the top pane and click the Remove button.
Click the Add button and select the Administrators group. Click Add and click OK.
Click the Full Control checkbox in the bottom pane to give the Administrators group full control permissions.
Clear the Allow inheritable permissions from parent to propagate to this object checkbox.
Click OK to accept the Administrator-only permissions defined for the directory.

Figure 7: Template Security Policy Setting

Select the Replace existing permission on all subfolders and file with inheritable permissions button and click OK.
Inheriting, Overwriting, and Ignoring Policy Changes
After you define permissions for a file system or registry object, the Security Configuration Tool Set asks you how the object's children should be configured.

If you select Propagate inheritable permissions to all subfolders and files, normal Windows 2000 ACL inheritance procedures are in effect. Specifically, any inherited permissions on child objects are adjusted according to the new permissions defined for this parent. Any explicit access control entry (ACE) defined for a child object remains unchanged.

If you select Replace existing permission on all subfolders and files with inheritable permissions, all explicit ACEs for all child objects (which are not otherwise listed in the template) are removed, and all child objects are set to inherit the inheritable permissions defined for this parent.

To prevent a child object from being overwritten by a parent, the child object can be added to the template and ignored. If a child object is added to the template and ignored, then that child's inheritance mode and that child's explicit ACEs remain untouched. Choosing the option: Do not allow permissions on this file or folder to be replaced for an object in a template makes sense only if an ancestor of that object is configured to overwrite children. If no ancestor exists in the template, ignoring an object has no impact. If an ancestor exists but is configured such that children inherit, then ignoring a child has no impact.

In this example, the ACL configuration for the %systemroot%\repair directory in the Securews.inf template is defined as follows:

Administrators have full control on the %systemroot%\repair directory. By default, these full control permissions apply to this folder, subfolders, and files. You specified this when you defined the Administrator permissions in the ACL Editor.
Note: The degree to which an ACE is inheritable is specified in the Advanced tab of the ACL Editor under the Apply to column. This walkthrough did not examine the Advanced tab when defining the permissions for Administrator.

The %systemroot%\repair directory does not inherit any permissions from its parent. You specified this when you cleared the Allow inheritable permissions from parent to propagate to this object checkbox in the ACL Editor.
All ACLs on all subfolders and files of the repair directory are configured such that they inherit the inheritable Administrators full control permission from this parent, regardless of their current configuration. You specified this when you selected the Replace existing permission on all subfolders and files with inheritable permissions mode of operation.
To save your customized Securews.inf file:

Right-click Securews.inf, click Save As, and type Mysecurews and click Save.
Exit the Security Templates snap-in console by clicking the Close button in the upper right corner.
Click Yes to save the console settings
Save the console as Security Templates. This allows you to start the Security Templates snap-in without having to add it to a console in the future.

Performing a Security analysis
You can analyze current system settings against a baseline template at anytime. Performing an analysis is useful for several different reasons:

To identify security holes that may exist in a current configuration.
To identify changes that a potential security policy may impart to a system, before actually deploying the security policy.
To identify deviations from a policy that is currently imposed on a system.
During this part of the guide, you will analyze the current system settings against the custom security template you created in the previous section. If you assume that the custom security template defines a more secure configuration, this analysis should identify security holes that may exist in the current system configuration, and can also identify changes that will take place if this template is used to configure the system.

To load the Security Configuration and Analysis MMC snap-in:

On the Start menu, click Run and type: MMC /s
From the Console menu, select Add\Remove Snap-in, and click Add.
Select Security Configuration and Analysis.
Click Add and then click Close. Click OK.
Creating a Database
All configurations and analyses are database-driven. Therefore, you must get the baseline analysis template into a database prior to performing the analysis operation.

To create the database

Click Security Configuration and Analysis in the left pane.
Right-click Security Configuration and Analysis in the left pane.
Click Open Database.
Type Mysecurews.sdb as the name of the database.
Click Open.
Select Mysecure.inf as the security template to import into the database.
Click Open.
Notice that the name of the database is now exposed in the result pane and that there are several more options on the context menu for Security Configuration and Analysis.

To perform the analysis

Right-click Security Configuration and Analysis, and then select Analyze Computer Now, from the context menu shown in Figure 8 below.

Figure 8. Analyze Computer option

Specify the log file for the analysis operation as follows: (note: you can find this also by clicking the browse button instead of typing it in)
%windir%\security\logs\Mysecurews.log
where %windir% is the drive and path to your Windows directory; for example:
C:\WINNT\security\logs\Mysecure.log

Click Open and then click OK. A progress dialog like the one show in Figure 9 below displays as the analysis proceeds.

Figure 9. Analyzing System Security Progress Report

Reviewing the Analysis Results
After the analysis has completed, the security areas are available under the Security Configuration and Analysis node.

To review the results

From the Security Configuration and Analysis node, click View.
Select the Description Bar to expose the database you are currently working with.
Expand Security Configuration and Analysis in the left pane, and then expand Local Policies, and then click Security Options as shown in Figure 10 below.

Figure 10. New Security Settings

In the right pane, both database and actual system settings are displayed for each object. Discrepancies are highlighted with a red flag. Consistencies are highlighted with a green check mark. If there is no flag or check mark, the security setting is not specified in the database (that is, the security setting was not configured in the template that was imported).

You can double-click any setting in the result pane to investigate discrepancies further and modify database settings if desired.

For example:

Expand the File System node in the left pane.
Expand the %windir% directory (for example, C:\WINNT).
Right-click the Repair directory.
Note that files contained in the repair directory are also highlighted as being OK or mismatched. When a template specifies a container object in overwrite mode (which was the case when we configured the repair directory) all children of that object are analyzed for compliance. Child objects that do not inherit from the parent are flagged as mismatched because overwrite implies that all children (not otherwise specified in the template) should inherit from the parent. Child objects that are inheriting from the parent (and contain no explicit ACEs of their own) are flagged as matches even if they are currently inheriting a different DACL than the one specified by the parent in the template. In this latter case, the relevant mismatch was flagged on the parent itself.

Select Security. You can view the analyzed permissions, the database permissions, or both.
Click View Security then click OK. (Note that you cannot modify the actual system settings while viewing analysis results.)
Drag the Last Analyzed Security dialog out of the way, and click Edit Security in the previous window. Line up the windows side by side as shown:

Figure 11. Compare Repair ACL

You can see the discretionary access control list (DACL) defined in the database (that was imported from the Mysecure template) and the actual DACL at the time the analysis was performed. Because the DACLs differ, the repair directory is highlighted as a mismatch.
Close these three windows.
Modifying Baseline Analysis Settings
After you review the analysis results, you may decide to update the baseline database that was used to perform the analysis. This may be desirable if you have changed your mind about the relevancy or the security specification that was originally defined for an object. For example:

If you consider an object to be security relevant, then you would check the Define this policy in the database checkbox when viewing the detailed analysis results. If this box is unchecked, the object is removed from the configuration and receives its inheritance from the parent object, as defined.
If you want to base future configurations or analyses on a different security specification, then you can click the Edit Security settings control to modify the security definition currently stored in the database.
In the example above, you already clicked the Edit Security control in step 6. If desired, you can modify the ACL currently defined for the repair directory in the database. Future analyses or configurations using this database would then be based on the newly defined ACL. Such modifications can be saved to a template by selecting Export Template from the context menu of the Security Configuration and Analysis node.

Configuring System Security
Thus far, you have created a customized security template (Mysecure.inf) and analyzed the current system settings against this template. If you are comfortable with the security changes indicated by this template (as noted by the mismatches flagged in the analysis), you can now configure the system with these new security settings.

To configure the system with the new settings:

Right-click the Security Configuration and Analysis node.
Select Configure System Now.
Specify the following as the path to the log file:
%windir%\security\\logs\Mysecure.log
where %windir% is the drive and path to your Windows directory (for example, C:\WINNT).
Click OK. A progress dialog displays to indicate the security areas being configured. When the configuration has completed your system is configured with the settings specified in Mysecure.Inf.
Click the Close button in the upper right corner of the Security Configuration and Analysis MMC snap-in.
Click Yes to save the console settings.
Specify SCA as the file name, and save the file.
This allows you to start the Security Configuration and Analysis snap-in without having to add it to a console in the future. Note that both the Security Templates snap-in and the Security Configuration and Analysis snap-in can be added to the same console if desired.

Viewing the Updated Local Security Policy
Changes made to local policy settings are automatically trapped by the Security Configuration Tool Set and stored in the local policy database. You can view these settings as you did in the first phase of this guide.

To view the policy

On the Start menu, click Run and then type Gpedit.msc and click OK.
Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then expand Account Policies.
Click Password Policy, as shown in Figure 12 below.

Note You must be an administrator to view local policy. If you are not logged on as an administrator user, then you may no longer have administrator permissions. This is because of the restricted Group Policy you just applied to the system.

Figure 12. Password Policy

You see that the local minimum password age (originally set to 1 during the Modifying Local Security Policy phase of this guide) is now set to 2 in accord with the Mysecure.inf specification.

Similarly, the message text has been updated:
In the left pane, expand Local Policies, and click Security Options, as shown in Figure 13 below.

Figure 13. Viewing security options

Viewing Updated File System Security Settings
Because file system settings are not local policies, you can verify the configuration of the repair directory through Windows Explorer.

To view file system security settings:

On the Start menu, point to Programs, then point to Accessories, and click Windows Explorer.
Unless it is already displayed, click the View menu, point to Explorer Bar, and select Folders.
Expand %windir% (where %windir% is the drive and path of your Windows directory; for example, C:\WINNT).
Click the Repair directory, right-click it, and select Properties.
Click the Security tab. Figure 14 below shows these two windows lined up:

Figure 14. Viewing file system security settings

Click the Close button in the upper right corner of the Group Policy window.
Now that the customized security settings specified in Mysecure.inf have been applied to the system, you can monitor any deviations from this security policy by periodically performing a system analysis against the database.

Command-line configuration and analysis
The configuration and analysis operations available from the Security Configuration and Analysis user interface can also be performed using the Secedit.exe command-line tool. Command-line operation allows security configuration and analysis to be performed in conjunction with other administrative tools, such as Microsoft Systems Management Server or the Task Scheduler built into Windows 2000. Secedit.exe also provides some capabilities that are not available in the graphical user interface.

Viewing Secedit.exe Help
The online Help provided with Secedit.exe describes the syntax for using the command.

To view the help text

On the Start menu, click Run and then type CMD. Click OK.
Type Secedit and press Enter to see online Help for this command.
The command provides five high-level operations:

Analyze
Configure
Export
RefreshPolicy
Validate
Analyze and Configure correspond to the same tasks available using the Security Configuration and Analysis snap-in.

Export dumps database configuration information into a template (.inf) file. This feature is also available in the snap-in through the Security Configuration and Analysis context menu after a database has been opened.

RefreshPolicy allows you to trigger a group policy propagation event which, by default, occurs whenever the machine boots, every 60-90 minutes thereafter, and when local security policy is modified using the Security Settings extension to Group Policy (as described in this guide). When a policy propagation event is triggered, pending policy changes are enforced by the corresponding Group Policy extensions (in this case, the Security Settings extension). To cause a refresh in policy regardless of whether there has been a change or not, you can use the /Enforce switch in conjunction with /RefreshPolicy.

Validate verifies the syntax of a template created using the Security Templates snap-in.

As described previously in this guide, all configurations and analyses are database driven. Therefore, Secedit.exe supports parameters for specifying a database (/db) as well as a configuration file (/cfg) to be imported into the database prior to performing the configuration. By default, the configuration file is appended to the database. To overwrite existing configuration information in the database, use the /overwrite switch. As with the snap-in, you can specify a log file (/log); however, Secedit.exe also allows detailed (/verbose) log information to be recorded. Also note that while the snap-in always configures all security areas, Secedit.exe allows you to specify areas (/areas) to be configured. Security areas not specified with the /areas switch are ignored even if the database contains security settings for those areas.

Configuring Security with Secedit.exe
The following example reapplies only the file system configuration specified by Mysecure.inf.

To configure file system security with Secedit.exe

Change to the %windir%\security\database directory (where %windir% is the drive and path to your Windows directory). For example, at the command prompt type:

cd\c:\windir\security\logs

Type the following:

secedit /configure /db mysecure.sdb /areas FILESTORE /log %windir%\security\logs\Mysecure.log /verbose

where %windir% with the drive and path to your Windows directory (for example, C:\WINNT)
Note: since the database already existed and contained configuration information previously imported from Mysecure.inf, you did not need to specify the /cfg parameter. Note also that paths for /db, /cfg, and /log–other than the current directory–must be absolute.

Type:

%windir%\security\logs\Mysecure.log

Notice that previous configurations configure all security areas, while the last configuration processed only the file security area.

Performing Security Analysis with Secedit.exe
Your system is currently configured according to the customized settings defined in Mysecure.inf. You will now violate this policy, and then perform a command-line analysis to locate the violation.

To violate the policy and then locate the violation:

Recall that Mysecure.inf specifies a restricted Group Policy for the Administrators group such that only the administrator user should belong to the Administrators group. Violate that policy by adding Everyone to the administrators group. Type the following at the Command prompt, and press Enter:

Net LocalGroup Administrators Everyone /Add

Perform the analysis using Mysecure.sdb as the baseline configuration. Type the following command at the Command prompt:

secedit /analyze /db Mysecure.sdb /Log Monitor.log /verbose

If you have access to the Grep tool, you can parse the log file to locate mismatches. Type the following at the Command prompt:

grep Mismatch Monitor.Log

Notice that the administrators group is flagged. Mismatches on registry values are occurring because these particular registry values are configured on the system, but not configured in the database. The snap-in tool does not flag these types of mismatches.

Pre-defined security templates
Windows 2000 Default Security Templates
Windows 2000 default security settings are applied only to Windows 2000—based systems that have been clean-installed on an NTFS partition. When computers are upgraded from Windows NT 4.0 or earlier, security is not modified. When Windows 2000 is installed on a FAT file system, security cannot be applied.

The following basic security templates are provided to secure upgraded NTFS computers in the same fashion as clean-installed NTFS computers:

Basicwk.inf for computers running Windows 2000 Professional.
Basicsv.inf for computers running Windows 2000 Server.
Basicdc.inf for domain controllers running Windows 2000 Server.
These security templates specify default Windows 2000 security settings for all security areas with the exception of User Rights and Groups.

Incremental Security Templates
Windows 2000 also ships with the following incremental security templates. These security templates were constructed based on the assumption that they would be applied to Windows 2000 computers that are configured with the new Windows 2000 default security settings. In other words, these templates incrementally modify the default security settings. They do not include the default security settings plus the modifications.

You should apply these incremental templates to Windows 2000 systems that have been clean-installed onto an NTFS partition. For NTFS computers that have been upgraded from Windows NT 4.0 or earlier, apply the corresponding basic template (as described above) before you apply any of the incremental security templates. Windows 2000 systems that are installed on FAT file systems cannot be secured.

Compatws.inf for workstations or servers. If you do not want your users to run as power users, the compatible configuration opens the default permissions for the Users group so that legacy applications are more likely to run correctly. Office 97 should run successfully when you are logged on as a User to a Windows 2000 machine that has had the compatible security template applied over the default settings. Note that this is not considered a secure environment.
Securews.inf for workstations or servers, and Securedc.inf for domain controllers provide a secure configuration. The secure configuration provides increased security for areas of the operating system not covered by permissions. This includes increased security settings for Account Policy, Auditing, and some well-known security relevant registry keys. Access control lists are not modified by the secure configurations because the secure configurations assume that default Windows 2000 security settings are in effect.
Hisecws.inf for workstations and servers, and Hisecdc.inf for domain controllers provide a highly secure configuration. The high security configuration is provided for Windows 2000 computers that operate in native Windows 2000 environments only. In this configuration, all network communications must be digitally signed and encrypted at a level that can only be provided by Windows 2000. Thus, communications between a Windows 2000 highly secure computer and a downlevel Windows client cannot be performed.
Security Levels
The following table describes the relative levels of security that can be associated with the operating system based on the templates that have been applied as well as the type of user accessing the system:

Templates Applied
User Level
Default Power User
Default + Compatible User
Default User
Default + Secure User
Default + Secure + High Secure User

Thus, logging on as a Power User on a system where Windows 2000 was clean-installed on an NTFS system is less secure than logging into that same system as a User.

Important Notes
The example company, organization, products, people, and events depicted in this step-by-step guide are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.

This common infrastructure is designed for use on a private network. The fictitious company name and DNS name used in the common infrastructure are not registered for use on the Internet. Please do not use this name on a public network or Internet.

The Active Directory® service structure for this common infrastructure is designed to show how Microsoft Windows 2000 Change and Configuration Management works and functions with the Active Directory. It was not designed as a model for configuring an Active Directory for any organization–for such information see the Active Directory documentation.