HP StorageWorks X5000, NSA Security Compliancy, C2 Security Compliancy, E3-FC2 Security Compliancy, CC Security Compliancy Technical Manual

NAS Security:

A technical guide to NSA, C2, E3-FC2, and CC Security Compliancy

1 Introduction ................................................................................................................................. 3

1.1 NSA Security Compliancy Overview ....................................................................................... 3

1.2 C2/CC Security Compliancy Overview ................................................................................... 4

1.3 E3/F-C2 Security Compliancy Overview.................................................................................. 4

2 NSA Security Compliancy ............................................................................................................. 4

2.1 Domain Model Design: Windows NT 4.0, Windows 2000, and Windows 2003 ....................... 5

2.2 Time Synchronization ............................................................................................................6

2.3 Organizational Unit (OU) and Group Policy Objects (GPOs) Design........................................... 7

2.4 Domain Level: Hardening the Domain Infrastructure Password Policy .......................................... 9

2.5 Domain Level: Hardening the Domain Infrastructure Account Lockout Policy .............................. 13

2.6 Domain Level: Hardening the Domain Infrastructure Kerberos Policy......................................... 15

2.7 Domain Level: Hardening the Domain Infrastructure Security Options ....................................... 15

2.8 Baseline Level ..................................................................................................................... 17

2.8.1 Audit Policy .................................................................................................................. 17

2.8.2 User Rights Assignments ................................................................................................. 27

2.8.3 Security Options............................................................................................................ 37

2.8.4 Event Log...................................................................................................................... 55

2.8.5 System Services............................................................................................................. 58

2.8.6 Additional Security Settings ............................................................................................ 91

2.8.7 Additional Security Settings (Manual Hardening Procedures) ............................................ 107

2.9 Hardening File Servers....................................................................................................... 111

2.9.1 Audit Policy Settings .................................................................................................... 112

2.9.2 2.9.2 User Rights Assignments ..................................................................................... 112

2.9.3 Security Options.......................................................................................................... 113

2.9.4 Event Log Settings........................................................................................................ 117

2.9.5 System Services........................................................................................................... 117

2.9.6 Additional Security Settings .......................................................................................... 125

2.9.7 HP NAS Specific Security Settings ................................................................................. 128

2.10 Hardening Print Servers .................................................................................................. 130

2.10.1 Audit Policy Settings ................................................................................................. 130

2.10.2 User Rights Assignments ............................................................................................ 130

2.10.3 Security Options....................................................................................................... 131

2.10.4 Event Log Settings..................................................................................................... 131

2.10.5 System Services........................................................................................................ 131

2.10.6 Additional Security Settings ....................................................................................... 132

2.10.7 HP NAS Specific Security Settings .............................................................................. 134

2.11 Hardening IIS Servers ..................................................................................................... 135

2.11.1 Audit Policy Settings ................................................................................................. 135

2.11.2 User Rights Assignments ............................................................................................ 135

2.11.3 Security Options....................................................................................................... 136

2.11.4 Event Log Settings..................................................................................................... 136

2.11.5 System Services........................................................................................................ 136

2.11.6 Additional Security Settings ....................................................................................... 139

2.11.7 HP NAS Specific Security Settings .............................................................................. 148

3 C2 / CC Security Compliancy ................................................................................................... 148

3.1 Security Policy Modifications .............................................................................................. 149

3.2 Registry Modifications........................................................................................................ 153

4 E3/F-C2 Security Compliancy.................................................................................................... 156

5 For more information ................................................................................................................ 156

1 Introduction

This document provides detailed steps and information on how customers can modify and integrate their HP Windows StorageServer 2003 NAS products into their existing NSA or C2 / CC v2.1security compliant environments. HP Windows StorageServer 2003 NAS NSA security compliancy are based on Microsoft’s “Windows Server 2003 Security Guide: Patterns and Practices” security paper at

4D89-B655-521EA6C7B4DB&displaylang=en which is recommended by National Security Agency (NSA)

of the United States to meet NSA security compliancy. Similarly, HP Windows StorageServer 2003 NAS C2 /CC v2.1 (ISO/ IEC15408) security compliancy is based on the US Department of Defense (DoD) “Trusted Computer System Evaluation Criteria (TCSEC)” security paper, a.k.a. the “Orange book”, at Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS) and the Common Criteria Recognition Arrangement (CCRA) documents located at

scheme/defining-ccevs.html. All E3/F-C2 system modifications within this document are based upon the

Information Technology Evaluation Manual (ITSEM) at Information Technology Security Evaluation Criteria (ITSEC) security requirements within the United Kingdom, Germany, France, and the Netherlands.

http://www.fas.org/irp/nsa/rainbow/tg003.htm and on the National Information Assurance

1.1 NSA Security Compliancy Overview

This document mainly focuses on NAS system modifications needed to meet NSA security compliancy. To meet NSA security requirements, the NAS system’s network infrastructure must be NSA security compliant as well. As such, the following modifications are required for full NSA security compliancy:

http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-

http://www.niap.nist.gov/cc-

http://www.boran.com/security/itsem.html to meet

• Hardening the Domain Infrastructure

• Creating a NSA Security Compliant Member Server Baseline Policy (MSBP)

• Hardening File Servers

• Hardening Print Servers

• Hardening IIS Servers

Depending upon the NAS appliance’s server roles, administrators may need to consolidate the security lockdown information within the later sections. For example, administrators who have NAS appliances that function as file servers, and IIS servers but not print servers need to only merge the security modifications for file and IIS server roles.

All NSA security information and recommendations within this guide are either summaries or direct content quotes from Microsoft’s “Windows Server 2003 Security Guide: Patterns and Practices” security paper at

521EA6C7B4DB&displaylang=en and from Microsoft’s “Windows Solution for Security: Threats and

Countermeasures: Security Settings in Windows Server 2003 and Windows XP” at

http://www.microsoft.com/downloads/details.aspx?FamilyId=1B6ACF93-147A-4481-9346F93A4081EEA8&displaylang=en.

http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-B655-

1.2 C2/CC Security Compliancy Overview

This document also describes network and server system modification steps required for Administrators to meet C2 / CC v2.1(ISO/ IEC15408) security requirements. C2 security requirements are based upon the US Department of Defense (DoD) “Trusted Computer System Evaluation Criteria” security paper, a.k.a. the “Orange book”, at

http://www.fas.org/irp/nsa/rainbow/tg003.htm . The Common Criteria (CC) v2.1) security

requirements are updated version requirements of the C2 security requirements. CC security requirements listed below are based upon the National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS) secuirty documents located at

http://www.niap.nist.gov/cc-scheme/defining-ccevs.html. The CC modification steps described below

within Chapter 3, “C2 / CC Security Compliancy”, should achieve an NIAP Evaluation Assurance Level (EAL) 4 augmented with ALC_FLR.3 and a TOE minimum function strength of SOF-medium.

1.3 E3/F-C2 Security Compliancy Overview

This document also depicts the modification steps necessary for Administrators to meet E3/F-C2 security requirements. All E3/F-C2 system modifications within this document are based upon the Information Technology Evaluation Manual (ITSEM) at Information Technology Security Evaluation Criteria (ITSEC) security requirements within the United Kingdom, Germany, France, and the Netherlands.

http://www.boran.com/security/itsem.html to meet

2 NSA Security Compliancy

This section provides detail steps in modifying the NAS system and other systems within the network to meet NSA security compliancy based on Microsoft’s “Windows Server 2003 Security Guide: Patterns and Practices”.

Not all network environments are the same. As such, NSA security requirements vary depending upon the network environment. These network infrastructures have been separated into 3 category levels:

Legacy Client

The Legacy Client level is specific to environments with legacy clients which includes Microsoft Windows® 98, Microsoft Windows NT® version 4.0 Workstation, Window 2000 Professional, and Windows XP Professional workstations. Since Windows NT 4.0 domain controllers do have certain required NSA security feature sets, this environment can only contain Windows 2000 or later domain controllers. Although there are no Windows NT 4.0 domain controllers in this environment, Windows NT member servers may exist. This environment is the lowest NSA lockdown level. Customers are recommended to start at this level first to meet minimal NSA security requirements and increase security level modifications as they see fit to meet their company security requirements.

Enterprise Client

This business environment includes clients running Windows 2000 Professional and Windows XP Professional. All domain controllers and member servers in this environment are Windows 2000 Server or later.

High Security

Moving from the Enterprise Client level to the High Security level requires conforming to stringent security policies for both clients and servers. This environment contains clients running Windows 2000 Professional and Windows XP Professional. Domain controllers and members servers are running Windows 2000 Server or later. In the High Security environment, concern about security is so great that significant loss of functionality and manageability is considered to be an acceptable tradeoff in order to achieve the highest level of security.

Figure 1. This figure shows the three layers of security and the clients supported in each.

Organizations that want to provide a phased approach to securing their environments may choose to start at the Legacy Client environment level and then gradually move to the higher security levels as their applications and client computers are upgraded and tested with tightened security settings.

2.1 Domain Model Design: Windows NT 4.0, Windows 2000, and Windows 2003

Before locking down the company’s domain infrastructure, one must understand the domain model differences between Windows NT 4.0, Windows 2000 Active Directory, and Windows 2003 Active Directory. The Windows NT 4.0 domain was a very good organizational and hierarchical model. However, it had poor communication feature sets with other domains. This issue prevented NT 4.0 to scale well within larger enterprise environments. As such, Windows 2000 Active Directory (AD) model was created. Windows 2000 AD enabled domains to communicate and trust each other in a peer-to-peer trust relationship. Domains could be grouped together in structures called forest which simplified and centralized domain management. Although Windows 2000 AD enabled the incorporation of various domains into a single tree, it opened up a security flaw in which all domains within a forest have full administrative access rights to all other domains within that forest. Similarly, Windows 2000 forests which have inter-forest trusts relationships with other forests have full administrative privileges within the other forests. The inter-domain trust relationship security flaw is the same within Windows 2003 AD. However, administrators within Windows 2003 can now control inter-forest relationships better using Windows 2003 cross forest authentications and cross forest

authorization feature sets. Companies implementing Windows 2003 AD must determine whether to create a single forest or multiple forest domain infrastructures depending upon manageability, security requirements between domains and forests, and administrative costs. A single forest is easier to manage and is ideal for workgroup and departmental environments. However, enterprise environments may require more administrative control between domains and forests and may need a multiple forest domain model even though such a model may increase administrative costs within each domain. Creating separate forests keep environments secure from rogue administrators within the company.

2.2 Time Synchronization

Administrators should also ensure that system time is accurate and that all servers in the organization are using the same time source. The Windows Server 2003 W32Time service provides time synchronization for Windows Server 2003 and Microsoft Windows XP-based computers running in an Active Directory domain. The W32Time service synchronizes the client clocks of Windows Server 2003-based computers with the domain controllers in a domain. This is necessary for the Kerberos v5 authentication protocol to work properly, as well as NTLMv2. To function correctly, a number of Windows Server family components rely on accurate and synchronized time. If the clocks are not synchronized on the clients, the Kerberos v5 authentication protocol might falsely interpret logon requests as intrusion attempts and deny access to users.

To ensure that the time is accurate, the PDC emulator in the forest root domain can be synchronized to an external NTP time server. However, doing so may result in a requirement to open ports on the firewall. NTP uses UDP port 123. Before doing this, weigh the benefits against the potential security risk of making these configuration changes. Complete the following task to synchronize Windows 2003, and Windows XP systems with an external time source:

1. Open a DOS Command Prompt.

2. Type the following, where PeerList is a comma-separated list of DNS names or Internet protocol (IP)

addresses for the desired time sources:

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

3. To update type:

w32tm /config /update

4. Check the Event Log. If the computer cannot reach the servers, the procedure fails and an entry is

written to the Event Log.

Computer systems running Windows 98, Windows NT 4.0, or Windows 2000 can synchronize their clocks using the following command in a logon script where <timecomputer> is a Windows 2000 or Windows 2003 domain controller on the network:

net time \\<timecomputer> /set /yes

Running this command will synchronize the time clocks in these computers with the time clocks in the other computers throughout the domain.

2.3 Organizational Unit (OU) and Group Policy Objects (GPOs) Design

An organizational unit (OU) is a container within a domain which contain specific access control list (ACL) permissions to devices and items that it can access and /or control. OUs provide administrators an easy way to group users and other security principals together while effectively creating segment administrative boundaries within their domains and forests. Administrators can then use group policy and delegate administration by applying specific settings, rights, and behaviors to all servers, devices, users, and groups within an OU. By using group policy rather than manual steps, it is simple to update a number of servers with any additional changes required in the future.

Figure 2. Group policies are accumulated and applied in the order shown in the illustration below.

As seen above, policies are applied first from the local machine policy level of the computer. After that, any GPOs are applied at the site level, and then at the domain level. If the server is nested in several OUs, GPOs existing at the highest level OU are applied first. The process of applying GPOs continues down the OU hierarchy. The final GPO to be applied is at the child OU level containing the server object. The order of precedence for processing Group Policy extends from the highest OU (farthest from the user or computer account) to the lowest OU (that actually contains the user or computer account).

The following rules must be observed when applying Group Policy:

• GPO application ordering for group policy levels must be set within multiple GPOs. If multiple policies specify the same option, the last one applied will take precedence.

• Configuring a Group Policy with the No Override option prevents other GPOs from overriding it.

Group Policies are implemented using security templates. These text based *.inf files can be accessed and applied using the Security Template snap-in found within Microsoft Management Console (MMC). All computers running Windows 2003 and Windows Storage Server 2003 store their security templates in the %SystemRoot%\security\template folder.

Administrators can implement NSA compliant security templates by downloading the Microsoft Windows Server 2003 Security Guide from

http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-B655521EA6C7B4DB&displaylang=en and extracting the security templates found within the guide.

Warning

: Although the security templates within the Microsoft guide does increase network security,

some applicational and operating system functionality may be lost due to its implementation. It is essential to thoroughly test these templates before deploying them in a production environment. Back up each domain controller and server before applying any new security settings. Ensure the system state is included in the backup to enable registry settings or Active Directory objects to be restored. Complete the following tasks to import the Microsoft Domain Policy security template into the domain server systems:

1. In Active Directory Users and Computers, right-click the Domain, and then select Properties.

2. On the Group Policy tab, click New to add a new GPO.

3. Depending upon the company’s network infrastructure, type Legacy Client - Domain Policy,

Enterprise Client - Domain Policy, or High Security Client - Domain Policy and then press Enter.

4. Right-click on the new domain policy and then select No Override.

5. Select on the new domain policy and then click Edit.

6. In the Group Policy window, click Computer Configuration\Windows Settings. Right-click Security Settings, and then select Import Policy.

7. In the Import Policy From dialog box, navigate to \Security Guide\Job Aids, and then double- click on the corresponding Legacy Client - Domain.inf, Enterprise Client - Domain.inf, or High

Security Client - Domain.inf.

8. Close the Group Policy that has been modified.

9. Close the Domain Properties window.

10. Force replication between the domain controllers so that all have the policy applied to them by typing the following command text within a DOS command prompt window:

gpupdate /Force.

For Windows 2000 Active Directory domains: Administrators should use the

/refreshpolicy

command-line from the DOS prompt instead to force domain policy replication.

secedit.exe

11. Verify in the Event Log that the Group Policy downloaded successfully and that the server can communicate with the other domain controllers in the domain.

Warning

: When creating the company’s domain policy, ensure that the No Override option is enabled to enforce this policy throughout the domain. This is the only Group Policy in which the No Override option must be enabled. Administrators should not enable this option in any of the other

group policies specified within this guide nor should they modify the Windows Server 2003 Default Domain Policy. To ensure that this new policy has precedence over the default policy, position it to have the highest priority among the GPO links.

Important

it is not uncommon to find environments where the root domain password policy is much stricter than any of the other domains. Care should also be taken to ensure that any other domains that will use this same policy have the same business requirements. Because the password policy can only be set at the domain level, there may be business or legal requirements that segment some users into a separate domain simply to enforce the use of a stricter password policy on that group.

Once the domain policy has been downloaded successfully to each of the servers, an event in the Application Event Log should appear specifying its completion in the form of the following Event ID number:

If the above message does not appear within a few minutes after applying the domain policy, rerun the Gpupdate.exe command-line tool to apply the domain policy, and then restart the server to force the domain policy download. By default, security settings are refreshed every 90 minutes on a workstation or server and every 5 minutes on a domain controller.

For Windows 2000 Active Directory domains: Administrators should use the

/refreshpolicy

Group Policy security settings are applied at several different levels within the network organizational hierarchy which have been broken down to the following three levels in the domain infrastructure:

• Domain Level-To address common security requirements, such as account and password policies

that must be enforced for all servers in the domain.

• Baseline Level-To address specific server security requirements that are common to all servers in the

domain infrastructure.

• Role Specific Level-To address security requirements for specific server roles. For example, the

security requirements for infrastructure servers differ from those for servers running HP NAS.

: This policy should be imported into any additional domains in the organization. However,

Type: Information Source ID: SceCli Event ID: 1704 Description: Security policy in the Group policy objects has been applied successfully. For more information, see Help and Support Center at

<http://go.microsoft.com/fwlink/events.asp>

secedit.exe

” command-line from the DOS prompt instead to force domain policy replication.

2.4 Domain Level: Hardening the Domain Infrastructure Password

Policy

The easiest and most important task in securing one’s network environment at the domain level is by implementing policies that force users to create complex passwords and requires them to change their passwords on a regular basis. Administrators should apply the following password guidelines:

• Avoid using words from a dictionary, common or clever misspellings of words, and foreign words.

• Avoid using incrementing passwords with a digit.

• Avoid preceding or appending passwords with a number.

• Avoid using passwords that others can easily guess.

• Avoid using words from popular culture.

• Avoid thinking of passwords as just full words.

• Enforce using passwords that require users to type with both hands on the keyboard.

• Enforce using uppercase and lowercase letters, numbers, and symbols in all passwords.

• Enforce using space characters and characters that can be produced only by pressing the Alt

key.

These guidelines should also be used for all service account passwords in the organization.

The following sections include the Password Policy recommendations for the three security environments defined in this guide. These values are set at:

Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy

Enforce Password History

Domain Member

Default

24 passwords

remembered

The Enforce password history setting determines the number of unique new passwords that have to be associated with a user account before it is possible to reuse an old password. The value must be set between 0 and 24 passwords. The default value for Windows Server 2003 is the maximum, 24 passwords. This policy setting enables administrators to enhance security by ensuring that old passwords are not continually reused. To maintain the effectiveness of the password history, also configure the Minimum password age to prevent passwords from being changed immediately. This combination makes it difficult for users to reuse passwords, either accidentally or on purpose. Since there are common vulnerabilities associated with reusing passwords, and specifying a low number for this setting will allow users to continually recycle a small number of passwords repeatedly, this setting recommendation is consistent across all environments defined within this guide. Also, there are no known issues related to setting this value at the maximum number for environments containing legacy clients.

Legacy Client Enterprise Client High Security Client

24 passwords

remembered

24 passwords

remembered

24 passwords

remembered

Maximum Password Usage

Domain Member

Default

42 days 42 days 42 days 42 days

The Maximum password age can be set so that passwords expire as often as necessary. The default values for this setting range from 1 to 999 days. This policy setting defines the period in which an attacker who has cracked a password may use it to access a computer on the network before the password expires. Changing passwords regularly is one way to prevent passwords from being compromised. The default value for this setting is 42 days. Most passwords can be cracked given enough time and computing power; the more frequently the password changes, the less time an attacker has to crack a password before a new one is created to invalidate his efforts at cracking the old password. However, the lower this value is set, the higher the potential for an increase in calls to help desk support. In order to balance the needs of security and usability in corporate environments, administrators can increase this setting in the Legacy Clients and Enterprise Clients. These recommended values increase password security by ensuring passwords are cycled periodically. In addition, the recommended values prevent users from having to change their password so often that they cannot remember what it is.

Legacy Client Enterprise Client High Security Client

Minimum Password Age

Domain Member

Legacy Client Enterprise Client High Security Client

Default

1 day 2 days 2 days 2 days

The Minimum password age setting determines the number of days that a password must be used before a user changes it. The range of values for this setting is between 0 and 999 days. Setting this to 0 allows users to change the password immediately. The default value for the setting is 1 day. The

Minimum password age setting must be less than the Maximum password age setting, unless the Maximum password age setting is set to 0, indicating that passwords will never expire. In this case,

the Minimum password age can be set to any value between 0 and 999. The Minimum password age must be greater than 0 for the Enforce password history to be effective. Without a minimum

password age, users can cycle through passwords repeatedly until they get to an old favorite. Change this setting from the default to 2 days because when the setting is used in conjunction with a similar low value in the Enforce password history setting, the restriction discourages users from recycling the same password again and again. If Minimum password age is left at 1 day, and the Enforce password history is set to 2 passwords, users would only have to wait 2 days before arriving at an old favorite password. This setting value ensures that users must wait a full two days to change passwords. The default setting does not follow this recommendation, so that an administrator can specify a password for a user and then require the user to change the administrator-defined password when the user logs on. If the password history is set to 0, the user does not have to choose a new password. For this reason, Enforce password history is set to 1 by default. It also prevents users from circumventing the Password history setting restriction by rapidly setting 24 new passwords.

Minimum Password Length

Domain Member

Legacy Client Enterprise Client High Security Client

Default

7 characters 8 characters 8 characters 12 characters

The Minimum password length setting ensures passwords have at least a specified number of characters. Long passwords, which are eight or more characters, are usually stronger than short ones. With this policy setting, users cannot use blank passwords, and they must create passwords that are a certain number of characters long. The default value for this setting is 7 characters, but an eightcharacter password is recommended as it is long enough to provide some level of security, but still short enough for users to easily remember. This setting will provide a great deal of defense against the commonly used dictionary and brute force attacks. A dictionary attack is a method of obtaining a password through trial and error in which an attacker uses all items in a word list. A brute force attack is a method of obtaining a password or other encrypted text by trying every possible value. The feasibility of a brute force password attack depends on the length of the password, the size of the potential character set, and the computational power available to the attacker. This guide recommends setting the value for password length in the High Security environment to 12 characters. Passwords are stored in the Security Accounts Manager (SAM) database or Active Directory after being passed through a one way hash algorithm. This type of algorithm is not reversible. Therefore, the only way to verify that a password is correct is to run it through the same one way hash algorithm and compare the results. Dictionary attacks run entire dictionaries through the encryption process, looking for matches. They are a simplistic, yet very effective, approach to finding out who has used common words like "password" or "guest" as their account passwords. If a password is seven characters or less, the second half of the LM Hash resolves to a specific value that can inform a cracker that the password is shorter than eight characters. Requiring passwords with at least eight characters strengthens even the weaker LMHash because the longer passwords require crackers to decrypt two portions of each password instead of only one. Since hackers can attack both halves of

the LM hash in parallel, the second half of the LM hash is only 1 character long; it will succumb to a rute-force attack in milliseconds. Also, each additional character in a password increases its complexity exponentially. For instance: A seven-digit password would have 267, or 1 x 107, possible combinations. A seven character alphabetic password with case sensitivity has 527 combinations. A seven haracter case-sensitive alphanumeric password without punctuation has 627combinations. At 1,000,000 attempts per second, it would only take 48 minutes to crack. An eight-character password has 268, or 2 x 1011, possible combinations. On the surface, this might seem a mindboggling number. However, at 1,000,000 attempts per second, a capability of many passwordcracking utilities, it would take only 59 hours to try all possible passwords. Remember these times will greatly increase with passwords that use ALT characters and other special keyboard characters, for example ! or @. For these reasons, using shorter passwords in place of longer ones is not recommended. However, requiring passwords that are too long may generate a high number of mistyped passwords, resulting in an increase in locked out accounts and help desk calls. Furthermore, requiring extremely long passwords can actually decrease the security of an organization because users may be more likely to write their passwords down in fear of forgetting them.

Password Must Meet Complexity Requirements

Domain Member

Legacy Client Enterprise Client High Security Client

Default

Enabled Enabled Enabled Enabled

The Password must meet complexity requirements policy option checks all new passwords to ensure that they meet basic requirements for strong passwords. Complexity requirements are enforced when passwords are created. The Windows Server 2003 policy rules cannot be directly modified. However, a new version of the passfilt.dll file can be applied with a different set of rules. For the source code for passfilt.dll, see the Microsoft Knowledge Base article 151082 at

http://support.microsoft.com/default.aspx?kbid=151082 labelled "HOW TO: Password Change Filtering &

Notification in Windows NT." A password of 20 or more characters can actually be set so that it is easier for a user to remember and be more secure than an eight-character password. The following 27-character password: I love cheap tacos for $.99, for example. This type of password, really a pass-phrase, might be simpler for a user to remember than a shorter password such as P@55w0rd. This recommended value, combined with a Minimum password length set to 8, includes upper and lowercase letters and numbers in the keyspace, which increases it from 26 to 62 characters. An eight-

character password then has 2.18 x 10

possible combinations. At 1,000,000 attempts per second, it would take 6.9 years to cycle through all possible permutations. Using these settings in conjunction makes it very difficult to mount a brute force attack. For these reasons, this is the recommendation the three environments defined in this guide.

Store Password Using Reversible Encryption

Domain Member

Default

Disabled Disabled Disabled Disabled

The security setting for Store password using reversible encryption determines whether the operating system stores passwords using reversible encryption or not. This policy supports applications using protocols requiring the user’s password for authentication purposes. Passwords stored using reversible encryption can be retrieved more easily than passwords stored without this option, increasing vulnerability. For this reason, never enable this policy unless application requirements outweigh the need to protect password information. Challenge-Handshake Authentication Protocol (CHAP) through remote access or IAS and Digest Authentication in IIS both require this policy.

Legacy Client Enterprise Client High Security Client

2.5 Domain Level: Hardening the Domain Infrastructure Account

Lockout Policy

The Account lockout policy is a Windows Server 2003 security feature that locks a user account after a number of failed logon attempts occur within a specified time period. The number of attempts allowed and the time period are based on the values configured for the security policy lockout settings. A user cannot log on to a locked account. Windows Server 2003 tracks logon attempts, and the server software can be configured to respond to this type of potential attack by disabling the account for a preset number of failed logins. These security policy settings help prevent attackers from guessing user passwords, and they decrease the likelihood of successful attacks on the network. The values in the following sections can be configured in the Domain Group Policy at the following location:

Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy

Account Lockout Duration

Domain Member

Default

Not defined 30 minutes 30 minutes 15 minutes

The Account lockout duration setting determines the length of time before an account is unlocked and a user can try to log on again. The setting does this by specifying the number of minutes a locked out account will remain unavailable. Setting the value for the Account lockout duration setting to 0, keeps the accounts locked out until an administrator unlocks them. The Windows Server 2003 default value for this setting is Not Defined. While configuring the value for this setting to never automatically unlock may seem like a good idea, doing so may increase the number of calls the company help desk receives to unlock accounts that were locked by mistake. Setting the value for this setting to 30 minutes for the Legacy and Enterprise Client environments and 15 minutes for High Security level decreases the amount of operation overhead during a denial of service (DoS) attack. In a DoS attack, the attacker maliciously performs a number of failed logon attempts on all users in the organization, locking out their accounts. This setting value also gives locked out users the chance to log on again in 30 minutes, a period of time they are more likely to accept without resorting to the help desk. This guide recommends setting the value to 15 minutes in the High Security environment.

Legacy Client Enterprise Client High Security Client

Domain Member

Default

Account Lockout Threshold

Legacy Client Enterprise Client High Security Client

0 invalid login attempts 50 invalid login

attempts

50 invalid login

attempts

10 invalid login

attempts

The Account lockout threshold setting determines the number of attempts that a user can make to log on to an account before it is locked. Authorized users can lock themselves out of an account by incorrectly entering their password, or by changing their password on one computer while logged on to another computer. The computer with the incorrect password may continuously try to authenticate the user, and because the password it is using to authenticate is incorrect, the user account is eventually locked out. To avoid locking out authorized users, set the account lockout threshold to a high number. Because vulnerabilities can exist both for when the value for this setting is configured and when and it is not, distinct countermeasures for each of these possibilities are defined. Company organizations should weigh the choice between the two based on the identified threats and the risks they are trying to mitigate.

• To prevent account lock outs, set the value for Account lockout threshold setting to 0. Setting the Account Lockout Threshold setting to 0 helps reduce help desk calls because users can not

accidentally lock themselves out of their accounts and it will prevent a DoS attack aimed at intentionally locking out accounts within the company. Because it will not prevent a brute force attack, choose this setting only if both of the following criteria are explicitly met:

o The password policy forces all users to have complex passwords made up of eight or

more characters.

o A robust auditing mechanism is in place to alert administrators when a series of

account lockouts are occurring in the environment. For example, the auditing solution should monitor for security event 539 which is, "Logon failure.The account was locked out at the time the logon attempt was made". This event means that the account was locked out at the time the logon attempt threshold was made. However, event 539 only shows an account lockout, not a failed password attempt. Therefore, administrators should also monitor for a series of bad password attempts.

• If these criteria are not met, the second option is to configure the Account lockout threshold setting to a high enough value to provide users with the ability to accidentally mistype their password several times without locking themselves out of their accounts, while ensuring that a brute force password attack will still lock out the account. In this case, setting the invalid logon attempts to a high number such as 50 ensures adequate security and acceptable usability. This setting value will prevent accidental account lockouts and reduce help desk calls, but will not prevent a DoS attack as mentioned above. This guide recommends setting the value to 10 invalid login attempts in the High Security environment.

Reset Account Lockout Counter After

Domain Member

Default

Not Defined 30 minutes 30 minutes 15 minutes

The Reset account lockout counter after setting determines the length of time before the Account lockout threshold resets to 0 and the account is unlocked. If the Account lockout threshold setting is

defined, then the reset time must be less than or equal to the value for the Account lockout duration setting. In coordination with the other values configured as part of this guide, leaving this setting at its default value, or configuring the value at an interval that is too long, could make the network domain environment vulnerable to an account lockout DoS attack. Without a policy to reset the account lockout, administrators would have to manually unlock all accounts. Conversely, if there is a reasonable time value for this setting, users would be locked out for a set period until all of the accounts are unlocked automatically. The recommended setting value of 30 minutes defines a time period users are more likely to accept without resorting to the help desk. Leaving this setting at its default only opens the network domain up to an account lockout DoS. This guide recommends setting the value to 15 minutes in the High Security environment.

Legacy Client Enterprise Client High Security Client

2.6 Domain Level: Hardening the Domain Infrastructure Kerberos Policy

Kerberos policies are used for domain user accounts. These policies determine Kerberosv5 protocolrelated settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in the local computer policy. Reducing the lifetime of Kerberos tickets decreases the risk of an attacker stealing passwords and then impersonating legitimate user accounts. However, maintaining these policies increases the authorization overhead. In most environments the default values for these policies should not be changed. The Kerberos settings are include in the Default Domain Policy and enforced there.

2.7 Domain Level: Hardening the Domain Infrastructure Security Options

There are two policies in Security Options that behave like account policies and should be considered at the domain level. These security options can be configured within the Domain Group Policy at the following location:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Microsoft Network Server: Disconnect Clients When Logon Hours Expire

Domain Member

Default

Not defined Enabled Enabled Enabled

Legacy Client Enterprise Client High Security Client

The Microsoft network server: Disconnect clients when logon hours expire security setting determines whether to disconnect users who are connected to the local computer outside their user account’s valid logon hours. This setting affects the server message block (SMB) component. When this policy is enabled, it causes client sessions with the SMB service to be forcibly disconnected when the client’s logon hours expire. If this policy is disabled, an established client session is allowed to be maintained

after the client’s logon hours have expired. When enabling this setting, the Network security: Force logoff when logon hours expire setting should be enabled. If the company has configured logon hours for users, then it makes sense to enable this policy. Otherwise, users who are assumed to be unable to access network resources outside of their logon hours may actually be able to continue to use those resources with sessions that were established during allowed hours. If logon hours are not used, enabling this setting will have no impact. If logon hours are used, then existing user sessions will be forcibly terminated when their logon hours expire.

Network Access: Allow Anonymous SID/ NAME translation

Domain Member

Legacy Client Enterprise Client High Security Client

Default

Not defined Disabled Disabled Disabled

Important: For NAS environments that require anonymous multi-protocol communications to cross platform systems, this guide recommends setting this security option to Enabled.

The Network Access: Allow anonymous SID/NAME translation setting determines if an anonymous user can request the SID for another user. If this policy is enabled on a domain controller, a user who knows an administrator’s SID attributes could contact a computer that also has this policy enabled and use the SID to obtain the administrator’s name. That person could then use the account name to initiate a password guessing attack. Disabled is the default setting on member computers; therefore it will have no impact on them. However, the default setting for domain controllers is Enabled.

Warning

: Disabling this setting may cause legacy systems to be unable to communicate with

Windows Server 2003 based domains such as:

• Windows NT 4.0-based Remote Access Service servers.

• When a Web application on IIS is configured to allow basic authentication and at the same

time has Anonymous access disabled, the built-in Guest user account cannot access the Web application. Also, if the built-in Guest user account was renamed to another name, the new name cannot be used to access the Web application.

• Remote Access Service servers running on Windows 2000-based computers that are located in Windows NT 3.x domains or Windows NT 4.0 domains.

• Multi-protocol applications such as Microsoft Services For Unix (SFU) and Microsoft Services For Netware (SFN) which require anonymous access for client systems may not function.

Network Security: Force Logoff When Logon Hours Expire

Domain Member

Legacy Client Enterprise Client High Security Client

Default

Disabled Enabled Enabled Enabled

The Network Security: Force Logoff when Logon Hours expire setting determines whether to disconnect users who are connected to a local computer outside their user account’s valid logon hours. This setting affects the SMB component. Enabling this policy forcibly disconnects client sessions with the SMB server when the client’s logon hours expire and the user will be unable to log on to the system until his or her next scheduled access time. Disabling this policy maintains an established client session after the client’s logon hours expire. To affect domain accounts, this setting must be defined in the Default Domain Policy.

2.8 Baseline Level

The settings at the Member Server OU level define the common settings for all member servers in the domain. This is done by creating a GPO that is linked to the Member Server OU, known as a baseline policy. The GPO automates the process of configuring specific security settings on each server. Administrators should use the member server baseline policy (MSBP) security template supplied within the Microsoft “Windows Server 2003 Security Guide” that is most appropriate to their corresponding network environment. The following table displays the security template used within each appropriate network environment.

Baseline Security Template

Member Server

Default

None Legacy client-

The following settings are described as they appear in the user interface (UI) of the Security Configuration Editor (SCE) snap-in.

2.8.1 Audit Policy

Administrators should set up an audit policy. An audit policy determines the security events to report to the network administrators so that user or system activity in specified event categories is recorded. The administrator can monitor security-related activity, such as who accesses an object, if a user logs on to or off from a computer, or if changes are made to an auditing policy setting. Before implementing audit policies, one must decide which event categories need to be audited for the corporate environment. The auditing settings that an administrator chooses for the event categories define the corporate auditing policy. By defining audit settings for specific event categories, administrators can create an audit policy that suits the security needs of the organization. Audit policy values can be configured in the Domain Group Policy section of Windows Server 2003 at the following location:

Legacy Client Enterprise Client High Security Client

member server

baseline.inf

Enterprise client-

member server

baseline.inf

High Security-

Member server

baseline.inf

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy

Audit Account Logon Events

Member Server Default Legacy Client Enterprise Client High Security Client

Success Success Failure Success Failure Success Failure

The Audit account logon events setting determines whether to audit each instance of a user logging on to or off another computer that validates the account. Authenticating a domain user account on a domain controller generates an account logon event. The event is logged in the domain controller’s security log. Authenticating a local user on a local computer generates a logon event. The event is logged in the local security log. There are no Account logoff events logged. The following table includes some of the important security events that this setting logs in the Security Event Log.

Event ID Event Description

672 An authentication service (AS) ticket was successfully issued and validated.

673 A ticket granting service (TGS) ticket was granted. A TGS is a ticket issued by the

Kerberos v5 ticket-granting service TGS that allows a user to authenticate to a specific service in the domain.

674 A security principal renewed an AS ticket or TGS ticket.

675 Pre- authentication failed. This event is generated on a Key Distribution Center (KDC)

when a user types in an incorrect password.

676 Authentication ticket request failed. This event is not generated in Windows XP

Professional or in members of the Windows Server family.

677 A TGS ticket was not granted. This event is not generated in Windows XP Professional or

in the members of the Windows Server family.

678 An account was successfully mapped to a domain account.

681 Logon failure. A domain account logon was attempted. This event is not generated in

Windows XP Professional or in members of the Windows Server family.

682 A user has reconnected to a disconnected terminal server session.

683 A user disconnected a terminal server session without logging off.

The event IDs above can be useful when creating custom alerts to monitor any software suite, for example, Microsoft Operations Manager (MOM).

Audit Account Management

Member Server Default Legacy Client Enterprise Client High Security Client

No auditing Success Failure Success Failure Success Failure

The Audit account management setting determines whether to audit each account management event on a computer. Examples of account management events include:

• A user account or group is created, changed, or deleted.

• A user account is renamed, disabled, or enabled.

• A password is set or changed.

Organizations need to be able to determine who has created, modified, or deleted both domain and local accounts. Unauthorized changes could indicate mistaken changes made by an administrator who does not understand how to follow corporate policies or a deliberate attack. The following table includes some of the important security events that this setting records in the Security Event Log.

Event ID Event Description

624 A user account was created.

627 A user password was changed.

628 A user password was set.

630 A user account was deleted.

631 A global group was created.

632 A member was added to a global group.

633 A member was removed from a global group.

634 A global group was deleted.

635 A new local group was created.

636 A member was added to a local group.

637 A member was removed from a local group.

638 A local group was deleted.

639 A local group account was changed.

641 A global group account was changed.

642 A user account was changed.

643 A domain policy was modified.

644 A user account was automatically locked.

645 A computer account was created.

646 A computer account was changed.

647 A computer account was deleted.

648 A local security group with security disabled was created.

Note: SECURITY_DISABLED in the formal name means that this group cannot be used to grant permissions in access checks.

649 A local security group with security disabled was changed.

650 A member was added to a security-disabled local security group.

651 A member was removed from a security-disabled local security group.

652 A security-disabled local group was deleted.

653 A security-disabled global group was created.

654 A security-disabled global group was changed.

655 A member was added to a security-disabled global group.

656 A member was removed from a security-disabled global group.

657 A security-disabled global group was deleted.

658 A security-enabled universal group was created.

659 A security-enabled universal group was changed.

660 A member was added to a security-enabled universal group.

661 A member was removed from a security-enabled universal group.

662 A security-enabled universal group was deleted.

663 A security-disabled universal group was created.

664 A security-disabled universal group was changed.

665 A member was added to a security-disabled universal group.

666 A member was removed from a security-disabled universal group.

667 A security-disabled universal group was deleted.

668 A group type was changed.

684 The security descriptor of administrative group members was set.

Note: Every 60 minutes on a domain controller, a background thread searches all members of administrative groups (such as domain, enterprise, and schema administrators) and applies a fixed security descriptor on them. This event is logged.

685 Name of an account was changed.

The event IDs above can be useful when creating custom alerts to monitor any software suite, for example, MOM. Most operational management software can be customized with scripts in order to capture or flag events based on the event IDs above.

Audit Directory Service Access

Member Server Default Legacy Client Enterprise Client High Security Client

No auditing Success Failure Success Failure Success Failure

The Audit directory service access setting determines whether to audit the event of a user accessing a Microsoft Active Directory® directory service object that has its own system access control list (SACL) specified. Setting Audit directory service access to No Auditing makes it difficult or impossible to determine what Active Directory objects may have been compromised during a security incident. There will be no audit record evidence available for analysis after a security incident if the values for this setting are not set to Success and Failure. Configuring Audit directory service access to Success generates an audit entry each time that a user successfully accesses an Active Directory object with a specified SACL. Configuring this setting to Failure generates an audit entry each time that a user unsuccessfully attempts to access an Active Directory object with a specified SACL.

Event ID Event Description

566 A generic object operation took place.

Audit Logon Events

Member Server Default Legacy Client Enterprise Client High Security Client

Success Success Failure Success Failure Success Failure

The Audit logon events setting determines whether to audit each instance of a user logging on to or off of a computer. Records are generated from the Account logon events setting on domain controllers to monitor domain account activity and on local computers to monitor local account activity. Configuring the Audit logon events setting to No auditing makes it difficult or impossible to determine which user has either logged on or attempted to log on to computers in the enterprise. Enabling the Success value for the Auditing logon events setting on a domain member will generate an event each time that someone logs on to the system regardless of where the accounts reside on the system. If the user logs on to a local account, and the Audit account logon events setting is Enabled, the user logon will generate two events. There will be no audit record evidence available for analysis after a security incident takes place if the values for this setting are not configured to Success and Failure for all three security environments defined in this guide.

Event ID Audit Logon Events

528 A user successfully logged on to a computer.

529 Logon failure. A logon attempt was made with an unknown user name or a known user

name with a bad password.

530 Logon failure. A logon attempt was made outside the allowed time.

531 Logon failure. A logon attempt was made using a disabled account.

532 Logon failure. A logon attempt was made using an expired account.

533 Logon failure. A logon attempt was made by a user who is not allowed to log on at the

specified computer.

534 Logon failure. The user attempted to log on with a password type that is not allowed.

535 Logon failure. The password for the specified account has expired.

536 Logon failure. The Net Logon service is not active.

537 Logon failure. The logon attempt failed for other reasons.

Note: In some cases, the reason for the logon failure may not be known.

538 The logoff process was completed for a user.

539 Logon failure. The account was locked out at the time the logon attempt was made.

540 A user successfully logged on to a network.

541 Main mode Internet Key Exchange (IKE) authentication was completed between the local

computer and the listed peer identity (establishing a security association), or quick mode has established a data channel.

542 A data channel was terminated.

543 Main mode was terminated.

Note: This might occur as a result of the time limit on the security association expiring (the default is eight hours), policy changes, or peer termination.

544 Main mode authentication failed because the peer did not provide a valid certificate or

the signature was not validated.

545 Main mode authentication failed because of a Kerberos failure or a password that is not

valid.

546 IKE security association establishment failed because the peer sent a proposal that is not

valid. A packet was received that contained data that is not valid.

547 A failure occurred during an IKE handshake.

548 Logon failure. The security identifier (SID) from a trusted domain does not match the

account domain SID of the client.

549 Logon failure. All SIDs corresponding to untrusted namespaces were filtered out during an

authentication across forests.

550 Notification message that could indicate a possible denial-of-service (DoS) attack.

551 A user initiated the logoff process.

552 A user successfully logged on to a computer using explicit credentials while already

logged on as a different user.

682 A user has reconnected to a disconnected terminal server session.

683 A user disconnected a terminal server session without logging off.

Note: This event is generated when a user is connected to a terminal server session over the network. It appears on the terminal server.

Audit Object Access

Member Server Default Legacy Client Enterprise Client High Security Client

No Auditing Success Failure Success Failure Success Failure

By itself, this setting will not cause any events to be audited. The Audit object access setting determines whether to audit the event of a user accessing an object-for example, a file, folder, registry key, printer, and so forth- that has a specified SACL. A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces of information:

• The security principal (user, computer, or group) to be audited.

• The specific access type to be audited, called an access mask.

• A flag to indicate whether to audit failed access events, successful access events, or both.

Configuring this setting to Success generates an audit entry each time that a user successfully accesses an object with a specified SACL. Configuring this setting to Failure generates an audit entry each time that a user unsuccessfully attempts to access an object with a specified SACL. Corporations should define only the actions they want enabled when configuring SACLs. For example, administrators may want to enable the Write and Append Data auditing setting on executable files to track the replacement or changes to those files, which computer viruses, worms, and Trojan horses will commonly cause. Similarly, administrators might want to track changes to or even the reading of sensitive documents. Therefore, this guide recommends enabling both the Success and Failure auditing values for this setting in all three environments defined in this guide.

Event ID Event Description

560 Access was granted to an already existing object.

562 A handle to an object was closed.

563 An attempt was made to open an object with the intent to delete it. Note: This is used by

file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile().

564 A protected object was deleted.

565 Access was granted to an already existing object type.

567 A permission associated with a handle was used. Note: A handle is created with certain

granted permissions (Read, Write, and so on). When the handle is used, up to one audit is generated for each of the permissions that were used.

568 An attempt was made to create a hard link to a file that is being audited.

569 The resource manager in Authorization Manager attempted to create a client context.

570 A client attempted to access an object. Note: An event will be generated for every

attempted operation on the object.

571 The client context was deleted by the Authorization Manager application.

572 The Administrator Manager initialized the application.

772 The Certificate Manager denied a pending certificate request.

773 Certificate Services received a resubmitted certificate request.

774 Certificate Services revoked a certificate.

775 Certificate Services received a request to publish the certificate revocation list (CRL).

776 Certificate Services published the CRL.

777 A certificate request extension was made.

778 One or more certificate request attributes changed.

779 Certificate Services received a request to shut down.

780 Certificate Services backup started.

781 Certificate Services backup completed.

782 Certificate Services restore started.

783 Certificate Services restore completed.

784 Certificate Services started.

785 Certificate Services stopped.

786 The security permissions for Certificate Services changed.

787 Certificate Services retrieved an archived key.

788 Certificate Services imported a certificate into its database.

789 The audit filter for Certificate Services changed.

790 Certificate Services received a certificate request.

791 Certificate Services approved a certificate request and issued a certificate.

792 Certificate Services denied a certificate request.

793 Certificate Services set the status of a certificate request to pending.

794 The certificate manager settings for Certificate Services changed.

795 A configuration entry changed in Certificate Services.

796 A property of Certificate Services changed.

797 Certificate Services archived a key.

798 Certificate Services imported and archived a key.

799 Certificate Services published the certificate authority (CA) certificate to Active Directory.

800 One or more rows have been deleted from the certificate database.

801 Role separation enabled.

Audit Policy Change

Member Server Default Legacy Client Enterprise Client High Security Client

No Auditing Success Success Success

The Audit policy change setting determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies. This includes making changes to the audit policy itself. Configuring this setting to Success generates an audit entry for each successful change to user rights assignment policies, audit policies, or trust policies. Configuring this setting to Failure generates an audit entry for each failed change to user rights assignment policies, audit policies, or trust policies. The recommended settings would let administrators see any account privileges that an attacker attempts to. Policy change auditing also includes making changes to the audit policy itself as well as to trust relationships.

: This guide recommends configuring the value for this setting to Success only because including

Note

the setting value for Failure will not provide meaningful access information. Currently, setting this value to Failure does not capture meaningful events.

Event ID Event Description

608 A user right was assigned.

609 A user right was removed.

610 A trust relationship with another domain was created.

611 A trust relationship with another domain was removed.

612 An audit policy was changed.

613 An Internet Protocol security (IPSec) policy agent started.

614 An IPSec policy agent was disabled.

615 An IPSec policy agent changed.

616 An IPSec policy agent encountered a potentially serious failure.

617 A Kerberos version 5 policy changed.

618 Encrypted Data Recovery policy changed.

620 A trust relationship with another domain was modified.

621 System access was granted to an account.

622 System access was removed from an account.

623 Auditing policy was set on a per-user basis

625 Auditing policy was refreshed on a per-user basis.

768 A collision was detected between a namespace element in one forest and a

namespace element in another forest. Note: When a namespace element in one forest overlaps a namespace element in another forest, it can lead to ambiguity in resolving a name belonging to one of the namespace elements. This overlap is also called a collision. Not all parameters are valid for each entry type. For example, fields such as DNS name, NetBIOS name, and SID are not valid for an entry of type ’TopLevelName.’

769 Trusted forest information was added.

Note: This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated for each added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages are assigned a single unique identifier called an operation ID. This allows administrators to determine if the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type “TopLevelName.”

770 Trusted forest information was deleted.

Note: See event description for event 769.

771 Trusted forest information was modified.

Note: See event description for event 769.

805 The event log service read the security log configuration for a session.

Audit Privilege Use

Member Server Default Legacy Client Enterprise Client High Security Client

No Auditing No Auditing Failure Success Failure

The Audit privilege use setting determines whether to audit each instance of a user exercising a user right. Configuring this value to Success generates an audit entry each time that a user right is exercised successfully. Configuring this value to Failure generates an audit entry each time that a user right is exercised unsuccessfully. Audits are not generated when the following user rights are exercised, even if the Audit privilege use settings is configured to Success or Failure. This is because auditing these user rights generates many events in the security log, which may constrain the performance of the NAS and other server systems. To audit the following excluded rights, administrators must enable the Audit: Audit the use of Backup and Restore privilege security option in Group Policy:

• Bypass traverse checking

• Debug programs

• Create a token object

• Replace process level token

• Generate security audits

• Back up files and directories

• Restore files and directories

Warning

reason, each security environment defined in this guide has unique recommendations for these settings. Failed use of a user right is an indicator of a general network problem and often can be a sign of an attempted security breach. Corporations should set the Audit privilege use setting to Enable only if there is a specific business reason to do so.

Event ID Event Description

576 Specified privileges were added to a user’s access token. Note: This event is generated

577 A user attempted to perform a privileged system service operation.

578 Privileges were used on an already open handle to a protected object.

: Enabling privilege auditing generates a very large number of event records. For this

when the user logs on.

Audit Process Tracking

Member Server Default Legacy Client Enterprise Client High Security Client

No Auditing No Auditing No Auditing No Auditing

The Audit process tracking setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access. Configuring this setting to Success generates an audit entry each time the process being tracked succeeds. Configuring this setting to Failure generates an audit entry each time the process being tracked fails. Enabling Audit process tracking will generate a large number of events, so typically it is set to No Auditing. However, these settings can provide a great benefit during an incident response from the detailed log of the processes started and the time when they were launched.

Event ID Event Description

592 A new process was created.

593 A process exited.

594 A handle to an object was duplicated.

595 Indirect access to an object was obtained.

596 A data protection master key was backed up.

Note: The master key is used by the CryptProtectData and CryptUnprotectData routines, and Encrypting File System (EFS). The master key is backed up each time a new one is created. (The default setting is 90 days.) The key is usually backed up by a domain controller.

597 A data protection master key was recovered from a recovery server.

598 Auditable data was protected.

599 Auditable data was unprotected.

600 A process was assigned a primary token.

601 A user attempted to install a service.

602 A scheduler job was created.

Audit System Events

Member Server Default Legacy Client Enterprise Client High Security Client

No Auditing Success Success Success

The Audit system events setting determines whether to audit when a user restarts or shuts down a computer or when an event occurs that affects either the system security or the security log. Configuring this setting to Success generates an audit entry when a system event is executed successfully. Configuring this setting to Failure generates an audit entry when a system event is attempted unsuccessfully. The table below includes some of the most useful successful events for this category.

Event ID Event Description

512 Windows is starting up.

513 Windows is shutting down.

514 An authentication package was loaded by the Local Security Authority.

515 A trusted logon process has registered with the Local Security Authority.

516 Internal resources allocated for the queuing of security event messages have been

exhausted, leading to the loss of some security event messages.

517 The audit log was cleared.

518 A notification package was loaded by the Security Accounts Manager.

519 A process is using an invalid local procedure call (LPC) port in an attempt to impersonate

a client and reply or read from or write to a client address space.

520 The system time was changed. Note: This audit normally appears twice.

2.8.2 User Rights Assignments

User Rights Assignments determine which users or groups have logon rights or privileges on the computers on the network. Logon rights and privileges govern the 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. User rights assignment settings can be configured in Windows Server 2003 in the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

The default User Rights Assignments are different between the various types of servers in the network. For example, Windows Server 2003 contains the following differences in User Rights Assignments with built-in groups between member servers and domain controllers. Similar built-in groups between member servers and domain controllers are not documented in the list that follows.

Member Servers

• Power Users

Power Users possess most administrative powers with some restrictions. Thus, Power Users can run legacy applications in addition to certified applications.

• Help Services Group

This is the group for the Help and Support Center. Support_388945a0 is a member of this group by default.

• Telnet Clients Members of this group have access to Telnet Server on the system.

Domain Controllers

• Server Operators Members of this group can administer domain servers.

• Terminal Server License Services Members of this group have access to Terminal Server License Servers on the system.

• Windows Authorization Access Group Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on

user objects.

The group Guests and the user accounts Guest and Support_388945a0 have unique SIDs between different domains. Therefore, this Group Policy for user right assignments may need to be modified on a system where only the specific target group exists. Alternatively, the policy templates can be edited individually to include the appropriate groups within the .inf files.

This section provides details on the prescribed user rights assignments for the three environments defined in this guide for the MSBP. For a summary of the prescribed settings in this section, see the Windows Server 2003 Security Guide Settings Excel spreadsheet. For information on the default settings and a detailed explanation of each of the settings discussed in this section, go and review Microsoft’s Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, available at:

http://go.microsoft.com/fwlink/?LinkId=15159.

: Throughout the following section, User Rights Assignments, "Not defined" means Administrators

Note

still have the privilege for every right not defined. Local administrators can make changes, but any domain-based Group Policy settings will override them the next time that the Group Policies are refreshed or reapplied.

Access This Computer From The Network Member Server Default Legacy Client Enterprise Client High Security Client

Administrators, Backup

Operators, Everyone,

Not Defined Not Defined Administrators,

Authenticated Users

Power Users, and Users

Important: Although in Windows Server 2003 permissions granted to the Everyone security group no

longer grant access to anonymous users, guest groups and accounts can still be granted access through the Everyone security group. For this reason, this guide recommends removing the Everyone security group from the Access this computer from the network user right in the High Security environment to further guard from attacks targeting guest access to the domain. However, administrators still need to check and verify that existing 3rd party applications within their network environment are functioning properly once this policy is set, especially with their NAS multi-protocol applications.

The Access this computer from the network user right determines which users and groups are allowed to connect to the computer over the network. This user right is required by a number of network protocols including server message block (SMB)-based protocols, network basic input/output system (NetBIOS), Common Internet File System (CIFS), Hypertext Transfer Protocol (HTTP).and Component Object Model Plus (COM+).

Act As Part Of The Operating System

Member Server Default Legacy Client Enterprise Client High Security Client

Not Defined Not Defined Not Defined Revoke all security

groups and accounts

Important: Since various 3rd party applications require and impersonate user and group accounts,

administrators should verify that these applications within their NAS system are still functioning properly once this policy is set.

The Act as part of the operating system user right allows a process to assume the identity of any user and thus gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this privilege. There are no security groups defined by default; therefore, this user right is sufficient for the Legacy Client and Enterprise Client environments. However, in the High Security environment, configure this setting to Revoke all security groups and

accounts.

Add Workstation To Domain

Member Server Default Legacy Client Enterprise Client High Security Client

Not Defined Not Defined Not Defined Administrators

The Add workstations to domain user right allows the user to add a computer to a specific domain. For the privilege to take effect, it must be assigned to the user as part of the Default Domain Controllers Policy for the domain. There are no security groups defined by default; therefore, this user right is sufficient for the Legacy Client and Enterprise Client environments. However, this setting is configured to grant only the Administrators group this user right in the High Security environment.

Adjust Memory Quotas For A Process

Member Server Default Legacy Client Enterprise Client High Security Client

Administrators,

NETWORK SERVICE,

LOCAL SERVICE

The Adjust memory quotas for a process user right allows a user to adjust the maximum memory that is available to a process. This privilege is useful for system tuning, but it can be abused. In the wrong hands, this user right can be used to launch a DoS attack. The default security groups for this user right are sufficient for the Legacy Client and Enterprise Client environments. However, this user right is configured to enforce Administrators, NETWORK SERVICE, LOCAL SERVICE value only in the High

Security environment.

Member Server Default Legacy Client Enterprise Client High Security Client

Administrators, Backup

Operators, Power

Users, and Users

Not Defined Not Defined Administrators,

NETWORK SERVICE,

LOCAL SERVICE

Allow Log On Locally

Administrators, Backup

Operators, Power

Users

Administrators, Backup

Operators, Power

Users

Administrators, Backup

Operators, Power

Users

The Allow log on locally user right determines which users can interactively log on to the specified computer. Logons initiated by pressing the CTRL+ALT+DEL key-combination on the keyboard require the user to have this logon right. Any account with this user right could be used to log on to the local console of the computer. Restricting this privilege to legitimate users who need to be able to log on to the system prevents unauthorized users from elevating their privileges or from introducing viruses into the computing environment.

Allow Log On Through Terminal Services

Member Server Default Legacy Client Enterprise Client High Security Client

Administrators and

Remote Desktop Users

The Allow log on through Terminal Services user right determines which users or groups have permission to log on as a Terminal Services client. The default security groups for this user right are sufficient for the Legacy Client and Enterprise Client environments. However, in the High Security environment, only Administrators should have the ability to log on as a Terminal Services client.

Member Server Default Legacy Client Enterprise Client High Security Client

Administrators and

Power Users

Administrators and

Remote Desktop Users

Change The System Time

Not Defined Not Defined Administrators

Administrators and

Remote Desktop Users

Administrators

The Change the system time user right determines which users and groups can change the time and date on the internal clock of the computer. Users with this user right can affect the appearance of event logs because event logs will reflect the new time, not the actual time that the events occurred. Limit the Change the system time privilege to users with a legitimate need to be able to change the time, such as members of the IT department. Discrepancies between the time on the local computer and on the domain controllers may cause problems for the Kerberos authentication protocol, which

+ 126 hidden pages

HP StorageWorks X5000, NSA Security Compliancy, C2 Security Compliancy, E3-FC2 Security Compliancy, CC Security Compliancy Technical Manual

Specifications and Main Features

Frequently Asked Questions

User Manual