Chapter 5 - Security Configuration

This section provides detailed documentation on the security settings that can be used to improve the security of Windows 2000. Tables are provided describing the security objective met by each setting and the configuration actions necessary to meet that objective. The settings are divided into categories corresponding to the categories presented in the SCE interfaces.

Section 0 of this document provides the procedures for automating most of the security settings defined in this section by applying pre-defined security configuration templates. For convenience, a Windows 2000 Security Configuration Checklist which can be used to track the settings made for a particular system is provided in Appendix C.

On This Page

Account Policies
Local Policies
Audit Log Management
Default Group Accounts
Default User Accounts
System Services
Securing the File System
Share Folder Permissions
Securing the Registry
IPSec Policy
Encrypting File System
Enable Automatic Screen Lock Protection
Update the System Emergency Repair Disk

Account Policies

Account policies are the rules that control three major account authentication features: password policy, account lockout, and Kerberos authentication.

• Password policy - determines settings for passwords such as enforcement, and lifetimes.

• Account lockout policy - determines when and for how long an account will be locked out of the system.

• Kerberos policy - Kerberos authentication is the authentication mechanism used by Windows 2000 and higher computers when they are members of an Active Directory domain. This policy allows administrators to configure Kerberos.

Account policies can be applied to user accounts in domains or OUs. For account policies in one domain in a forest to have any effect on another domain, even a sub-domain, there must be an explicit link to the group policy object. In addition, the following are important points to keep in mind with respect to account policies:

• Domain account policies applied through a Domain policy take effect only on the accounts defined on the domain controllers in that domain and any sub-domains. This also includes the following three settings:

  • Automatically log off users when logon time expires

  • Rename administrator account

  • Rename guest account

• Account policies defined on an OU take effect on the local accounts defined on the computers that are members of that OU.

Password Policy

View and edit current password policy settings as follows:

1. Open the applicable security policy, whether via a GPO, through the SCE, or through Local Security Policies

2. Expand Security Settings.

3. Within Security Settings, expand Account Policies to reveal the Password, Account Lockout, and Kerberos policies.

4. Click on the Password Policy object. The right-hand details pane will reveal the configurable Password Policy settings.

5. Set the Password Policy as recommended in Table 4.1.

Table 4.1 Password Policy Settings

Password Policies	Domain WKS	Domain Laptop	DC	Domain Server	Standalone WKS	Stand-alone Server
Set the Password History Requirements Security Objective: Set limit on how often passwords may be reused. Setting this to any value checks new passwords against that many prior passwords and rejects a password change if the new password matches any existing passwords. (Note, this is done without storing clear-text passwords). Procedure: Double click on the Enforce password history policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. For Domain-level policies, check the Define this policy setting box. Change the number in the passwords remembered field (maximum is 24) to reflect the number of passwords the system will remember. Recommendation: Set this to 24. Rationale: This setting enhances password security by ensuring that users cannot reuse passwords, whether accidentally or on purpose. This increases the chance that passwords stolen by an attacker will not be valid by the time they are cracked.
Set the Maximum Password Age Security Objective: Set the length of time users can keep their passwords before they have to change it. Procedure: Double click on the Maximum password age policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. For Domain-level policies, check the Define this policy setting box. Change the number in the days field to the desired number. Recommendation: 70 days. Rationale: this increases password security by ensuring that passwords are cycled periodically. The recommended setting prevents users from having to change their password so often that they cannot remember what it is.
Set the Minimum Password Age Security Objective: Set the length of time users must keep a password before they can change it. Procedure: Double click on the Minimum password age policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. For Domain-level policies, check the Define this policy setting box. Change the number in the days field to the desired number. Recommendation: 2 days. Rationale: This setting helps users remember new passwords by forcing them to use them for a period of time before they can reset them. It also prevents them from circumventing the password history by rapidly setting 25 new passwords.
Set the Minimum Password Length Security Objective: Set the minimum number characters required for user passwords. Procedure: Double click on the Minimum password length policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. For Domain-level policies, check the Define this policy setting box. Change the number in the characters field to the desired value. Recommendation: 8 characters. Note: Each additional character in a password increases the complexity of the password exponentially. By requiring at least 8 characters even the weaker LMHash is much stronger, requiring crackers to crack both 7-character portions of the LMHash, as opposed to only one half. If a password is 7 characters or less, the second half of the LMHash has a specific value which allows a cracker to tell that the password is shorter than 8 characters. A significant amount of time has been spent arguing that 8 character passwords are less secure than 7 character passwords due to the way the LMHash is stored. In an 8 character password, the cracker would simply test the second half of the password while testing the first half. However, what this argument fails to take into account is that this still increases the number of checks a cracker has to perform by an additional 1/7th, significantly extending the time it takes to crack the password. Longer passwords are always better, and if LMHashes are not stored, 8 character passwords are orders of magnitude more secure than 7 character passwords. Recommending shorter passwords over longer ones is misguided.
Set the Password Complexity Requirements Security Objective: Requires the use of complex (strong) password. This policy will impose a requirement for at least three of the following four character sets: (1) upper case letters, (2) lower case letters, (3) numbers, and (4) non-alpha numeric characters. For more information on requiring and verifying additional complexity in passwords, please see section 0. Recommendation: Enable password complexity. Rationale: Password complexity is paramount to prevent password guessing and password cracking.
Enable Reversible Encryption for Passwords Security Objective: This setting is designed to decrease security for environments needing particular types of backward compatibility. Certain scenarios require knowledge of the user's clear-text password. In those scenarios enabling this setting allows the clear-text password to be obtained. Recommendation: Do not enable this setting. Verify the default setting of "Disabled" is still enforced.

Account Lockout Policy

Account lockout is used to prevent password guessing against accounts. Account lockout would lock out the account after a certain number of bad passwords have been entered. The lockout can last for a duration of time or be indefinite, until the administrator unlocks the account. The built-in Administrator account cannot be locked out from local logons, only from network logons. Furthermore, it can only be locked out from network logons by using the passprop.exe tool in the Windows 2000 Server Resource Kit.

We recommend not using account lockout policy for several reasons. First, if password policies are configured as per above, account lockouts are superfluous as no attacker will be able to guess the password in a reasonable period of time. Using only upper- and lower-case letters and numbers, and assuming that users do not use dictionary words with only a number appended, it will take 3,461,760 years to guess the password if each guess takes half a second. Since passwords are changed frequently, the likelihood that an attacker can guess the password is very slim. In fact, if passwords are changed every 70 days, the attacker would need the equivalent of 52,000 T3 lines coming in to the victim system in order to guess just one random password prior to its expiration (assuming, of course, that the password does not appear in a dictionary). In other words, if passwords are so weak that an attacker manages to guess the password in a single-digit number of tries, the problem is not the lack of account lockout policies, but rather extremely poor passwords.

Further, enabling account lockout policies will greatly increase the helpdesk burden due to users accidentally locking out their account by forgetting to turn off the caps-lock key or similar issues. This is particularly true when users are required to use complicated passwords, which otherwise is a good practice.

Even worse than the increased helpdesk call volume directly generated by account lockout would be the effect on the network if an attacker should lock out service accounts. In this case, the services would fail to start. If a service fails to start once because of an account lockout, it will not retry starting the service, and an administrator would have to manually go to the system and start the service; after the account lockout period has expired.

We highly recommend using a vulnerability scanner in all environments. However, a vulnerability scanner typically tests a small number of commonly used passwords, and if account lockout policy is used, the scanner will lock out all accounts each time it scans the network. This could have an unintended adverse impact on system availability.

In addition, account lockout by default does not operate against the one account that an attacker is most likely to attack; the Administrator account. Although it is possible to obtain a list of the other administrative accounts on a system, most attackers will attempt to guess passwords on the obvious accounts, such as the default Administrator account. In order to enable lockout of the Administrator account you must use the passprop.exe utility in the Resource kit.

Lastly, since a firewall should be used to block Windows networking from untrusted networks, password guessing would only be possible from trusted networks. In a trusted network, the culprit of a password guessing attack should be relatively easy to locate and deal with by tracing the logon attempts.

This all being said, there is one potential use of account lockout, and it is to alert administrators that a password guessing attack is under way. However, an intrusion detection system should be used to detect this. We do not endorse using account lockout policy as a replacement for a real intrusion detection system. However, in environments where account lockout is desired for its alerting effect, we recommend setting the threshold to 50 and the timers to 30 minutes, respectively.

Access the Kerberos Policy Settings

The default settings for Kerberos Policies are adequate. Do not change these defaults.

Local Policies

Local Policies govern security settings that apply to individual computers or users. The Local Policies section can be used to configure:

• Audit policy. Determines which security events are logged into the security event log on the computer (i.e., successful attempts, failed attempts or both). The security log is managed through the Event Viewer MMC snap-in.

• User rights assignment. User rights govern the types of actions individual users or groups can perform. These used to be called privileges in prior versions of Windows NT.

• Security options. Used to manage various registry based security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD ROM access, driver installation, and logon prompts. Several of the settings discussed in this section are not visible by default in the tools described in this section. In order to view and manage these settings in the user interface, an administrator must first apply a custom template to modify the settings which appear in the interface. Instructions for how to apply the custom templates included with this guide are available in section 0.

Audit Policy

To enable auditing of security related events:

1. Open the applicable Security Policy.

2. Expand Security Settings.

3. Within Security Settings, expand Local Policies to reveal the Audit, User Rights Assignment, and Security Options policies.

4. Click on the Audit Policy object. The right-hand details pane will reveal the configurable Audit Policy settings

   

5. To set auditing of a security event, double click on the desired audit policy in the right-hand details pane. This will open the Security Policy Setting dialog window.

Table 4.4 Audit Policy Settings

Audit Policies			Domain WKS	Domain Laptop	DC	Domain Server	Standalone WKS	Stand-alone Server
Audit Event Categories	Success	Failure
Audit Account Logon Events This audits logon events where this computer is used to authenticate the user. In other words, on a DC, this will audit all domain logon events, whereas on a domain member, it will only audit those events where a local account was used.
Audit Account Management This audits any event that involves account management, such as account creation, account lockout, account deletion, etc.
Audit Directory Service Access This enables auditing of access to Active Directory objects. By itself, this setting does not actually cause any events to be generated. Only when a SACL is defined on an object are any accesses audited. Therefore, we recommend enabling both success and failure auditing, in order to allow any SACL to be effective.
Audit Logon Events This audits logon events occurring on the system this policy is applied to, regardless of where the accounts reside. In other words, on a domain member, enabling success auditing for this would generate an event each time someone logged on to the system. If the account used to logon was local and the Audit Account Logon Events setting was also enabled, the logon would generate two events.
Audit Object Access This enables auditing of access to all auditable objects such as file system and registry objects (with the exception of Directory Service objects). This setting, by itself, will not cause any events to be audited. It will only enable auditing so that objects on which a SACL are defined can be audited. Therefore, we recommend enabling both success and failure auditing for this setting.
Audit Policy Change This setting defines whether to audit changes to user rights assignment policies, audit policies, or trust policies. We only recommend success auditing for this since failure auditing of this type of access is not really meaningful.
Audit Privilege Use This setting determines whether we generate an audit event every time someone uses a privilege. Certain privileges, such as Bypass traverse checking and Debug programs are not audited in spite of this setting (such auditing can be turned on by setting the FullPrivilegeAuditing registry value). In spite of this, enabling privilege auditing generates a very large number of events, and for that reason, we do not recommend turning it on.
Audit Process Tracking This setting enables auditing of certain process events, such as program entry and exit, handle duplication, indirect object access, and so on. Enabling this auditing will generate a very large number of events which will fill the event logs in a short period of time. For this reason, we do not recommend enabling this on a wide scale except for debugging purposes. It may also be useful to use process tracking to analyze an attack. For example, buffer overflow exploits are often used to launch command shells, which will be logged of process tracking is turned on. However, a strict log management discipline must be used if process tracking is turned on.
Audit System Events Audits events such as system shutdown, start, or events affecting the system and/or security logs, such as clearing the logs.

Logon Rights and Privileges

Logon rights and privileges govern rights that users have on the target system. They are used to grant the right to perform certain actions, such as logging on from the network or locally, as well as administrative tasks, such as generating new logon tokens. In order to modify User Rights:

1. Open the applicable Security Policy.

2. Expand Security Settings.

3. Within Security Settings, expand Local Policies to reveal the Audit, User Rights Assignment, and Security Options policies.

4. Click on the User Rights Assignment object. The right-hand details pane will reveal the configurable user rights policy settings.

   

Note: Not all groups exist on all types of systems. Therefore, this policy may need to be modified on a system where the target group exists. Alternatively, the policy templates can be hand edited to include the appropriate groups.

Table 4.5 lists the User Rights and Privilege Assignments that should be modified from their defaults. Many other rights will show up in the policy editor interfaces, however, their default settings are adequate and need not be modified. The check marks in this table indicate that this modification should be applied to the particular type of system in that column.

Table 4.5 User Rights and Privileges

User Rights and Privilege Assignment			Domain WKS	Domain Laptop	DC	Domain Server	Standalone WKS	Stand-alone Server
Privilege	Default	Modified
Access this computer from the network (Professional/Server)	Administrators Backup Operators Power Users Users Everyone	Administrators Backup Operators Power Users Users Authenticated Users
Access this computer from the network (Domain Controller)	Administrators Authenticated Users Everyone	Administrators Authenticated Users
Log on Locally (Professional)	Administrators Backup Operators Power Users Users Machinename\Guest	Administrators Backup Operators Power Users Users
Log on Locally (Server)	Administrators Backup Operators Power Users Users Machinename\Guest Machinename\TsInternetUser	Administrators Backup Operators Power Users NOTE: You will need to grant this privilege to Users on a Terminal Server Application Server
Log on Locally (Domain Controller)	Administrators Account Operators Backup Operators Print Operators Server Operators TsInternetUser	Administrators Account Operators Backup Operators Print Operators Server Operators
Add Workstations to the Domain (Domain Controller)	Authenticated Users	Authenticated Users
Increase Quotas (Domain Controller – in the Domain Security Policy)	(Not Defined)	Administrators
Increase Scheduling Priority (Domain Controller – in the Domain Security Policy)	(Not Defined)	Administrators
Load and Unload Device Drivers (Domain Controller – in the Domain Security Policy)	(Not Defined)	Administrators
Manage Auditing and Security Log (Domain Controller – in the Domain Security Policy)	(Not Defined)	Administrators
Modify Firmware Environment (Domain Controller – in the Domain Security Policy)	(Not Defined)	Administrators
Profile System Performance (Domain Controller – in the Domain Security Policy)	(Not Defined)	Administrators
Shut Down the System (Clients)	Administrators Backup Operators Power Users Users	Administrators Backup Operators Power Users Authenticated Users
Shut Down the System (Servers)	Administrators Power Users (other groups vary depending on system type)	Administrators
Take Ownership of Files and Objects (Domain Controller – in the Domain Security Policy)	(Not Defined)	Administrators

Modify Security Options

Modify predefined security related Registry settings:

1. Open the applicable Security Policy.

2. Expand Security Settings.

3. Within Security Settings, expand Local Policies to reveal the Audit, User Rights Assignment, and Security Options policies.

4. Click on the Security Options object. The right-hand details pane will reveal the configurable security options.

   

5. To set a Security Option, double click on the desired policy in the right-hand details pane. This will open the Security Policy Setting dialog window.

6. For Domain-level policies, check the Define these policy settings box.

7. Input to the Security Policy Setting dialog boxes for selected security options will vary depending on the configuration requirements of the option. For example some security options may require selection from a drop down menu or a text input as shown below.

   

   

8. Modify the Security Options as shown in Table 4.6.

Table 4.6 Security Option Settings

Security Options	Domain WKS	Domain Laptop	DC	Domain Server	Standalone WKS	Stand-alone Server
Set Additional Restrictions for Anonymous Connections Security Objective: Disable ability of anonymous users to enumerate SAM accounts and shares. Recommendations: Domain and stand-alone servers - set this to "Do not allow enumeration of SAM accounts and shares." This setting is equivalent to RestrictAnonymous set to 1 and frequently, the setting is referred to this way. Laptops and workstations - set this to "No access without explicit anonymous permissions" (RestrictAnonymous = 2). Note: The "No access without explicit anonymous permissions" option has the potential to cause connectivity problems in many environments. Hence, we do not recommend this setting for systems that need to accept inbound connections generally. However, because of its great security value, we encourage testing it thoroughly to evaluate whether it can be used in your particular environment. Currently, several major incompatibilities with this setting are known: When set to "No access without explicit anonymous permissions" on Exchange 2000 servers, clients will be unable to look up addresses in the Global Address Book. This issue was fixed in Windows 2000 Service Pack 3. When set to "Do not allow enumeration of SAM accounts and shares" on a Windows 2000 domain controller, users on Windows XP, NT, and Macintosh clients will be unable to change their domain password at logon. A fix for Windows XP can be obtained from PSS by asking for hotfix 328817. No fix is available for Windows NT and Macintosh clients. Down-level clients (Windows 9x and earlier) will be unable to authenticate to the domain if this is set. Users on trusting NT 4 domains will be unable to list users from the trusted Windows 2000 domain. The Browser Service does not function reliably. Inter-forest communication will not function correctly. For more information, please see Microsoft Knowledge Base 246261 Note: On a bastion host system, we recommend seriously considering configuring this to "No access without explicit anonymous permissions"
Allow Shutdown without Logon Security Objective: Users should not be able to shut down the system without first having logged on. This is particularly important on terminal servers. Recommendation: Set this policy to Disabled on the systems in the matrix This setting does not actually provide much security on systems without terminal services enabled. An attacker would need physical access to a non-terminal services system to shut it down, in which case he could simply unplug the system.
Audit the Access of Global System Objects Security Objective: Enable the capability to audit access of global system objects. When this policy is enabled, it causes system objects such as mutexes, events, semaphores, and DOS Devices to be created with a default system access control list (SACL). If the Audit object access audit policy is also enabled, then access to these system objects will be audited. Recommendation: Leave this policy disabled except on particularly sensitive systems. On those, set this policy to Enabled. Note: This setting was designed primarily for developers troubleshooting new programs. It will generate a large amount of audit information. Therefore, it should only be enabled where there is a strict audit management process in place for reviewing, archiving, and clearing the audit logs on a regular basis and where the events generated by this setting are actually useful to the forensics process. The maximum log size should also be edited to support an increase in the number of events being logged.
Audit the Use of Backup and Restore Privilege Security Objective: Enable the capability to create audit event entries whenever the Backup files and directories or the Restore files and directories privileges are used. By default, the use of backup and restore privileges are not audited. When the Audit privilege use audit policy is enabled and this security option is set, the use of the Backup and Restore privileges will be audited. Recommendation: This setting generates an extremely large number of events and should only be enabled when troubleshooting backup problems.
Automatically Log Off Users When Logon Time Expires Security Objective: Force a user to log off of the network when that user remains logged on beyond the allowed hour range. Recommendation: In environments where logon time restrictions are enforced, this setting should be enabled. In other environments, this setting has no effect. Note: Keeping users to particular logon times is not a security measure in and of itself. In other words, it does nothing to protect the systems those users touch from the users themselves.
Clear Virtual Memory Page File When System Shuts Down Security Objective: Removes the virtual memory pagefile when the system is shut down. The pagefile is reinitialized the next time a user logs in. The purpose is to ensure that any information that may remain within the page file is not available to the next user that logs on to the machine. Recommendation: Enable this on notebook computers and other machines which may not be physically secured while shut down. Note: Configuring this setting will significantly increase the time it takes to shut down a system.
Digitally sign client communications (always) Security Objective: Determines whether the computer will always digitally sign client communications. The Windows 2000 Server Message Block (SMB) authentication protocol supports mutual authentication, which closes a "man-in-the-middle" attack, and supports message authentication, which prevents active message attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by both the client and the server. This setting is disabled by default. Enabling this option requires the Windows 2000 SMB client subsystem to perform SMB packet signing. In this case, the computer will be unable to communicate with servers which do not support digital signing. Unless this is a preferred result, this option should not be set. Rather, ensure that the "when possible" option is set on all systems that support signing (Windows 2000 and higher) to ensure that signing is used whenever it is possible. Recommendation: Do not enable this setting.
Digitally sign client communications (when possible) Security Objective: If this policy is enabled, it causes the Windows 2000 Server Message Block (SMB) client subsystem to perform SMB packet signing when communicating with an SMB server that is enabled or required to perform SMB packet signing. See "Digitally sign client communications (always)" for additional details. Recommendation: Leave this setting enabled, which is the default.
Digitally sign server communications (always) Security Objective: If this policy is enabled, it requires this system to perform Server Message Block (SMB) packet signing when the system is acting as an SMB server. This policy is disabled by default since otherwise it prevents this machine from communicating with client systems which do not perform signing. See "Digitally sign client communications (always)" for additional details. Recommendation: On systems which should not act as SMB servers to down-level systems, this setting should be enabled. Client workstations in a domain should rarely serve in this capacity. Therefore, we recommend that client workstations have this setting enabled. On domain controllers, enabling this setting would prevent certain types of attacks, such as the one discussed in Microsoft Security Bulletin MS02-070. However, this has to be weighed against the fact that down-level clients would be unable to communicate with the domain controller. For that reason, we leave the setting off in the DC configuration templates. In an environment with only Windows 2000 or newer clients, this setting should be enabled on the domain controllers.
Digitally sign server communications (when possible) Security Objective: If this policy is enabled, it enables this system to perform Server Message Block (SMB) packet signing when the system is acting as an SMB server. This policy is disabled by default on workstation and server platforms in Local Computer Policy. This policy is enabled by default on Domain Controllers.. See "Digitally sign client communications (always)" for additional details. Recommendation: This setting should be enabled on all systems. Note: This setting imposes a communications overhead which could be significant in some cases. Therefore, you should evaluate this setting in your environment to ensure that it will not degrade network response time beyond acceptable levels.
Disable CTRL+ALT+ DEL Required for Logon Security Objective: Enabling this option will disable the trusted path mechanism. The purpose of the trusted path mechanism is to prevent spoofing of user login sessions. It is the mechanism which causes the operating system to always intercept CTRL+ALT+DEL key-sequences and prevents other sub-systems and processes from capturing that key-sequence. If this mechanism is disabled, it would be simply for an attacker to spoof the logon interface with a keystroke logger. Therefore, this setting should never be enabled. The default setting of this option is Disabled on a Windows 2000 computer, although a policy tool may show it as Not Defined. Recommendation: Set this policy to disabled. Note: The default is "leave as is" but disabling the setting ensures that it is overridden on machines where it has been changed.
Do Not Display Last User Name on Logon Screen Security Objective: By default, the Windows 2000 login interface displays the user name of the last user that logged onto the computer. Enabling this option removes the name of the last user from the login session. As a result, an intruder attempting to break into the computer locally would not only need to guess the password, but would also need to guess a correct user name. However, obtaining a list of user names is not particularly difficult and passwords are the proper defense mechanism. Further, enabling this setting has been shown to increase technical support costs since users may forget their username. Recommendation: We recommend enabling this setting only on machines that are set up for shared use, such as lab workstations or terminal servers. On other machines, this setting provides little value to offset the increased support cost.
LAN Manager Authentication Level Security Objective: This Security Option is used to enforce a particular type of authentication protocols used for Windows networking, as well as enable a new type of authentication protocol (NTLMv2). NTLMv2 is a new type of authentication protocol which significantly enhances the security of Windows authentication. It prevents many spoofing attacks, and allows the server to authenticate itself to the client. The nature of the NTLM protocol allows password crackers to use a captured NTLM authentication session to crack passwords. To counteract this, NTLM version 2 was developed. NTLMv2 introduces additional security features, including Unique session keys per connection. Each time a new connection is established, a unique session key is generated for that session. This way a captured session key will serve no useful purpose after the connection is completed. Session keys protected with a key exchange. The session key can't be intercepted and used unless the key pair used to protect the session key is obtained. Unique keys generated for the encryption and integrity of session data. The key that's used for the encryption of data from the client to the server will be different from the one that's used for the encryption of data from the server to the client. Stronger encryption. NTLMv2 uses a stronger encryption protocol for the session keys as well as a stronger hashing algorithm for the message integrity and authentication sequences. For more information on NTLMv2, see Knowledge Base article 147706. NTLMv2 has been available since Windows NT 4.0 Service Pack 4, and is available for Windows 9x in the Directory Services Client which ships on the Clients\Win9x directory on the Windows 2000 CD-ROM. This setting is often referred to in the literature as "LMCompatibilityLevel" which is the name of the actual registry switch used to enable it. The setting affects both the authentication protocol and the session security protocol used after authentication. All Windows NT-based systems since Windows NT 4.0 SP4 (including Windows 2000, Windows XP, and Windows Server 2003) will accept SMB client connections using NTLMv2 authentication without further modification. The LMCompatibilityLevel setting is used to modify several aspects of authentication: Modify the authentication protocols the systems will send when they act as clients Modify the authentication protocols they accept when acting as servers. The value of the setting on the machine that holds the account database governs this behavior. In other words, when domain accounts are used, the value of the setting on the domain controller takes effect. When using local accounts, the value of the setting on the server is the effective one. Enable NTLMv2 session security. There are 6 possible settings which govern this behavior. The numbers in parentheses are the actual settings of the LMCompatibilityLevel registry value. The client behavior column shows how a machine with this setting behaves as an SMB client. The server behavior column shows how the server performing the authentication behaves if this setting is made on that server. The authentication server is always the DC when domain accounts are used and the DC is reachable. If the DC is not reachable, or local accounts are used, the authentication server is the server that the client is connecting to. Recommendation Set this as high as your environment allows, as per the following guidelines: In a pure Windows NT 4.0 SP4 and higher environment (including Windows 2000 and XP) set this to 5 on all clients, and then to 5 on all servers once all clients are configured. The exception is Windows 2000 RRAS servers which will not function properly if this setting is set higher than 4. If you have Windows 9x clients, and you can install the DSClient on all such clients, set this to 5 on Windows NT-based machines (NT, 2000 and XP) and to 3 on Windows 9x machines. Otherwise, you must leave this setting at no higher than 3 on non-Windows 9x machines. If you find applications that break when this setting is enabled, roll it back one step at a time to discover what breaks. At a minimum, this setting should be set to 1 on all machines, and can typically be set to 3 on all machines. If you have a priority support contract, please contact PSS and let them know what applications break and at what level. Note: Setting LMCompatibility higher than 2 in a mixed Windows NT 4.0 and Windows 2000 domain environment can cause interoperability problems. For more information, see Microsoft Knowledge Base article 305379. The W2KHG-baseline.inf template sets LMCompatibilityLevel to "Send NTLMv2 response only (3)."
Implement an Authorized Usage Warning Security Objective: Configure the interactive logon screen to display a logon banner with a title and warning. This banner is primarily used to comply with, and notify users of, authorized usage policy. Please contact legal counsel to determine whether there are legal reasons to use it or that require it. Recommendation: Set this banner in accordance with your information security policy.
Disable Caching of Logon Information Security Objective: Windows 2000 has the capability to cache logon information. If the Domain Controller cannot be found during logon and the user has logged on to the system in the past, it can use those credentials to log on. This is extremely useful, for example, on portable computers, which need to be used when the user is away from the network. The CachedLogonsCount Registry valued determines how many user account entries Windows 2000 saves in the logon cache on the local computer. The logon cache is a secured area of the computer and the credentials are protected using the strongest form of encryption available on the system. If the value of this entry is 0, Windows 2000 does not save any user account data in the logon cache. In that case, if the user's Domain Controller is not available and a user tries to log on to a computer that does not have the user's account information, Windows 2000 displays the following message: The system cannot log you on now because the domain <Domain-name> is not available. If the Administrator disables a user's domain account, the user could still use the cache to log on by disconnecting the net cable. To prevent this, Administrators may disable the caching of logon information. The default setting allows caching of 10 sets of credentials. Recommendation: Set this to at least 2 to ensure that the system is usable while the domain controllers are down or unavailable.
Prevent System Maintenance of Computer Account Passwords Security Objective: Computers in a Windows 2000 domain need to authenticate themselves to the domain controller before they can use domain resources. This setting determines whether the computer account password should be prevented from being reset every week. As a part of Windows 2000 security, computer account passwords are changed automatically every seven days. If this policy is enabled, the machine is prevented from requesting a weekly password change. If this policy is disabled, a new password for the computer account will be generated every week. This policy is disabled by default. Recommendation: Set this policy to disabled to ensure that it is configured properly on machines where it was overridden at some point. There is virtually no reason to ever enable this policy.
Prevent Users from Installing Print Drivers Security Objective: Determines whether members of the Users group are prevented from installing print drivers. If this policy is enabled, it prevents users from installing printer drivers on the local machine. This prevents users from "Adding Printers" when the device driver does not exist on the local machine. If this policy is disabled, then a member of the Users group can install printer drivers on the computer. By default, this setting is enabled on servers and disabled on workstations to reduce the support overhead associated with forcing administrators to install printer drivers. While enabling this setting would marginally increase the security of workstations, it will significantly increase administrative overhead. This needs to be balanced against the third immutable law of security: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." Recommendation: Leave this setting unchanged.
Prompt User to Change Password before Expiration Security Objective: Determines how far in advance Windows 2000 should warn users that their password is about to expire. By giving the user advanced warning, the user has time to construct a sufficiently strong password. By default, this value is set to 14 days. Recommendation: None. The default setting is adequate.
Recovery Console: Allow Automatic Administrative Logon Security Objective: By default, the Recovery Console requires that a password be provided for the Administrator account before accessing the system. If this option is enabled, the Recovery Console does not require a password and will automatically log on to the system. By default, this setting is disabled, although a policy tool may show it as Not Defined. Recommendation: Set this option to disabled.
Recovery Console: Allow Floppy Copy and Access to All Drives and Folders Security Objective: Enabling this option enables the Recovery Console SET command, which allows the following Recovery Console environment variables to be set: AllowWildCards - Enable wildcard support for some commands (such as the DEL command). AllowAllPaths - Allow access to all files and folders on the computer. AllowRemovableMedia - Allow files to be copied to removable media, such as a floppy disk. NoCopyPrompt - Do not prompt when overwriting an existing file. By default, the SET command is disabled and all these variables are not enabled, although a policy tool may show it as Not Defined. Recommendation: Enable this option to enhance the ability to recover the system through the recovery console.
Rename Administrator Account Security Objective: Used to change the name that is associated with the security identifier (SID) for the account "Administrator." This provides virtually no security value since it is trivial to determine the name of the Administrator account unless anonymous access is disabled. If "Set Additional Restrictions for Anonymous Connections" is set to "Do not allow enumeration of SAM accounts and shares", this setting does, however, buy you a marginal measure of security. However, a username is not a password and a strong password should be used to protect the Administrator account instead of a non-standard name. Furthermore, some programs will fail if you rename the Administrator account. Recommendation: Do not bother renaming the Administrator account for its security benefits unless you are also able to use restrict anonymous enumeration of SAM accounts.
Rename Guest Account Security Objective: Used to change the name that is associated with the security identifier (SID) for the account "Guest." This setting provides no security value. Recommendation: Do not bother renaming the Guest account for its security benefits. Just make sure it is disabled.
Restrict CD-ROM Access to Locally Logged-On User Only Security Objective: Determines whether a CD-ROM is accessible to both local and remote users simultaneously. If enabled, this policy allows only the interactively logged-on user to access removable CD-ROM media. If this policy is disabled the CD-ROM may be shared over the network if no one is logged on interactively. Recommendation: This setting provides very little security, particularly since it only takes effect when a user is logged on. Do not enable this setting
Restrict Floppy Access to Locally Logged-On User Only Security Objective: Determines whether a floppy disk is accessible to both local and remote users simultaneously. If enabled, this policy allows only the interactively logged-on user to access removable floppy media. If this policy is disabled the floppy may be shared over the network if no one is logged on interactively. Recommendation: This setting provides very little security, particularly since it only takes effect when a user is logged on. Do not enable this setting
Secure Channel: Digitally Encrypt or Sign Secure Channel Data (Always) Security Objective: Determines whether the computer will always digitally encrypt or sign secure channel data. The secure channel is used to communicate between domain controllers and domain members. When a Windows 2000 system joins a domain, a computer account is created. Thereafter, when the system boots, it uses the password for that account to create a secure channel with the domain controller for its domain. Examples of traffic flowing over the secure channel include logon traffic. Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the channel is not integrity checked and not all information is encrypted. If this policy is enabled, all outgoing secure channel traffic must be either signed or encrypted. If this policy is disabled, signing and encryption are negotiated with the domain controller. By default, this policy is disabled. Recommendation: This policy should not be enabled unless it is desirable to prevent the system from communicating with down-level domains.
Secure Channel: Digitally Encrypt Secure Channel Data (When Possible) Security Objective: Determines whether the computer will negotiate encryption of the secure channel with a domain controller. By default, all sensitive information is already encrypted. If this policy is enabled, the system will encrypt all traffic over the secure channel when communicating with domain controllers that support it. By default, this option is enabled. Recommendation: Do not change the default setting.
Secure Channel: Digitally Sign Secure Channel Data (When Possible) Security Objective: Determines whether the computer will negotiate integrity signing of secure channel data. Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the channel is not integrity checked and not all information is encrypted. If this policy is enabled secure channel traffic will be digitally signed when communicating with domain controllers that support signing. By default, this option is enabled. Recommendation: Do not change the default setting.
Secure Channel: Require Strong (Windows 2000 or Later) Session Key Security Objective: If this policy is enabled, all outgoing secure channel traffic will require a strong (Windows 2000 or later) encryption key. If this policy is disabled, the key strength is negotiated with the DC. This option should only be enabled if all of the DCs in all trusted domains support strong keys. By default, this value is disabled. Procedure: If all legitimate DCs are running Windows 2000 or higher, enable this policy. Otherwise, leave it disabled.
Send Unencrypted Password to Connect to Third-Party SMB Servers Security Objective: If this policy is enabled, the Server Message Block (SMB) redirector is allowed to send clear-text passwords to non-Microsoft SMB servers that do not support password encryption during authentication. By default, this option is disabled. Recommendation: Set this to disabled to ensure that it overrides changes made to individual machines
Shut Down the System Immediately if Unable to Log Security Audits Security Objective: Determines whether the system should shut down if it is unable to log security events. If this policy is enabled, it causes the system to halt if a security audit cannot be logged for any reason. Typically, an event will fail to be logged when the security audit log is full and the retention method specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days. If the security log is full and an existing entry cannot be overwritten and this security option is enabled, the following blue screen error will occur: STOP: C0000244 {Audit Failed} An attempt to generate a security audit failed. To recover, an administrator must log on, archive the log (if desired), clear the log, and reset this option as desired. By default, this policy is disabled. If this policy is enabled, an attacker can easily create a denial of service condition by simply generating a large number of event log entries. Recommendation: Do not enable this policy. Proper log management strategies will prevent event loss without enabling attackers to create a denial of service condition.
Smart Card Removal Behavior Security Objective: Determines what should happen when the smart card for a logged-on user is removed from the smart card reader. The options are: No Action Lock Workstation Force Logoff By default, No Action is specified. If Lock Workstation is specified, then the workstation is locked when the smart card is removed allowing users to leave the area, take their smart card with them, and still maintain a protected session. If Force Logoff is specified, then the user is automatically logged off when the smart card is removed. Recommendation: Configure smart card removal to lock the workstation Note: Smart card logon is only supported in a domain environment. Therefore, this setting has no effect on stand-alone systems
Strengthen Default Permissions of Global System Objects (e.g. Symbolic Links) Security Objective: Determines the strength of the default discretionary access control list (DACL) for system objects. Windows 2000 maintains a global list of shared system resources such as DOS device names, mutexes, and semaphores. Objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. If this policy is enabled, the default DACL is stronger, allowing non-admin users to read shared objects, but not modify shared objects that they did not create. By default, this option is enabled locally on Windows 2000 Professional and Server, but is not defined in the Domain Security Policy. Recommendation: Ensure that this setting is configured to enabled.
Unsigned Driver Installation Behavior Security Objective: Determines what should happen when an attempt is made to install a device driver (by means of the Windows 2000 device installer) that has not been signed by the publisher of the driver. The options are: Silently succeed Warn but allow installation Do not allow installation The default setting is to Warn but allow installation. Recommendation: The default setting is adequate.
Unsigned Non-Driver Installation Behavior Security Objective: Determines what should happen when an attempt is made to install any non-device driver software that has not been signed. The options are: Silently succeed Warn but allow installation Do not allow installation The default setting is to Silently succeed. Recommendation: Very little software is digitally signed today. Therefore, this setting has no real effect. Leaving it at the default is fine.

Additional Security Settings

The additional security settings described in this subsection are not available in the default security policy GUIs. These settings can be configured using the Registry Editor or by installing the customized sceregvl.inf template shipped with this guide. The custom sceregvl.inf template will add these settings to the default security policy GUI.

Information on how to edit the Registry is also available through the Help tool in the registry editor itself. For example, for instructions on adding a key to the Registry:

1. Click the Start button and select Run...

2. Within the Run dialog window's text box, type regedt32 and click the OK button to open the Registry Editor (Regedt32.exe).

3. From the editor's Help menu, select Contents.

4. In the right-hand pane of the Registry Editors Help tool, click on the "Add and delete information in the registry" hyperlink.

5. The pane will change to provide a list of help topics for adding and deleting information in the Registry. Click on the "Add a key to the registry" hyperlink to obtain the detailed instructions.

Note: It is highly recommended to use regedt32.exe (a.k.a. the Windows NT registry editor) and not regedit.exe (a.k.a. the Windows 95 registry editor) to modify registry settings. Both editors ship with Windows 2000 and regedit.exe is generally perceived as easier to use. However, regedit.exe does not support all the registry data types and will convert certain types it does not understand. Certain values will not be read properly if they are converted and this can cause serious problems with the system, including failure to boot. Editing the registry manually is at your own risk. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, see article 256986 in the Microsoft Knowledge Base:

Other Registry Settings

The Registry settings described in this subsection can be used to further enhance the security posture of the operating system. With the exception of the settings in the "Service Pack 3 Registry entries" section these settings are available in all versions of Windows 2000.

Remove OS/2 and POSIX subsystems

The OS/2 and POSIX subsystems are included for compatibility with POSIX and OS/2 applications. It is rare that these types of applications need to be run on Windows 2000, and in most cases, these sub-systems can safely be removed. However, be sure to make a backup of this registry key before removing it manually (or use the template, which allows you to revert the setting). To remove OS/2 and POSIX support from Windows 2000, edit the Registry and delete the value as shown in the table below.

Key Path: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager	Type	Value
Key: SubSystems Value Name: Optional	REG_MULTI_SZ	Delete all entries

Note: It is extremely important to use regedt32.exe to make this change if you make it manually. Regedit.exe does not handle REG_MULTI_SZ values. Deleting all entries from the Optional value using regedit.exe will cause the system to fail to boot. For more information, please see the note on the previous page. If you make this change using group policy, the change is made properly.

Note: Dell Computer previously shipped certain update files with an extractor that was written for OS/2. These update files will no longer work if the OS/2 subsystem is removed.

Note: Microsoft's Services for Unix product requires the Posix sub-system. Do not remove that sub-system from a machine that needs to run the Services for Unix.

Restrict Null Session Access

Null sessions are used for various unauthenticated legacy communications purposes. They can be exploited through the various shares that are on the computer. To prevent null session access to the computer, add a value called RestrictNullSessAccess to the registry. Setting the value to 1 restricts null session access to all server pipes and shares except those listed in the NullSessionPipes and NullSessionShares entries.

Key Path: HKLM\SYSTEM\ CurrentControlSet\Services\LanmanServer	Type	Value
Key: parameters Value Name: RestrictNullSessAccess	REG_DWORD	1

Restrict null session access over named pipes and shares

Prevent unauthorized access over the network. To restrict null session access over named pipes and shared directories, edit the Registry and delete the values as shown in the table below.

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer	Type	Value
Key: parameters Value Names: NullSessionPipes NullSessionShares	REG_MULTI_SZ	Delete all values

Note: Certain services need to use null session access. For example, Microsoft Commercial Internet System 1.0 requires the SQL\query pipe on the SQL Server computer it uses for the POP3 service to work.

Hide the computer from the network browse list

In Windows domains and workgroups one computer maintains a list of resources on the network. This list, called the Browse List, contains a list of shares, printers, etc, that are available on the network. By default, all computers with the SMB protocol installed advertise themselves to this resource list, maintained by the Master Browser, regardless of whether they have any resources to provide or not. While this imposes unnecessary network overhead in many cases, it also makes it trivial for a potential attacker inside the firewall to generate a list of available network resources. Therefore, it is desirable to turn off browser announcement from computers that do not have any resources to provide. One method to do this is to turn off the Computer Browser service. However, this would also prevent client computers from obtaining a copy of the browse list, making it significantly more difficult for end-users to locate legitimate network resources. A better solution is to hide the computer from the browse list. Primarily, this should only be done on workstations and laptops. Therefore, the two workstation templates and the laptop template included with this guide turn this setting off.

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer	Type	Value
Key: parameters Value Names: hidden	REG_DWORD	1

Note: This does not prevent an attacker from generating a list of resources on the network. Such a list can be generated using different means, particularly if anonymous enumeration of SAM accounts and shares is not turned off. However, it does make generating such a list much more time-consuming.

Service Pack 3 Registry entries

Service Pack 3 introduces a number of new registry entries that can be configured to enhance the security provided by the operating system.

Remove the default IPSec exemptions

Some types of traffic are exempted by design from being secured by IPSec, even when the IPSec policy specifies that all IP traffic should be secured. The IPSec exemptions apply to Broadcast, Multicast, RSVP, IKE, and Kerberos traffic. For details about these exemptions, please refer to Microsoft Knowledge Base article: 254949 "Client-to-Domain Controller and Domain Controller-to-Domain Controller IPSec Support." This exemption can be used by an attacker to circumvent IPSec restrictions. Therefore, it is important to remove it if at all possible. On systems that do not use IPSec, this setting has no effect.

Key Path: HKLM\SYSTEM\CurrentControlSet\Services	Type	Value
Key: IPSEC Value Name: NoDefaultExempt	REG_DWORD	1

For more information about this switch, please refer to Microsoft Knowledge Base article 811832

Change the DLL search order

Most programs on the Windows platform make use of various Dynamic Link Libraries (DLL) to avoid having to reimplement functionality. The operating system actually loads several DLLs for each program, depending on what type of program it is. When the program does not specify an absolute location for a DLL, the default search order is used to locate it. By default, the search order used by the operating system is as follows:

1. Memory

2. KnownDLLs

3. Manifests and .local

4. Application directory

5. Current working directory

6. System directories (%systemroot%, %systemroot%\system, and %systemroot%\system32)

7. The path variable

The fact that the current working directory is searched before the system directories can be used by someone with access to the file system to cause a program launched by a user to load a spoofed DLL. If a user launches a program by double-clicking a document, the current working directory is actually the location of the document. If a DLL in that directory has the same name as a system DLL in that location will then be loaded instead of the system DLL. This attack vector was actually used by the Nimda virus.

To combat this, a new setting was created in Service Pack 3, which moves the current working directory to after the system directories in the search order. To avoid application compatibility issues, however, this switch was not turned on by default. To turn it on, set the following registry value:

Key Path: HKLM\SYSTEM\CurrentControlSet\Control	Type	Value
Key: Session Manager Value Name: SafeDllSearchMode	REG_DWORD	1

Prevent interference of the session lock from application generated input

Service Pack 3 introduces a registry value that can be used to prevent application generated keyboard/mouse input messages from interfering with the session lock. By default, applications can generate fake input to keep the screensaver timeout from incrementing thereby preventing the screensaver from turning on. The value's name is BlockSendInputResets and as with most policy settings the value resides underneath the software\policy tree:

HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop

Policy takes precedence over a user applied setting. The value will be REG_SZ to be consistent with other related keys and will be interpreted as a Boolean value with any non –zero value meaning the value is set and the feature active. A zero value or a lack of the value will maintain the current functionality.

When this value is set only 'real' (mouse or keyboard) input will reset the screensavers timer. Currently there are 3 cases where injected input will reset the time.

• Input injected via SendInput – This is the case where an app is intentionally trying to simulate input and will be blocked.

• Window activation – When a new window becomes active the counter is reset. This will be blocked unless the screensaver is already active.

• Calls to SystemParametersInfo() that set SPI_SETSCREENSAVETIMEOUT, SPI_SETSCREENSAVEACTIVE, SPI_SETLOWPOWERTIMEOUT, SPI_SETLOWPOWERACTIVE, SPI_SETPOWEROFFTIMEOUT, SPI_SETPOWEROFFACTIVE. These will no longer result in the timer being reset if BlockSendInputResets is set. This should not have an effect on user experience, as a user setting these values will result in 'real' input from their mouse movement and keystrokes.

To enable this capability, edit the following Registry value as shown in the table below. The path may need to be created.

Key Path: (Policy) HKCU\Software\Policies\Microsoft\Windows\Control Panel	Type	Value
Key: Desktop Value Name: BlockSendInputResets	REG_SZ	1

Note: It is important to note that the appropriate screen saver settings must be set in conjunction with this value for the feature to make sense. The necessary screen saver settings are:

• A selected screen saver

• Password protection

• A screen saver timeout period

If the screensaver is not properly configured this feature will essentially have no effect on the machines overall security. Procedures for setting a password protected screen saver are available in the "Enable Automatic Screen Lock Protection" subsection.

Generate an audit event when the audit log reaches a percent full threshold

Service Pack 3 includes a feature for generating a security audit in the security event log when the security log reaches a configurable threshold. To enable this capability create the value shown in the table below. The data in the value designates the percent value that will cause the event to be recorded in the security log. The value shown in the table below is a recommendation and can be configured to an appropriate value based on local operational needs. For example, if set as shown below, and the security log size reaches the percent shown (90), the security log will show one event entry for eventID 523 with the following text: "The security event log is 90 percent full." An IDS can be configured to key off of that event and perform a log dump and reset.

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\Eventlog	Format	Value
Key: Security Value Name: WarningLevel	REG_DWORD	90

Note: Will not work if log is set to "Overwrite events as needed"

Harden the TCP/IP stack against denial of service attacks

Denial of service attacks are network attacks aimed at making a computer or a particular service on a computer unavailable to network users. The following Registry TCP/IP-related values help to increase the resistance of the Windows 2000 TCP/IP Stack in Windows 2000 against denial of service network attacks. Some of the values listed below will need to be added the specified Registry key. Additional details can be found in Microsoft Knowledge Base Article 315669, "HOW TO: Harden the TCP/IP Stack Against Denial of Service Attacks in Windows 2000."

These values can be set on all systems:

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip	Format	Value
Key: Parameters Value Name: DisableIPSourceRouting	REG_DWORD	2
Key: Parameters Value Name: EnableDeadGWDetect	REG_DWORD	0
Key: Parameters Value Name: EnableICMPRedirect	REG_DWORD	0
Key: Parameters Value Name: EnableSecurityFilters	REG_DWORD	1
Key: Parameters Value Name: KeepAliveTime	REG_DWORD	300,000
Key: Parameters Value Name: PerformRouterDiscovery	REG_DWORD	0
Key: Parameters Value Name: SynAttackProtect	REG_DWORD	2
Key: Parameters Value Name: TcpMaxConnectResponseRetransmissions	REG_DWORD	2
Key: Parameters Value Name: TcpMaxConnectRetransmissions	REG_DWORD	3
Key: Parameters Value Name: TcpMaxDataRetransmissions	REG_DWORD	3
Key: Parameters Value Name: TCPMaxPortsExhausted	REG_DWORD	5

Additionally, to further harden a critical server which serves SMB traffic, such as a file server or a domain controller, set these values:

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip	Format	Value
Key: Parameters Value Name: EnablePMTUDiscovery	REG_DWORD	0

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\NetBT	Format	Value
Key: Parameters Value Name: NoNameReleaseOnDemand	REG_DWORD	1

It is not recommended to set these values on clients. EnablePMTUDiscovery disables discovery of the Maximum Transfer Unit to prevent the stack from becoming overworked by an attacker setting a very small MTU. On client systems, you will get better performance if you leave this value at its default setting (1). The NoNameReleaseOnDemand setting configures the system to refuse name release requests to release its SMB name. This setting prevents an attacker from sending a name release request to a server, causing the server to be inaccessible to legitimate clients. If this setting is configured on a client, however, and that client is misconfigured with the same name as a critical server, the server will be unable to recover the name, and legitimate requests may be directed to the rogue server instead, causing a denial of service condition at best.

Review time service authentication

Review the key shown in the table below to ensure the "type" value is set to NT5DS. This ensures the system is operating with authenticated time service.

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\W32Time	Format	Value
Key: Parameters Value Name: type	REG_SZ	Nt5DS

Note: Due to a limitation in the Security Configuration Editor interface, this setting cannot be shown the user interface. It will, however, be configured since it is set in the baseline template.

Disable LMHash creation

Windows 2000-based servers can authenticate computers running all previous versions of Windows. However, previous versions of Windows do not use Kerberos for authentication, so Windows 2000 supports LAN Manager (LM), Windows NT (NTLM) and NTLM version 2 (NTLMv2). While NTLM, NTLMv2, and Kerberos all use the Unicode hash, also known as the NT Hash, the LM authentication protocol uses the LM hash. The LM hash is relatively weak compared to the NT hash and therefore prone to rapid brute force attack. The LM hash also removes a considerable amount of the entropy added to the hash by using complex passwords. Therefore, it is desirable to prevent storage of the LM hash if it is not necessary for backward compatibility. In an environment with only Windows 95 and newer clients, the LM hash is not needed. However, a user without an LM Hash will not be able to connect to a Win9x computer acting as a server.

Windows 2000 Service Packs 2 and higher provide a registry setting to disable the storage of the LM hashes. Additional details can be found in Microsoft Knowledge Base article 299656, "New Registry Key to Remove LM Hashes from Active Directory and Security Account Manager."

Key Path: HKLM\SYSTEM\CurrentControlSet\Control\LSA	Format	Value
Key: NoLMHash	N/A	N/A

On Windows 2000, this setting is a key, called NoLMHash. However, creating that key on Windows XP or Windows Server 2003 has no effect. On those operating systems, the setting is a DWORD value called NoLMHash. If you are creating a custom policy template that may be used on all these operating systems, you can create both the key and the value (the value is in the same place and a value of 1 disables creation of the LM hash). While the key is upgraded when a Windows 2000 system is upgraded to Windows Server 2003, there is no harm in both settings being in the registry.

Note: The baseline template configures this policy. If you have clients running Windows 3.1 or the original release of Windows 95 that need to connect to a Windows 2000 system it is imperative that you do not configure this setting for the Windows 2000 system.

Disable autorun

Autorun begins reading from a drive as soon as media is inserted in it. As a result, the setup file of programs and the sound on audio media starts immediately. To prevent a possible malicious program from starting when media is inserted, create the following Registry key to disable autorun on all drives.

Key Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies	Format	Value
Key: Explorer Value Name: NoDriveTypeAutoRun	REG_DWORD	255

Note that auto run is a usability setting which users have come to expect. Therefore, it is recommended only to make this change on servers and workstations where administrators log on.

LDAP BIND command request settings

This value is used to determine the LDAP server (ldapagnt.lib) handling of LDAP bind command requests as follows.

• 1 (default) or not defined: The AD's LDAP agent always supports LDAP client request for LDAP traffic signing when handling a LDAP bind command request which specifies a SASL authentication mechanism.

• 2: The ADs LDAP agent only supports SASL in a LDAP bind command request unless the incoming request is already protected with TLS/SSL. It rejects the LDAP bind command request if other types of authentication are used. If the LDAP bind command request does not come in via TLS/SSL, it requires the LDAP traffic signing option in the client security context.

To set this value, edit the Registry key as shown in the table below and create the value LdapServerIntegrity with a value of 2.

Key Path: HKLM\System\CurrentControlSet\Services\NTDS	Format	Value
Key: Parameters Value Name: LdapServerIntegrity	REG_DWORD	2

Note, this setting has no effect on client systems.

Generate administrative alert when the audit log is full

To add Alerter service recipients for Windows 2000 based computers, edit the Registry (using Regedt32.exe) as shown in the table below. The Value entry will be the name of each recipient (user name or computer name) that is to receive the administrative alerts. Each recipient should be on a separate line in the Data dialog box.

Key Path: HKLM\SYSTEM\CurrentControlSet\Services\Alerter	Format	Value
Key: Parameters Value Name: AlertNames	REG_MULTI_SZ	As explained above

Note: Administrative alerts rely on both the Alerter and Messenger services. Make sure that the Alerter service is running on the source computer and that the Messenger service is running on the recipient computer.

Turn off web view in folders

Folder web view (known as Common Tasks in Windows XP) allows folders to be customized using background pictures and other active content. It also enables parsing of content when it is selected in the folder. If the content contains malicious code, such as a virus infected web page or Word document, the malicious code will fire as soon as the document is selected. It is highly recommended, therefore, to turn off web view at least on administrative workstations. This can be done in the GUI, by selecting "Use Windows Classic Folders" in the Folder Options dialog. It can also be done in the registry by configuring the following registry value:

Key Path: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced	Format	Value
Key: Advanced Value Name: WebView	REG_DWORD	1

Harden the NTLM SSP

Programs that use the NTLM Security Support Provider (SSP) - including programs communicating via RPC - are not directly affected by the LMCompatibilityLevel setting described above. The NTLM SSP uses its own security settings to control its behavior. By creating values called NtlmMinClientSec and NtlmMinServerSec it is possible to control the behavior of a system when acting as a client and server, respectively.

The setting is a bitmask where the actual data is the logical OR of the following values:

• 0x00000010 Message integrity

• 0x00000020 Message confidentiality

• 0x00080000 NTLMv2 session security

• 0x20000000 128 bit encryption

• 0x80000000 56-bit encryption

In other words, to enforce message integrity, confidentiality, use of NTLMv2 and 128-bit encryption, set the value 0x20080030. We recommend that this setting be set as high as is possible while still allowing the applications used on the network to function.

Key Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA	Format	Value
Key: MSV1_0Value Name: NtlmMinClientSec and NtlmMinServerSec	REG_DWORD	0x20080030

Note: This setting will break applications. The following are known incompatibilities:

• FrontPage 2000 is incompatible with 0x20080000. When using that setting, the FrontPage client will be unable to communicate with the FrontPage Server Extensions Server

• A node will be unable to join a cluster when NtlmMinServerSec is configured

It is also important that the client and server settings match. Many local administration tools use RPC for communication and if the client and server settings do not match, it is likely that these tools will fail to make local connections. Remote connections may fail if the NtlmMinClientSec setting on the Client does not match the NtlmMinServerSec setting on the server. Therefore, it is important to ensure that the same setting is made for both settings consistently in a network.

Audit Log Management

Management options for event logs, including the security log, can be configured for all computers in a domain by using the Even Log folder within the Domain Security Policy or a specific Group Policy object associated with domains, OUs, and sites (Domains). The Event Log folder does not appear in the Local Security Policy object. On those systems, these settings area managed in the Event Log snap-in directly.

For domain members, the management options for local audit can be configured using the Event Viewer Snap-In. From the Event Viewer, the applicable Properties interface is selected to set the management options for a particular log, such as the Security log.

These interfaces allow for viewing, sorting, filtering, and searching the event logs as well as setting the maximum log size or clearing the log. The user must have access to the event log file in order to successfully view it. To view the contents of the security log, the user must be logged on as a member of the Administrator's group. No special privilege is required to use the Event Viewer itself. Security is enforced by the ACL on the log and certain registry settings.

Access the Settings for Event Logs

View current settings for event logs and allow editing.

Procedure for Domain and Domain Controller Policies:

1. Open the Domain Security Policy or the Domain Controller Security Policy as applicable.

2. Expand Security Settings.

3. Within Security Settings, expand Event Log to reveal the Settings for Event Logs policy.

4. Click on the Settings for Event Logs object. The right-hand details pane will reveal the configurable audit log management settings.

   

Procedure for Standalone Workstations and Servers:

1. Open the Event Viewer, Click Start, point to Programs, point to Administrative Tools, and then click Event Viewer.

2. Right-click on the Security Log object and select Properties. The Security Log Properties window will appear revealing the configurable audit log management settings.

   

   Set the Audit Policies as recommended in Table 4.8.

Table 4.8 Audit Management Settings

Audit Management and Configuration	Domain WKS	Domain Laptop	DC	Domain Server	Standalone WKS	Stand-alone Server
Set Maximum Application Log Size Security Objective: Specifies the maximum size for the Application event log. The default is 512KB, and the maximum size is 4GB (4,194,240KB). Requirements for the Application log size vary depending the function of the platform and the need for historical records of application related events. Recommendation: The default setting is adequate on most systems.
Set Maximum Security Log Size Security Objective: Specifies the maximum size for the Security event log. The default is 512KB, and the maximum size is 4GB. Recommendation: Configure to at least 20 MB on DCs and servers. Configure other systems such that the log size is adequate based on the frequency with which logs are reviewed, available disk space, etc. The templates configure the log size for all other systems to 5 MB.
Set Maximum System Log Size Security Objective: Specifies the maximum size for the System event log. The default is 512KB, and the maximum size is 4GB. Recommendation: For most environments, the default setting is adequate.
Restrict Guest Access to the Application Log Security Objective: Prevent anonymous access to the Application event log. If this policy is enabled, guests are prevented from access to the Application event log. By default, this policy is disabled locally on all Windows 2000 operating systems. Recommendation: Set this to enabled on all systems. Note: By default, guest access is prohibited on all systems. Therefore, this setting has no real effect on default systems. However, it is a defense-in-depth setting that has very few side effects.
Restrict Guest Access to the Security Log Security Objective: Prevent anonymous access to the Security event log. If this policy is enabled, guests are prevented from access to the Security event log. By default, this policy is disabled locally on all Windows 2000 operating systems. A user must possess the Manage auditing and security log user right in order to access the security log. Since Guest does not have that right, this setting is simply defense in depth. Recommendation: Set this to enabled on all systems.
Restrict Guest Access to the System Log Security Objective: Prevent anonymous access to the System event log. If this policy is enabled, guests are prevented from access to the System event log. By default, this policy is disabled locally on all Windows 2000 operating systems. Recommendation: Set this to enabled on all systems.
Retain Application Log Security Objective: Determines the number of days' worth of events that should be retained for the Application log if the retention method for the application log is set to Overwrite events by days in a Domain policy, or if the Overwrite events older than option is selected in the Application Log Properties window of a standalone workstation or server. Set this value only if the log is archived at scheduled intervals and make sure that the maximum Application log size is large enough to accommodate the interval. Recommendation: Do not change the default setting of "Not Defined." Note: it is imperative that the logs are archived regularly if historical events are desirable for either forensics or troubleshooting purposes. Overwriting events as needed ensures that the logs always keep the most recent events, although this could result in the loss of historical data.
Retain Security Log Security Objective: Determines the number of days' worth of events that should be retained for the Security log if the retention method for the application log is set to Overwrite events by days in a Domain policy, or if the Overwrite events older than option is selected in the Security Log Properties window of a standalone workstation or server. Set this value only if the log is archived at scheduled intervals and make sure that the maximum Security log size is large enough to accommodate the interval. Recommendation: Do not change the default setting of "Not Defined.". Note: It is imperative that the logs are archived regularly if historical events are desirable for either forensics or troubleshooting purposes. Overwriting events as needed ensures that the logs always keep the most recent events, although this could result in the loss of historical data.
Retain System Log Security Objective: Determines the number of days' worth of events that should be retained for the System log if the retention method for the application log is set to Overwrite events by days in a Domain policy, or if the Overwrite events older than option is selected in the System Log Properties window of a standalone workstation or server. Set this value only if the log is archived at scheduled intervals and make sure that the maximum System log size is large enough to accommodate the interval. Recommendation: Do not change the default setting of "Not Defined.". Note: It is imperative that the logs are archived regularly if historical events are desirable for either forensics or troubleshooting purposes. Overwriting events as needed ensures that the logs always keep the most recent events, although this could result in the loss of historical data.
Retention Method for Application Log Security Objective: Determines how Application logs that have reached their maximum size will be handled by the operating system. Recommendation: Set this to "Overwrite events as needed" to ensure that the most recent events get logged.
Retention Method for Security Log Security Objective: Determines how Security logs that have reached their maximum size will be handled by the operating system. Recommendation: Set this to "Overwrite events as needed" to ensure that the most recent events get logged.
Retention Method for System Log Security Objective: Determines how System logs that have reached their maximum size will be handled by the operating system. Recommendation: Set this to "Overwrite events as needed" to ensure that the most recent events get logged.
Shut Down the Computer when the Security Log is Full Security Objective: Determines whether the system should shut down if it is unable to log security events. If this policy is enabled, it causes the system to halt if a security audit cannot be logged for any reason. Typically, an event will fail to be logged when the security audit log is full and the retention method specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days. Recommendation: Do not enable this setting. Doing so will make a denial of service attack extremely easy and will significantly affect uptime.

Default Group Accounts

This subsection discusses required and recommended changes to default group memberships for the built-in groups found in default Windows 2000 operating system installations. These built-in groups have a predefined set of user rights and privileges as well as group members. The five built-in group types are defined as follows:

• Global Groups. When a Windows 2000 domain is established, built-in global groups are created in the Active Directory store. Global groups are used to group common types of user and group accounts for use throughout the entire domain. New to Windows 2000, global groups can now contain other groups in a native mode domain.

• Domain Local Groups. Domain local groups provide users with privileges and permissions to perform tasks specifically on the domain controller and in the Active Directory store. Domain local groups are used only within a domain and cannot be exported to other domains in an Active Directory tree.

• Universal Groups. Universal groups are only available in a native Windows 2000 domain. They can be used across the entire forest.

• Local Groups. Stand-alone Windows 2000 Servers, member servers, and workstations have built-in local groups. These built-in local groups provide members with the capability to perform tasks only on the specific computer to which the group belongs.

• System Groups. System groups do not have specific memberships that can be modified. Each is used to represent a specific class of users or to represent the operating system itself. These groups are created within Windows 2000 operating systems automatically, but are not shown in the group administration GUIs. These groups are used only for controlling access to resources.

Review / Modify Group Account Memberships for a Domain

1. To access group accounts within a Domain, log in with an administrative account on the Domain Controller.

2. Open Start, point to Administrative Tools, and then click Active Directory Users and Computers.

3. In the console tree, double-click the domain node.

4. Group accounts are found in the Builtin and Users containers.

   

Review / Modify Group Account Memberships for a Standalone or Member Computer

1. To access group accounts within a Standalone or individual Domain Member computer, log in with an administrative account.

2. Open Start, point to Administrative Tools, and then click Computer Management.

3. In the console tree, double-click on Local Users and Groups.

4. Group accounts are found in the Groups container.

   

Note: Set Group Memberships as recommended in Table 4.9. This table lists default groups. A checkmark for a particular system role indicates that the group is native to, and needs to be managed on, that system type.

Change the Primary Group Membership of an Account

Some of the required group membership changes identified in the table below call for removing an account from a specific group. For compatibility with other network protocols, such as AppleTalk, accounts must have a primary group assignment in a domain. It may therefore be necessary to first change the account's primary group membership that is set by default when a computer is joined to a domain. If an attempt is made to remove an account from its primary group in the Active Directory Computers and Users GUI, the action will be denied and the following message will appear:

Use the following procedures to change an account's primary group:

1. Log in with an administrative account on the Domain Controller.

2. Open Start, point to Administrative Tools, and then click Active Directory Users and Computers.

3. In the console tree, double-click the domain node.

4. User accounts are found in the Users container.

5. Right-click on the account name and select Properties from the menu. The account Properties GUI will appear.

6. Click on the Member Of tab to display the list of groups the account belongs to. Observe that when clicking any of the groups in the Member of: window, the Set Primary Group button will be either active or inactive. The Set Primary Group button will be active for groups which can be set as primary groups and will be inactive for groups either cannot be set as primary groups or which are already the primary group.

   

7. To change the primary group of the account, select the group that will become the new primary group and click on the Set Primary Group (must have the Set Primary Group button active). Note that the group identified above the Set Primary Group button as the Primary group: will change to the new selection.

8. Click the Apply and click OK.

Note 1 If an account is removed from a group using the Group Policy GUI instead, it is possible that an account is left without a primary group. This will have no adverse affects unless the account needs to be used from a Posix application or a Macintosh client.

Note 2 In the following table we will frequently refer to a SID. A SID is a Security Identifier, which is a value representing a particular user or group. For example, the Anonymous Logon group is represented by the SID S-1-5-7. For more information, see the Well Known Identifiers article on Technet at https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsfe_sid_yokv.mspx?mfr=true or in the Windows 2000 Resource Kit.

Table 4.9 Group Memberships

Group Membership Modifications			Domain WKS	Domain Laptop	DC	Domain Server	Standalone WKS	Stand-alone Server
Global and Universal Groups	Default Members	Modification / Verification
DnsUpdateProxy	None	Do not add accounts to this group.
Domain Admins	Administrator	Do not add non-administrative accounts to this group.
Domain Guests	Guest	Do not add accounts to this group.
Domain Users	Administrator Guest Krbtgt TsInternetUser (All new users are added by default)	Remove the Guest account and ensure the TsInternetUser account is disabled. Note: Before removing the Guest account, change the primary group for that account to Domain Guests.
Enterprise Admins	Administrator (Domain Controller Administrator)	Do not add non-administrative accounts to this group. Caveat: This group will have full administrative privileges on every computer in the entire forest. Under no circumstances should accounts in this group be used for any other purposes than administering systems.
Group Policy Creator Owner	Administrator	Do not add non-administrative accounts to this group.
Schema Admins	Administrator	Do not add non-administrative accounts to this group.
Domain Local Groups	Default Members	Modification / Verification
Account Operators	None	Use this group only for administrators who should only be able to manage accounts. These users need to be as well screened as ordinary administrators.
Administrators	Administrator Domain Admins Enterprise Admins	Do not add non-administrative accounts to this group.
Backup Operators	None	Do not add non-administrative accounts to this group. Note: Backup operators can read all files on a system, regardless of the permissions of those files. Since they can also restore files, they can adversely affect both the security and the stability of the system.
DnsAdmins	None	Do not add non-administrative accounts to this group.
Guests	Guest (Local) Domain Guests TsInternetUser	Do not use this group.
Pre-Windows 2000 Compatible Access	None	Provides backward compatibility with pre-Windows 2000 operating systems. Use of this group will significantly loosen the permissions on Active Directory. By default, this group has no members. However, if the domain was created in "Pre-Windows 2000 Compatibility Mode" the Everyone group is a member of this group, giving Everyone read permission to all Active Directory objects. To disable this remove the Everyone group from the Pre-Windows 2000 Compatible Access group and reboot all domain controllers. This will, however, adversely affect backward compatibility.
Print Operators	None	Do not add non-administrative accounts to this group. These users can install kernel mode drivers, and therefore compromise both stability and security.
Replicator	None	Do not add non-administrative accounts to this group.
Server Operators	None	Do not add non-administrative accounts to this group. This group is designed to prevent well-meaning users from doing as much damage as they could if they were administrators. It is not designed to contain malicious users from compromising the system.
Users	Authenticated Users Domain Users INTERACTIVE (All new local users are added by default)	Do not add accounts with a potential for unauthenticated access (such as Guest) to this group.
Local Groups	Default Members	Modification / Verification
Administrators	Stand-Alone: Administrator Domain Member: Administrator Domain Admins	Do not add non-administrative accounts to this group.
Backup Operators	None	Do not add non-administrative accounts to this group.
Guests	Stand-Alone Professional: Guest Stand-Alone Server: Guest TsInternetUser Domain Member: Add Domain Guests to the above	Do not use this group. Remove all accounts, including Guest, from this group.
Power Users	None	This group is equivalent in power to the Server Operators group. It is provided for backward compatibility with applications which will not run as a normal user. Using Power Users prevents organizations from having to make users administrators to allow them to run these applications. In some environments, Power Users is absolutely essential, as the only other option is to make users Administrators. However, in environments where the Power Users group is not needed, its membership should be controlled using Group Policy by making it a restricted group. It is important to keep in mind that making a user a member of the Power Users group does not prevent that user from easily becoming an Administrator. This group is meant to contain well-meaning users. It can not contain malicious users. Therefore, its use should be evaluated carefully.
Replicator	None	Do not add non-administrative accounts to this group.
Users	Stand-Alone: Authenticated Users INTERACTIVE (All new local users are added by default) Domain Member: Authenticated Users Domain Users INTERACTIVE (All new local users are added by default)	Do not add accounts with a potential for unauthenticated access (such as Guest) to this group.
System Groups	Default Members	Modification / Verification
Anonymous Logon	All unauthenticated users	This group is used to grant access to resources to users who do not or cannot authenticate. In general, this is undesirable. Therefore, do not use this group unless some application or usage scenario requires it. Do not grant resource permissions or user rights to this group.
Authenticated Users	All authenticated users	Use the Authenticated Users group instead of the Everyone to prevent the potential for anonymous access to resources.
DIALUP	All dial-in users	In the rare case that Dial-up users need particular permissions they would not otherwise have, this group is useful. For simplicity, it is easier not to use this group.
SERVICE	Any process running as a service gets this SID	Generally speaking, it is not necessary to use this group to assign rights
SELF	The security principal represented by the object.	Use this SID to assign users the right to modify their own objects in Active Directory.
NETWORK	Users accessing the computer through the network.	This sid is primarily used for IIS. Any user accessing the server through authenticated web access (other than basic authentication) gets this SID. Therefore, it can be used to grant access to resources for those users.
INTERACTIVE	All users accessing the computer locally, i.e. at the console. Also, all users accessing the computer through the web server using Basic Authentication or using authenticated FTP and Telnet get this SID.	Be very careful assigning access for this SID. It will allow any user who can get to the system locally to access those resources. Also, keep in mind that anonymous access to IIS is considered a local logon. Therefore, anonymous web users can get to resources where INTERACTIVE have access, if those resources are exposed via an IIS VRoot.
Everyone	All users accessing the computer, either locally, through the network, or through RAS. This includes all authenticated and unauthenticated users.	Do not assign resource permissions or user rights to this account. Use Authenticated Users or specific user accounts and groups where necessary. Note this group is necessary to use in some situations to support down-level clients who do not authenticate with the system.
TERMINAL SERVER USER	None	Used to provide terminal services users with permissions they would not normally have when connecting to the system interactively. In most cases, it would be simpler to use the Users group.

Default User Accounts

This subsection discusses required and recommended changes to built-in user accounts found in default Windows 2000 operating system installations. The built-in user accounts include Administrator, Guest, and TsInternetUser.

Review / Modify Default User Accounts for a Domain

Review or modify user accounts to ensure your security goals are being met.

1. To access user accounts within a Domain, log in with an administrative account on the Domain Controller.

2. Open Start, point to Administrative Tools, and then select Active Directory Users and Computers.

3. In the console tree, expand the domain node.

4. User accounts are found in the Users container.

   

Review / Modify Default User Accounts Locally

Review or modify user accounts within a Standalone or individual Domain Member computer to ensure your security goals are being met.

1. Open Start, point to Administrative Tools, and then select Computer Management.

2. In the console tree, expand Local Users and Groups.

3. User accounts are found in the Users container.

   

Modify User Accounts as recommended in Table 4.10.

Table 4.10 Default User Accounts

User Account Modifications			Domain WKS	Domain Laptop	DC	Domain Server	Standalone WKS	Stand-alone Server
Local User Accounts	Description	Modification / Verification
Administrator	Built-in account for administering the computer/Domain.	Do not use this account for day-to-day administration. Assign each administrator two accounts, one for their day-to-day use, such as reading e-mail, and one for administrative duties. For security reasons, administrative accounts should never be used for e-mail purposes.
Guest	Built-in account for guest access to the computer/Domain.	This account should be disabled
TsInternetUser	User account used by Terminal Services. It is used by the Terminal Services Internet Connector License and is available on Windows 2000 Servers. When Internet Connector Licensing is enabled, a Windows 2000-based server accepts 200 anonymous-only connections. Terminal Services clients are not prompted with a logon dialog box; they are logged on automatically with the TsInternetUser account.	Treat this account as you would any other anonymous account. Do NOT permit usage of anonymous accounts on Domain Controllers.

System Services

Table 4.11 lists the system services that should be enabled on secure Windows 2000 computers.

To enable or disable services on all or a group of Windows 2000 platforms in a domain, set a Domain Security Policy. For settings on domain controllers use the Domain Controller Security Policy interface. Local settings on individual Windows 2000 platforms can be set through the Computer Management interface, the Local Security Policy interface or by applying a security template using secedit.exe.

Disable Unnecessary System Services on Domain Computers

Set a policy to disable unnecessary services within a Domain. Also, set a policy to disable unnecessary services for Domain Controllers.

1. Open the Domain Security Policy or the Domain Controller Security Policy as applicable.

2. Expand Security Settings and click on System Services.

3. From the right-hand pane, select a service to disable. Right-click on the selected service and select Security.

4. In the Security Policy Setting dialog window, check the Define this policy setting box and then select the Disabled radio button.

   

5. Click the OK button.

Disable Unnecessary System Services Locally

Disable unnecessary services locally on Windows 2000 Server or Professional operating systems being used in standalone or workgroup scenarios.

1. Open the Computer Management interface.

2. In the console tree, expand Services and Applications and select Services.

3. From the right-hand pane, select a service to disable. Right-click on the selected service and select Properties.

4. The Properties dialog box for the selected services will appear. From the Startup type: drop down menu, select Disabled.

   

5. Under Service status: click on the Stop button.

6. Click the OK button.

Minimum System Services

Table 4.11 lists the system services that should be enabled on secured Windows 2000 computers.

Table 4.11 Acceptable Services for secured Windows 2000 computers

Alerter Service Automatic Updates Background Intelligent Transfer Service COM+ Event System Computer Browser DHCP Client DHCP Server Distributed File System (DFS) Distributed Link Tracking Client Distributed Link Tracking Server DNS Client DNS Server Event Log File Replication Service IIS Admin Service (only on web servers) Indexing Service (only on systems which need file indexing) Intersite Messaging IPSec Policy Agent Kerberos Key Distribution Center License Logging Service Logical Disk Manager Logical Disk Manager Administrative Service Messenger Net Logon

Network Connections NTLM Security Support Provider Plug and Play Print Spooler Protected Storage Remote Procedure Call (RPC) Remote Registry Service Removable Storage RunAs Service Security Accounts Manager Server Service System Event Notification Task Scheduler TCP/IP NetBIOS Helper Service Telephony Terminal Services (server only) Windows Internet Name Service (WINS) Windows Management Instrumentation Windows Management Instrumentation Driver Extensions Windows Time Workstation World Wide Web Publishing Service, Simple Mail Transport Service, NNTP Service, and FTP Service should ONLY be enabled on bona fide IIS servers. Ensure that they are disabled or uninstalled on all other computers.

Securing the File System

Windows 2000 includes the ability to protect files using discretionary access control lists (DACL), sometimes referred to as permissions collectively. The default set of file and directory permissions once Service Pack 3 has been applied provides a reasonable level of security for most application environments. However, certain DACLs can be improved over these defaults. Default file and directory permissions are applied during operating system installation via the "setup security.inf" security template file, which is described as containing the "out of box default security settings."

To ensure greater security, consider modifying file, directory, and subdirectory permissions as recommended in the table below immediately after installing the operating system and updating it with the latest service pack and all patches issued since that service pack. Use the inheritance features in Windows 2000 to set permissions as high up in the directory tree as possible. This simplifies permissions management significantly. The permission changes recommended below apply to all Windows 2000 operating systems. To implement permissions on all or a group of Windows 2000 platforms in a domain use Group Policy. It is preferable to set permissions at the OU level as opposed to the domain level. An OU can easily be constructed to contain all machines with particular security requirements. Local permissions on individual Windows 2000 platforms can be set through the Security Configuration Editor interface using the included templates.

Set Permissions through a Domain Policy

Set a file and folder permissions policy for the Domain. Set a file and folder permissions policy for Domain Controllers.

1. Open the appropriate group policy object.

2. Expand Security Settings.

3. Within Security Settings, right-click on File System.

4. Select Add File.

5. From the Add a file or folder window, navigate to and select the desired file or folder.

   

6. Click the OK button. A window labeled Database Security for path\filename Properties will appear.

   

7. Set permissions as necessary. File and Folder permission settings are provided in Table 4.12.

Set Permissions Locally through the Security Configuration Editor

The easiest method to set permissions in a repeatable fashion on a stand-alone system or locally is to use the Security Configuration Editor tool. The following instructions demonstrate how to define and set permissions on the root of a newly added drive.

1. Open the Microsoft Management Console by chosing Start:Run and type MMC.

2. Select Console:Add/Remove Snap-in and click Add...

3. Double-click Security Configuration and Analysis and Security Templates and click Close. Click OK. Save the console if desirable

4. Expand the Security Templates node and select New Template... Save the new template with a descriptive name

   

5. Expand the new template so you can see the File System node

6. Right-click File System and select Add File... Select the new drive, in our case, D:

7. Set the permissions as shown in this picture:

   

8. Click OK to close all the dialogs. Right-click the new template and select Save

9. Right click on Security Configuration and Analysis and select Open Database

10. Type any name for the database and click OK

11. If you are opening an existing database it is imperative that you select the Clear this database before importing switch in the next dialog. Then select the new template you just created and click Open.

    

12. Right-click Security Configuration and Analysis and select Configure Computer Now.... Select a path for the error log (the default path is fine).

13. You can now verify the permissions in the standard ACL editor in Windows Explorer. However, these ACLs can now be saved for the future, or applied to another system.

Table 4.12 File and Folder Permission Settings

Files and Folders	DACL Settings	Inheritance Method (Set via Security Policy tools)	Domain WKS	Domain Laptop	DC	Domain Server	Stand-alone WKS	Stand-Alone Server
%SystemDrive% Note: Drive where the Windows 2000 operating system is installed. Note: These permissions should be applied to all other non-removable drives as well. If these permissions are set on the root of all drives, they will allow users to create folders and then files within those folders, but will prevent them from modifying anything on the drive that they did not create themselves. Note also the use of Everyone. Since we are restricting anonymous access to the system Everyone becomes equivalent to any user who has authenticated as long as the Guest account remains disabled.	Administrators: Full Control CREATOR OWNER: Full Control (Subfolders and Files) SYSTEM: Full Control Users: Read & Execute (This folder, subfolders, and files) Users: Create Folders / Append Data (This folder and Subfolders) Users: Create Files / Write Data (Subfolders only) Everyone: Read & Execute	Propagate

Share Folder Permissions

The native Windows 2000 file sharing service is provided using the SMB-based server and redirector services. Even though only administrators can create shares, the default security placed on the shares allows the group Everyone to have Full Control access. These permissions allow access to the network-visible shares themselves. Access to the files and subfolders displayed through the share is controlled by the NTFS permissions that are set on the underlying folder to which a share maps. It is therefore recommended that proper security be applied via NTFS permissions to any files and folders mapped by a share. In effect, setting Full Control for Everyone equates to managing permissions only on the underlying file system, not on the share itself.

Securing the Registry

In addition to the considerations for standard security described in this document, security administrators may want to increase protections on certain keys within the Windows 2000 Registry. By default, protections are set on various components of the registry that allow work to be done while providing standard-level security. Default Registry key permissions are applied during operating system installation via the setup "security.inf" security template file, which is described as containing the "out of box default security settings."

Microsoft has configured the default Registry ACL settings for Windows 2000 to address security issues associated with the default Registry ACL settings identified for Windows NT 4.0. In addition, Service Pack 2 and higher harden portions of the registry over the default settings. Therefore, the ACL changes defined in Table 4.13 provide only a small number of changes that will have minimal application impact and will protect sensitive data locations in the registry. All such changes should be done with caution, because there is always a risk that a small number of untested third party applications may no longer function properly. Recommended permission changes apply to all Windows 2000 operating systems. However, due to the different group usage on the various platforms, the permissions differ subtly between clients, servers, and domain controllers. Therefore, it is important not to apply client permissions to anything other than clients, and so on. If a mistake is made, reduced functionality of your systems is the likely result. However, the mistake can usually be resolved by re-applying the proper template.

To implement permissions on all or a group of Windows 2000 platforms in a domain set a Domain Security Policy. For settings on domain controllers use the Domain Controller Security Policy interface. Local permissions on individual Windows 2000 platforms can be set through the Regedt32.exe interface or using security templates and the secedit.exe utility.

Set Registry Permissions through a Domain Policy

Set Registry permissions policies for the Domain and for Domain Controllers.

1. Open the Domain Security Policy or the Domain Controller Security Policy as applicable.

2. Expand Security Settings.

3. Within Security Settings, right-click on Registry.

4. Select Add key.

5. From the Select Registry Key window, navigate to and select the desired key.

   

6. Click the OK button. A window labeled Database Security for path Properties will appear.

   

7. Set permissions as necessary. Required DACL changes are provided in Table 4.13.

Set Registry Permissions through Regedt32.exe

To set Registry permissions locally:

1. Click the Start button and select Run...

2. Type regedt32 and click the OK button to open the Registry Editor (Regedt32.exe).

3. Navigate to and select the desired Registry key.

   

4. From the Security menu, select Permissions. The Permissions for... dialog window will appear. Click Advanced for more detailed permission settings.

   

5. Set permissions as necessary. DACL changes are provided in Table 4.13.

Notes

1. If you wish to manage the Propagate or Replace behaviors like with the file system permissions, you must use the Advanced button. Through the Advanced button, permissions can be propagated by applying them to the current key, and subkeys. By default, permissions are replaced by applying them to the current key only.

2. The Read Control ACE in Regedt32.exe is called "Read Permissions" in the Security Policy tools.

3. The Power Users group shown in the table below is not available on a Domain Controller and cannot be set from a Domain Controller to remote Windows 2000 computers. However, a security template applied to a group policy object can set permissions for this group.

Table 4.13 Required Registry Permission Changes

Registry Key	Subkey DACL Settings	Inheritance Method	Domain WKS	Domain Laptop	DC	Domain Server	Stand-alone WKS	Stand-Alone Server
\SOFTWARE\Microsoft\Windows NT\CurrentVersion	Users: Read; This key and subkeys Power Users: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read permissions; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only TERMINAL SERVER USER: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read permissions; This key and subkeys	Replace
\SOFTWARE\Microsoft\Windows NT\CurrentVersion	Authenticated Users: Read; This key and subkeys Server Operators: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read permissions; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
\SOFTWARE\Microsoft\Windows NT\CurrentVersion	Users: Read; This key and subkeys Power Users: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read permissions; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
The remaining settings reset the default DACL on a number of subkeys which had explicit DACLs. If we do not make these settings, they would get modified by the changes we made above
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\ProfileList	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Do not allow permissions on this key to be replaced
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\AEDebug	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Accessibility	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\AsrCommands	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only Backup Operators: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read permissions; This key and subkeys	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Classes	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Drivers32	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\EFS	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\FontMapper	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Font Drivers	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Windows	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Time Zones	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Svchost	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Setup\RecoveryConsole	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\SecEdit	Users: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Perflib	INTERACTIVE: Read; This key and subkeys Power Users: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\ProfileList	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Do not allow permissions on this key to be replaced
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\AEDebug	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Accessibility	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\AsrCommands	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only Backup Operators: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read permissions; This key and subkeys	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Classes	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Drivers32	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\EFS	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\FontMapper	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Font Drivers	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Windows	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Time Zones	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Svchost	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Setup\RecoveryConsole	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\SecEdit	Authenticated Users: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace
HKLM\System\Software\Microsoft\Windows NT\CurrentVersion\Perflib	INTERACTIVE: Read; This key and subkeys Server Operators: Read; This key and subkeys Administrators: Full Control; This key and subkeys SYSTEM: Full Control; This key and subkeys CREATOR OWNER: Full Control; Subkeys only	Replace

IPSec Policy

IPSec policies, rather than application programming interfaces (APIs), are used to configure IPSec security services. The policies provide variable levels of protection for most traffic types in most existing networks. IPSec policies can be configured to meet the security requirements of a user, group, application, domain, site, or global enterprise. Microsoft Windows 2000 provides an administrative interface called IPSec Policy Management to define IPSec policies for computers at the Active Directory level for any domain members, or on the local computer for non–domain members.

IPSec policies can be applied to computers, domains, or any organizational units created in Active Directory. IPSec policies should be based on an organization's guidelines for secure operations. Through the use of security actions, called rules , one policy can be applied to heterogeneous security groups of computers or to organizational units.

The management of IPSec policies is a complex topic, and beyond the scope of this document. While IPSec policies serve a very useful purpose in securing a Windows 2000 system, we refer the reader to more specific documentation on using IPSec, such as the article "Using IPSec to Lock Down a Server", which you can find here: https://www.microsoft.com/serviceproviders/columns/using_ipsec.asp.

Encrypting File System

Windows 2000 operating systems provide a native ability to encrypt files and folders on an NTFS volume through the use of its Encrypting File System (EFS). EFS uses a private key encryption mechanism for storing data in encrypted form on the network. EFS runs as a file system driver and uses both symmetric key encryption and public key encryption to protect the files.

As with IPSec, management of EFS is beyond the scope of this document. While using EFS is relatively simple, to achieve the maximum security benefit from the feature requires additional configuration. The interested reader is referred to the following resources on the topic:

• EFS Best Practices Knowledge Base Article
  https://support.microsoft.com/default.aspx?scid=kb;EN-US;223316&sd=tech

• Encrypting File System white paper
  https://www.microsoft.com/windows2000/techinfo/howitworks/security/encrypt.asp

Enable Automatic Screen Lock Protection

Enable a password-protected screensaver for the Evaluated Configuration. Doing so will enable a user desktop to be locked for security reasons by setting an automatic screen lock that is initiated with the screensaver after a set period of inactivity. Once the computer screen lock is invoked, access to the computer will only be allowed to the user whose account is currently logged on to the computer or by an authorized administrator.

Set an automatic screen lock by setting screensaver based screen lock as follows:

1. Right click on the user desktop and select Properties. The Display Properties window will appear.

2. Click on the Screen Saver tab.

3. Select a screen saver from the Screen Saver drop down menu.

4. Enter the number of minutes of inactivity that the system must wait before initiating the screen saver in the Wait: dialog box (the default of 15 minutes is recommended).

5. Select the Password Protected box.

   

6. Click OK to set the password protected screen saver.

Update the System Emergency Repair Disk

Update the system's ERD to reflect all the changes made. For instructions, see "Recommended Actions Prior to Installing Service Pack and
Hotfix Updates".