Step-by-Step Guide to Using

the Security Configuration Tool

Set

ON THIS PAGE
 Introduction
 Viewing and Modifying Local Security Policy
 Working with security templates
 Performing a Security analysis
 Configuring System Security
 Command-line configuration and analysis
 Pre-defined security templates

Introduction
This step-by-step guide describes how to view, configure, and analyze
local security policy and local security settings using various
components of the Security Configuration Tool Set included with the
Windows® 2000 operating system.

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:

1. 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.
2. To open the Group Policy console, click Start, click Run and type Gpedit.msc.
Click OK.
 3. Click the + next to Computer Configuration, then Windows Settings, then
Security Settings, and then Local Policies to expand these folders.
4. 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:

1. Click the + next to Account Policies in the left pane (under Security Settings) to
expand it.
2. Click Password Policy.
3. Double-click Minimum Password Age in the right pane.
4. 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.

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

6. 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:

1. 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).
2. Click Console (under Console1 in the upper right of the window), click Add\
Remove Snap-in, and click Add.
3. 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
4. Click Add, then click Close.
5. Click OK.
6. Click the + next to Security Templates in the left pane to expand it.
7. 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:

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

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

1. Click the Security Options node under Local Policies.

2. In the right pane, scroll down and then double-click Message Text for Users
Attempting to log on.
3. 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:

1. In the left pane, right-click Restricted Groups, and select Add Group.
2. 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.
3. 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.

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

Figure 4: Select Administrator

6. 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.
1. Right-click File System in the left pane, and click Add File.
2. 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

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

Figure 7: Template Security Policy Setting

8. 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:

1. Right-click Securews.inf, click Save As, and type Mysecurews and click Save.
2. Exit the Security Templates snap-in console by clicking the Close button in the
upper right corner.
3. Click Yes to save the console settings
4. 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:

1. On the Start menu, click Run and type: MMC /s

2. From the Console menu, select Add\Remove Snap-in, and click Add.
3. Select Security Configuration and Analysis.
4. 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

1. Click Security Configuration and Analysis in the left pane.

2. Right-click Security Configuration and Analysis in the left pane.
3. Click Open Database.
4. Type Mysecurews.sdb as the name of the database.
5. Click Open.
6. Select Mysecure.inf as the security template to import into the database.
7. 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

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

2. 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
3. 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

1. From the Security Configuration and Analysis node, click View.

2. Select the Description Bar to expose the database you are currently working
with.
3. 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:

1. Expand the File System node in the left pane.

2. Expand the %windir% directory (for example, C:\WINNT).
3. 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.
 4. Select Security. You can view the analyzed permissions, the database
permissions, or both.
5. Click View Security then click OK. (Note that you cannot modify the actual
system settings while viewing analysis results.)
6. 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.
7. 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:

1. Right-click the Security Configuration and Analysis node.

2. Select Configure System Now.
3. 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).
4. 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.
5. Click the Close button in the upper right corner of the Security Configuration and
Analysis MMC snap-in.
6. Click Yes to save the console settings.
7. 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

1. On the Start menu, click Run and then type Gpedit.msc and click OK.
2. Expand Computer Configuration, expand Windows Settings, expand
Security Settings, expand Local Policies, and then expand Account Policies.
3. 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:

4. 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:

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

Figure 14. Viewing file system security settings

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

1. On the Start menu, click Run and then type CMD. Click OK.
2. 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

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

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

3. 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:

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

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

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