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.

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

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

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.

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

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.

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

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

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

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:

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.

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.

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.

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.

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.

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.

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.

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 introduces a number of new registry entries that can be configured to enhance the security provided by the operating system.

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.

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

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:

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.

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.

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.

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

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:

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

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

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.

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

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.

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.

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.

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.

Note, this setting has no effect on client systems.

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.

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.

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:

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.

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.

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.

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

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.

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.

   

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.

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

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

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.

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

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

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

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

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.

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

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

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.

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 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's ERD to reflect all the changes made. For instructions, see "Recommended Actions Prior to Installing Service Pack and
Hotfix Updates".