Setting:	CIS Recommended	Further Explanation
1 Service Packs and Hotfixes
1.1 Major Service Pack and Hotfix Requirements
1.1.1 Current Service Pack Installed	SP1a for XP, SP4 for 2000
1.2 Minor Service Pack and Hotfix Requirements
1.2.1 Hotfixes recognized by HFNetChk	All Critical and Important Hotfixes
2 Auditing and Account Policies
2.1 Major Auditing and Account Policies Requirements
2.1.1 Minimum Password Length	8 Characters	In general, password length and password complexity requirements are used to protect against password guessing attacks. Password length significantly increases resistance to brute force attacks. A single extra character makes a large difference: even if passwords are case insensitive and alphanumeric, one extra password means the typical brute force attack will take 36 times as long (10 digits plus 26 letters) to complete. In addition to password guessing attacks, some legacy Microsoft protocols suffer from a limitation which makes an eight character password particularly important. These protocols effectively break down passwords into seven character “chunks”. This creates two significant vulnerabilities: • First, passwords with seven or fewer characters are quickly identified. • Second, since a fourteen character password effectively becomes two seven character passwords, it is actually only twice as secure as a seven character password. In order to protect against the first vulnerability, the general consensus requires passwords to be eight characters or more. Protection against the second vulnerability, however, can only be provided through the use of stronger authentication protocols. In particular, LAN Manager (LANMan) and NTLM authentication contains this limitation; however, NTLMv2 and Kerberos are not affected by this. See 3.2.1.47, which discuss how to require NTLMv2 or Kerberos authentication, and how to disable storage of LANMan password hashes.
2.1.2 Maximum Password Age	90 days	All passwords must be changed regularly to ensure they are known only by individuals authorized to use the account.
2.2 Minor Auditing and Account Policies Requirements
2.2.1 Audit Policy (minimums)		Audit Policy defines the significant events which a computer should log. The log entries, or events, perform two important roles: they provide a means for near-real-time monitoring of the system, and they allow investigation of actions which occurred in the past.
2.2.1.1 Audit Account Logon Events	Success and Failure	Audit logon events track all attempts to access the workstation. These may come from a local interactive logon, a network logon, a batch process, or even a service. Failed account logon may show a trend for password attacks; successful logon events are important to identify which user was logged on to the workstation at a given time.
2.2.1.2 Audit Account Management	Success and Failure	In order to track successful and failed attempts to create new users or groups, rename users or groups, enable or disable users, or change accounts’ passwords, enable auditing for Account Management events. Successful account management events are also generated when an account is locked out, so these events become important in determining the cause of an account lockout.
2.2.1.3 Audit Directory Service Access	<Not Defined>	No auditing of Directory Service Access is required on Windows XP Professional because Directory Service Access can only be audited on Windows 2000 (or later) domain controllers.
2.2.1.4 Audit Logon Events	Success and Failure	Logon Events will identify which accounts are accessing resources on the workstation. These events are generated only when local machine credentials are used. Even if a workstation is domain member, it is still possible to log on to the workstation using a local account.
2.2.1.5 Audit Object Access	Failure (minimum)	It is possible to track when specific users access specific files. This option only produces events when one or more objects are actively being audited. In order to track user access to specific files or directories, navigate to the file or folder, edit the security properties for that object, and enable auditing the object.
2.2.1.6 Audit Policy Change	Success (minimum)	When the “Audit Policy Change” option is set, changes to User Rights, Audit Policies, or Trust Policies will produce events in the Security Event Log.
2.2.1.7 Audit Privilege Use	Failure (minimum)	Auditing privilege use enables auditing for any operation that would require a user account to make use of extra privileges that it has already been assigned. If this is enabled, Events will be generated in the Security Event Log if a user or process attempts to bypass traverse checking, debug programs, create a token object, replace a process level token, or generate security audits.
2.2.1.8 Audit Process Tracking	<Not Defined>	When this option is enabled, an event is generated each time an application or a user starts, stops, or otherwise changes a process. This creates a very large event log very quickly, and the information is not normally exceptionally useful, unless you are tracking a very specific behavior. As such, auditing process tracking is not required, and is only recommended when absolutely necessary.
2.2.1.9 Audit System Events	Success (minimum)	Auditing System events is very important. System events include starting or shutting down the computer, full event logs, or other security related events that have impact across the entire system. Auditing of Success and Failure events should be enabled.
2.2.2 Account Policy
2.2.2.1 Minimum Password Age	1 day	The recommended password policy requires users to change passwords regularly, and requires the password to be different from those cached in history. When the minimum password age is set to 0, a user can change passwords repeatedly. It is possible for the user to continue changing passwords until yesterday’s password is flushed from the cache, and then re-use the old password. This activity is prevented by limiting password changes to once a day.
2.2.2.2 Maximum Password Age	90 days	See section 2.1.2
2.2.2.3 Minimum Password Length	8 characters	See section 2.1.1
2.2.2.4 Password Complexity	Enabled	Complex passwords further mitigate the risk of a brute force password attack by significantly increasing the set of all possible passwords. This is done by requiring passwords to include a combination of upper and lowercase letters, numbers and symbols (special characters) in the password.
2.2.2.5 Password History	24 passwords remembered	Passwords should be changed on a regular basis. By that same rule, users should not be permitted to use the same few passwords over and over again. The Enforce Password History setting determines how many previous passwords are stored to ensure that users do NOT cycle through regular passwords. The NSA requirement of 24 passwords remembered should be viable for public use as well.
2.2.2.6 Store Passwords using Reversible Encryption	Disabled	The Windows authentication model allows storage of a password hash rather than the actual password. A password hash can not be decoded to regain the original password. Rather, to authenticate, the password must be hashed exactly the same way and compared with the original stored hash. If the values match, the correct password was presented, and access is granted. In order to support some applications and their authentication, Microsoft permits the ability to store passwords using reversible encryption. If at all possible, this should be avoided. This option is disabled by default, and should remain so. Any application that requires reversible encryption for passwords is purposely putting systems at risk.
2.2.3 Account Lockout Policy		In order to protect against online password attacks, enforce an account lockout policy.
2.2.3.1 Account Lockout Duration	15 minutes	Once the criteria for a lockout are met, the account becomes locked. However, the account will automatically become re-enabled once again after the duration specified in the “Account Lockout Duration.” Specify 0 minutes to have the account lockout until an administrator manually resets the account.
2.2.3.2 Account Lockout Threshold	50 attempts	The user is given a number of attempts to enter the wrong password before their account becomes locked. The “Account Lockout Threshold” defines this limit.
2.2.3.3 Reset Account Lockout After	15 minutes	Following a bad logon, the system increments the count of invalid attempts for this account. This counter continues to increment until the lockout threshold is reached, or the counter is reset. The “Reset Account Lockout After” setting defines how often the counter is reset. This setting must be less than or equal to the “Account Lockout Duration”, 2.2.3.1.
2.2.4 Event Log Settings – Application, Security, and System Logs		All system events are collected into event logs. Two additional settings control system behavior when the event log is full. Essentially there are two possibilities: • Continue logging events as they come but risk overwriting important events • Stop logging events Obviously, it is preferable to continue logging events so that useful information is not lost. However, consider the attacker that kicks off a fake event generator as the last step of the attack (for example, it might try to log in with the guest account hundreds of times a second knowing the guest account is disabled). If all events continue to be logged, the events from the actual attack will soon be overwritten. In this case, it would be preferable to stop logging events when the log fills. The Audit policy setting for “Log Retention Method” provides control over how the system reacts to a full log: • Overwrite Events as Needed continues logging all events, overwriting older event whenever necessary. • Overwrite by Days allows overwriting some events, but not all. Events older that a specific number of days can be cleared out. Once all the older events are overwritten, no new events are logged. • Do not overwrite (Clear logs manually) prevents overwriting events, and new events are lost when the event log fills. The event log must be cleared manually by the system administrator or an automated log management application. Setting the “Log Retention Method” to “Overwrite by Days” enables the “Log Retention” option. This specifies the number of days of event logs the system will preserve. It may seem advisable to make the event logs as large as possible. However, due to constraints in how the operating system handles the logs, all three log files must be mapped to memory during normal system operation. An excessively large setting may cause unexpected results as the logs grow beyond the ability for the operating system to load the file in memory. Therefore, this guide recommended combined size of all three log files is limited to 120Mb, although a combined size of up to 300Mb seems to work well.
2.2.4.1 Application Log
2.2.4.1.1 Maximum Event Log Size	16 MB
2.2.4.1.2 Restrict Guest Access	Enabled
2.2.4.1.3 Log Retention Method	<Not Defined>
2.2.4.1.4 Log Retention	<Not Defined>
2.2.4.2 Security Log
2.2.4.2.1 Maximum Event Log Size	80 MB
2.2.4.2.2 Restrict Guest Access	Enabled
2.2.4.2.3 Log Retention Method	<Not Defined>
2.2.4.2.4 Log Retention	<Not Defined>
2.2.4.3 System Log
2.2.4.3.1 Maximum Event Log Size	16 MB
2.2.4.3.2 Restrict Guest Access	Enabled
2.2.4.3.3 Log Retention Method	<Not Defined>
2.2.4.3.4 Log Retention	<Not Defined>
3 Security Settings
3.1 Major Security Settings
3.1.1 Network Access: Allow Anonymous SID/Name Translation:	Disabled	Each object within Active Directory obtains a unique binary security identifier (SID). The operating system controls access to resources by their SID. SID formatting is well known, and some SIDs (e.g., local administrator and local guest) have properties which divulge the actual purpose of the account. Disable this option to prevent the null user from translating the binary SID into the actual account name.
3.1.2 Network Access: Do not allow Anonymous Enumeration of SAM Accounts	Enabled	By default, the null session login can list all the accounts within its domain. This presents a significant security risk, particularly if strong passwords are not required. Should an attacker be able to anonymously gather all available accounts, they can then try some basic guessing to quickly locate accounts with blank or very weak passwords.
3.1.3 Network Access: Do not allow Anonymous Enumeration of SAM Accounts and Shares	Enabled	See 3.1.2 above. In addition to protecting the list of user accounts, it also controls the list of network file shares established on the workstation. Documentation does not describe behavior if this setting conflicts with 3.1.2; however, if this setting is enabled, 3.1.2 should be enabled as well.
3.2 Minor Security Settings
3.2.1 Security Options
3.2.1.1 Accounts: Administrator Account Status	<Not Defined>	Each Windows XP installation creates an “Administrator” account that has the highest access to the system. The account has the highest possible access and can bypass most security controls local to the machine; it is comparable to the “root” account in Unix. Many system maintenance features require use of the Administrator account. However, in some environments, the existence of this account can present a security risk. By setting the “Administrator Account Status” to disabled, the account becomes unavailable.
3.2.1.2 Accounts: Guest Account Status	Disabled	The Guest account can provide some regulation to unauthenticated users. Disabling this account will prevent unknown users being authenticated as Guests. This default installation disables this account, and it should remain disabled. is disabled by default, and should remain so.
3.2.1.3 Accounts: Limit local account use of blank passwords to console logon only	Enabled	In a console logon, the physically logs on to the device with the attached keyboard. Remote logons are performed across the network using various protocols such as telnet, FTP and remote desktop.
3.2.1.4 Accounts: Rename Administrator Account	<non-std>	See 3.2.1.1. Often disabling the Administrator account is not practical. However, simply knowing the name of an account on a machine can be valuable information to an attacker. In an attempt to hide the account, best practices recommend renaming the account to something unique for your implementation.
3.2.1.5 Accounts: Rename Guest Account	<non-std>	See 3.2.1.2. Similar to the Administrator account, the Guest account should be renamed even if it is disabled. The operating system places additional safeguards on the Guest account, and it is less of a target than the Administrator account, but it still deserves significant attention warrant changing the account name.
3.2.1.6 Audit: Audit the access of global system objects	<Not Defined>	Global system objects typically only provide interesting audit information to developers. Some examples of these kernel objects include mutexes, semaphores and DOS devices. Normal system operation does not require auditing to this level of detail.
3.2.1.7 Audit: Audit the use of backup and restore privilege	<Not Defined>	When enabled, this setting will generate a log entry for every file which is backed up or restored using the “Backup or Restore” privilege. During normal operations, this will generate a large amount of event entries, and is typically not required.
3.2.1.8 Audit: Shut Down system immediately if unable to log	<Not Defined>	See 2.2.4. A system administrator may choose not to overwrite events when the event log is full. Assuming that logs are sized appropriately, routinely backed up and cleared, this could indicate a security incident. In the high security environment, the inability to log events may be just cause to halt the server.
3.2.1.9 Devices: Allow undock without having to log on	<Not Defined>	Some laptop docking stations have a hardware eject button that can actually be locked by software on the laptop. Setting this option to disabled provides greater security; however, without proper training a user may physically damage the hardware.
3.2.1.10 Devices: Allowed to format and eject removable media	Users	This setting governs the type of users which have authority to remove NTFS formatted media from the computer. The available choices (listed from most to least restrictive) are Administrators, Administrators and Power Users, or Administrators and Interactive Users.
3.2.1.11 Devices: Prevent users from installing printer drivers	<Not Defined>	Users typically need the ability to install and configure their own printers. However, printer driver installation loads code directly into the privileged space of the operating system kernel. The malicious user could choose to install an invalid or trojaned print driver to gain control on the system.
3.2.1.12 Devices: Restrict CD-ROM Access to Locally Logged-On User Only	<Not Defined>	With sufficient privileges, users can create network shares from any folder on a Windows XP workstation. This extends to sharing a CD-ROM drive externally. This setting would restrict use of the shared CD-ROM drive to the local interactive logon. Since different CDs can be inserted, the user may forget or be unaware that the information on the CD becomes remotely accessible. Also, unlike typical file shares, access control lists can not be placed on files and directories to control access and auditing.
3.2.1.13 Devices: Restrict Floppy Access to Locally Logged-On User Only	<Not Defined>	Similar to a CD-ROM drive (3.2.1.12 above), the floppy drive can be shared to network users. Again, the user may not remember that the information on all inserted floppies becomes exposed.
3.2.1.14 Devices: Unsigned Driver Installation Behavior	Warn, but allow	Drivers interact with the kernel and hardware at a low level; improper drivers can open the system to low level hardware and kernel problems. Additionally, trojaned drivers can open the system to compromise. Microsoft generally ships drivers with a digital signature, expressing that Microsoft itself has certified the drivers through their Windows Hardware Quality Lab. Unfortunately, not all drivers (even from Microsoft) have digital signatures.
3.2.1.15 Domain Controller: Allow Server Operators to Schedule Tasks	<Not Applicable>	This setting applies only to Windows 2000 Server Domain Controllers. It has no effect on Windows XP workstations.
3.2.1.16 Domain Controller: LDAP Server Signing Requirements	<Not Applicable>	This setting is not currently enforced, and must be set at the LDAP server (domain controller). This setting is disabled on Windows XP workstations, which has the same effect as “None”: data signing can optionally be negotiated by the client and server.
3.2.1.17 Domain Controller: Refuse machine account password changes	<Not Applicable>	This setting only applies to domain controllers. See 3.2.1.21 for the corresponding client workstation setting.
3.2.1.18 Domain Member: Digitally Encrypt or Sign Secure Channel Data (Always)	Enabled	With this setting enabled, all packets sent from the client will be signed. The client will also encrypt the packets if the server supports it. A signed packet can not be spoofed or tampered; however, the payload remains untouched and could possibly be deciphered should it be intercepted. Encrypted packets can only be decrypted by the server.
3.2.1.19 Domain Member: Digitally Encrypt Secure Channel Data (When Possible)	Enabled	See 3.2.1.18 above. This setting provides greater compatibility than requiring encryption or signing.
3.2.1.20 Domain Member: Digitally Sign Secure Channel Data (When Possible)	Enabled	See 3.2.1.18 above. This setting also provides compatibility with legacy equipment. It prevents replay and man-in-the middle attacks when domain controllers support signing. However, by itself, this setting will not protect against packet sniffing to gather potentially sensitive information.
3.2.1.21 Domain Member: Disable Machine Account Password Changes	Disabled	Like any other account, the computer account has a name and password. The computer manages its own password and changes it to a strong password regularly. This setting can be used to prevent the machine from managing its own password. Should the machine’s local copy of the password falls out of synch with the domain controller’s copy, the machine can not access domain resources, and the machine must be re-joined to the domain.
3.2.1.22 Domain Member: Maximum Machine Account Password Age	30 days	See 3.2.1.21 above. This setting determines how often the computer resets its password. Remember that machine password changes do not visibly impact the end user, and they should be consistent with corporate policy for account management.
3.2.1.23 Domain Member: Require Strong (Windows 2000 or later) Session Key	Enabled	This setting applies specifically to the NetLogon secure channel established between workstations and domain controllers (see 3.2.1.18). This setting only impacts workstations which have joined a domain.
3.2.1.24 Interactive Logon: Do Not Display Last User Name	Enabled	Anyone attempting to log into a computer may see the name of the last valid user who logged on to that system. This does not prevent displaying the currently logged on user when unlocking a workstation. This information may seem trivial, but it helps an attacker tie a workstation to a particular individual, or may help an attacker gain access to a stolen mobile device.
3.2.1.25 Interactive Logon: Do not require CTRL+ALT+DEL	Disabled (Disabled means you will have to press CTRL+ALT+DEL to login)	The Windows operating system treats the CTRL+ALT+Delete key different from any other. Operating system design prevents any application from intercepting and responding when these keys are pressed. When you type CTRL+ALT+Delete, you are guaranteed that the operating system authentication process will handle the request. With the CTRL+ALT+Delete requirement lifted, the user could actually be typing their password into a trojaned application, rather than the operating system authentication process. Remember, the trojaned application would not be able to respond had the user pressed CTRL+ALT+Delete. When a workstation does not require CTRL+ALT+Delete to log on, users will not see the dialog “Press CTRL+ALT+Delete To Log On.” Rather, the workstation simply presents the standard logon dialog.
3.2.1.26 Interactive Logon: Message Text for Users Attempting to Log On	<Custom, or DoJ Approved>	In general, legal requirements dictate that users must be notified of security practices when logging on to a system. The users should agree to acceptable usage policies, and be notified that the system may be monitored. The message is commonly referred to as a “logon banner”.
3.2.1.27 Interactive Logon: Message Title for Users Attempting to Log On	<Custom, or DoJ Approved>	The message title acts as part of the logon banner discussed above. The workstation places this text as the title for the logon banner window. The text should be either neutral or a warning. Avoid inviting titles such as “Welcome”.
3.2.1.28 Interactive Logon: Number of Previous Logons to Cache	1	When a workstation belongs to a domain, users can log on to it using domain credentials. The domain credentials can be cached in the local workstation’s Security Accounts Manager (SAM) database. On next logon, should no domain controller be available, the user can still log on locally by authenticating against the cached account information. When logging on using cached credentials, some account properties will not be enforced, since the domain controller maintains responsibility for enforcing account policy. The local SAM database does not “own” the account, so cached account passwords do not expire, and domain accounts can not be locked out when the domain is unavailable.
3.2.1.29 Interactive Logon: Prompt User to Change Password Before Expiration	14 days	Should a user’s password be near its expiration date, the logon process warns the user and asks if they would like to change the password. Once the password has expired, the user will be required to change the password to complete the logon. This setting governs the window of convenience between the time when the system offers the user to change the password, and the time when they are required to change the password.
3.2.1.30 Interactive Logon: Require Domain Controller authentication to unlock workstation	Enabled	Enabling this setting to protect against brute force password attacks through the screen saver. However, enabling it will hinder the user who locks and hibernates their workstation, and then attempts to resume when the domain controller is unavailable. Disabling this setting (or leaving it undefined) minimizes domain controller traffic.
3.2.1.31 Interactive Logon: Smart Card Removal Behavior	Lock Workstation	When users authenticate with smart cards, the system can be set to lock or log out the user when the smart card is removed. Any setting other than “No Action” is acceptable. In an environment that does not use Smart Cards, this setting has no effect.
3.2.1.32 Microsoft Network Client: Digitally sign communications (always)	Enabled	This setting applies specifically to communications using the Server Message Block (SMB) protocol. When enabled, the client will negotiate signed communications with any SMB server. If the server can not support SMB signing (typically servers prior to Windows 2000), communications will fail. When possible, digitally sign client communication to protect against man-in-the-middle attacks, as it supports mutual authentication and protection against packet tampering. SMB signing does not impact network bandwidth; however, CPU resources will be used in generating and verifying SMB signatures.
3.2.1.33 Microsoft Network Client: Digitally sign communications (if server agrees)	Enabled	This setting applies specifically to communications using the Server Message Block (SMB) protocol. When enabled, the client will negotiate signed communications with any server supporting SMB signing (typically Windows 2000 and later). Unsigned communications will still succeed with servers that do not support message signing.
3.2.1.34 Microsoft Network Client: Send Unencrypted Password to Connect to Third-Part SMB Server	Disabled	Would you like your Windows XP computer to send your password in clear text to another computer that requests authentication? The setting is disabled by default, and should remain so.
3.2.1.35 Microsoft Network Server: Amount of Idle Time Required Before Disconnecting Session	15 Minutes	This setting applies specifically to communications using the SMB protocol. When a client establishes a connection with an SMB server, they exchange credentials, perform authentication, and set aside resources to manage the connection. After a period of inactivity, the client or server may close the connection to conserve resources. When the client again attempts to use the SMB server, it reestablishes the connection without interaction with the user. The reconnection typically happens fast enough to hide the activity from the user.
3.2.1.36 Microsoft Network Server: Digitally sign communications (always)	Enabled	Similar to 3.2.1.32, the workstation may require all SMB traffic to be digitally signed. Workstations act as servers when remote devices connect to published shares; many workstation management systems also use SMB protocols.
3.2.1.37 Microsoft Network Server: Digitally sign communications (if client agrees)	Enabled	Similar to 3.2.1.33, the workstation should request signed communications wherever possible. This option is enabled by default, and should remain enabled.
3.2.1.38 Microsoft Network Server: Disconnect clients when logon hours expire	Enabled	This setting only applies to workstations joined to a domain, as logon hours can not be set for local accounts. Additionally, this applies only to network connections established with the SMB protocol.
3.2.1.39 Network Access: Do not allow storage of credentials or .NET passports for network authentication	Enabled	This setting controls behavior of the “Stored User Names and Passwords” feature of Windows XP. This feature stores NTLM, Kerberos, Passport and SSL authentication; it should not be confused with the Internet Explorer authentication cache, since it is managed separately. Some documents refer to this setting as “Network Access: Do not allow Stored User Names and Passwords to safe passwords or credentials for domain authentication”.
3.2.1.40 Network Access: Let Everyone permissions apply to anonymous users	Disabled	Many resources across the network are accessible to the “Everyone” group. This special group contains all accounts; however, it does not contain the anonymous user (null session, see section 3.1). Enabling this option adds the “null user” to the “Everyone” group, escalating privileges of this account. The “Everyone” group is assigned to many network resources by default.
3.2.1.41 Network Access: Named pipes that can be accessed anonymously	<None>	Named Pipes are communications channels between two processes. The process may or may not be located on the same computer, and communications are peer-to-peer rather than client-to-server. Each pipe is assigned an access control list. This setting defines which pipes can be accessed remotely without authentication, and should be left blank.
3.2.1.42 Network Access: Remotely accessible registry paths	<Not Defined>	This setting defines the registry paths which can be accessed from another computer. Remote registry access depends on the remote registry service and requires authentication.
3.2.1.43 Network Access: Shares that can be accessed anonymously	<None>	Access Control Lists restrict access to published network shares hosted by a workstation. Shares can be published to the “Everyone” group, but this does not include the unauthenticated null user. Adding specific shares to this list grants access to the unauthenticated user. Note that NTFS permissions on the share still apply.
3.2.1.44 Network Access: Sharing and security model for local accounts	Classic	Remote users often must present logon credentials to the workstation to gain access. Occasionally, they may present credentials for a local account on the workstation. In the “Classic” security model, even though a remote user is using local credentials, they still gain access based on restrictions for the local account. However, the “Guest Only” model remaps the remote user to the guest account, so they will only be able to access resources available to guests.
3.2.1.45 Network Security: Do not store LAN Manager password hash value on next password change	Enabled	The SAM database typically stores a LANManager (LM) hash of account passwords. The SAM database should be secure on the workstation; however, if it is captured, the LM hash can be retrieved. Many vulnerabilities exist with the LM authentication model, and brute force attacks usually succeed with ease. Removing the LM hash from the SAM database helps protect the local account passwords. However, most Windows 9x clients only support LM authentication.
3.2.1.46 Network Security: Force logoff when logon hours expire	Enabled	This setting is similar to 3.2.1.38, but reflects the client-side settings. This setting only applies to workstations joined to a domain, as logon hours can not be set for local accounts. The setting deals exclusively with connections using the SMB protocol, and not with the interactive logon session. Enabling this feature will disconnect all client connections when logon time limits are reached. By default, the workstation only enforces logon hours during session setup, and not afterwards.
3.2.1.47 Network Security: LAN Manager Authentication Level	Send NTLMv2, refuse LM	The default, and weakest option, is the first: send LM & NTLM responses. As a result, using NTLM is ineffective because both protocols are sent together. In order to take a much more effective stand to protect network authentication, set LAN Manager Authentication Level to “Send NTLMv2 response only\refuse LM & NTLM”. Enabling this setting may have adverse effects on your ability to communicate with other Windows machines unless the change is made network-wide. If you find that you are unable to require a certain level of LM Authentication, back down to “Send LM & NTLM – Use NTLMv2 session security if negotiated” and try your network authentication again. Communication with Windows 9x/Me machines requires the DSCLIENT.EXE utility from the Windows 2000 installation CD.
3.2.1.48 Network Security: LDAP client signing requirements	Require Signing	Similar to the SMB protocol, the LDAP protocol supports signing. LDAP, “Lightweight Directory Access Protocol,” provides one means for the client to talk to active directory. LDAP protocol is text-based, but supports authentication to gain access to sensitive sections of the directory. Require signing to provide the assurance of mutual authentication for this communications channel.
3.2.1.49 Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients	Require Message Integrity, Message Confidentiality, NTLMv2 Session Security, 128-bit Encryption	NTLM authentication can provide a security service to manage connection between various clients and servers, including through the Remote Procedure Call (RPC) service. Windows 2000 improved the security model for secure, authenticated client-server communications; this setting manages the new features for communications established by this workstation.
3.2.1.50 Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers	Require Message Integrity, Message Confidentiality, NTLMv2 Session Security, 128-bit Encryption	Similar to 3.2.1.49, this setting manages features for communication services provided by this workstation to other computers.
3.2.1.51 Recovery Console: Allow Automatic Administrative Logon	Disabled	If configured, a boot to the recovery console could result in automatic logon, and bypass the need for the password of the administrator account. Since this gives administrator access to anyone who can reboot the computer, the setting is generally disabled.
3.2.1.52 Recovery Console: Allow Floppy Copy and Access to All Drives and All Folders	<Not Defined>	By default, the Recovery Console only allows access to the root folder of each drive, and the operating system folder (typically C:\Windows). The console also prevents copying files from the hard drive onto removable media. Although this protection can be bypassed by enabling floppy copy and drive access, the setting is disabled by default and should remain disabled.
3.2.1.53 Shutdown: Allow System to be Shut Down Without Having to Log On	Disabled	Some systems run critical processes and should only be shut down by authorized users. Occasionally, special processes could be evoked during system startup, sometimes even trojaned processes. In environments where abnormal system reboots could cause problems, require a logon prior to reboot.
3.2.1.54 Shutdown: Clear Virtual Memory Pagefile	Enabled	Enabling this options provides greater security by erasing the data during normal operations; however, this may also significantly increase the time required to shut down the computer. When enabled, the hibernation file (hiberfil.sys) is also cleaned on shutdown.
3.2.1.55 System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing	<Not Defined>	FIPS stands for “Federal Information Processing Standards”. The National Institute of Standards and Technology (NIST) maintains the standards, available online at http://www.itl.nist.gov/fipspubs/index.htm. Although the operating system can support a variety of hashing and encryption algorithms, only the following are FIPS compliant:   • Secure Hash Algorithm (SHA-1) for hashing   • Triple Data Encryption Standard (DES) for encryption   • RSA for key exchange and authentication. Only these algorithms are used when the workstation requires FIPS compliant algorithms. With this setting enabled, the encrypting file system (EFS) will use triple DES rather than the default DESX. NOTE: Enabling the requirement for FIPS compliant system cryptography will limit the workstation’s ability to interact with SSL encrypted web sites that do not support these encryption mechanisms. This will likely have an effect on most non-IIS served web sites.
3.2.1.56 System objects: Default owner for objects created by members of the Administrators group	Object Creator	When an Administrator creates an object (file, directory, account, or any object which obtains and ACL from the operating system), an owner will be assigned. Normally, the account which created the object is assigned as the owner; however, changing this option allows assignment to the “Administrators Group” rather than an individual account.
3.2.1.57 System objects: Require case insensitivity for non-Windows subsystems	<Not Defined>	The Windows operating systems ignore case when accessing resources; for example, “C:\Windows”, “C:\WINDOWS” and “c:\windows” all refer to the same directory. However, the Windows kernel allows interfaces with other case-sensitive operating systems (e.g., Unix). Enabling this setting causes the interoperability features to be case-insensitive as well. This setting has no effect when the workstation communicates only with other Windows systems.
3.2.1.58 System objects: Strengthen default permissions of internal system objects	Enabled	This setting actually digs deep into the operating system behavior and should be left at the default setting (Enabled) unless explicitly required. “Internal system objects” are shared physical and logical resources such as semaphores and DOS device name; the objects all are created with access control lists (ACLs). When enabled, the ACL allows other non-administrative system processes to query internal system objects, but will not allow them to modify them.
3.2.2 Additional Registry Settings
3.2.2.1 Suppress Dr. Watson Crash Dumps: HKLM\Software\Microsoft\DrWatson\CreateCrashDump	(REG_DWORD) 0	Dr. Watson is one of Microsoft’s utilities that handles errors in applications. If an application produces an error that Dr. Watson can manage, it will dump the contents of memory for that application to a file for future analysis. In the process of writing the contents of memory to disk, it is entirely possible that password information could be written to disk as well, and later exploited. Set this value to zero to prevent Dr. Watson from writing crash dumps to disk.
3.2.2.2 Disable Automatic Execution of the System Debugger: HKLM\Software\Microsoft\Windows NT\CurrentVersion\AEDebug\Auto	(REG_DWORD) 0	If an application is executed in non-privileged memory, and the system debugger is started, it is possible for that application to execute code in privileged memory space. Set this value to zero to prevent the system debugger from executing automatically.
3.2.2.3 Disable autoplay from any disk type, regardless of application: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun	(REG_DWORD) 255	Although it is convenient for applications to automatically run when Windows Explorer opens up, it can also cause applications to be executed against the wishes of an administrative user, and exploiting that privilege. Set this value to 255 to prevent any type of drive from automatically launching an application from Windows Explorer.
3.2.2.4 Disable autoplay for current user: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\ NoDriveTypeAutoRun	(REG_DWORD) 255	Note: Due to the inability to manage registry entries for each local user via Security Templates, this setting is recommended, but not required or measured.
3.2.2.5 Disable autoplay for the default profile: HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun	(REG_DWORD) 255	Similar to the autoplay settings above, this enforces the policy for any new profiles created on the workstation.
3.2.2.6 Disable Automatic Logon: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon	(REG_DWORD) 0	Windows also has the ability to automatically log a user on every time that machine starts up. Some users may prefer this as a feature. Some server based applications may require that a user log in before they can execute, so they require this activity as well. The problem with this “feature” is that in order for it to work, it stores the username and password for that user in plaintext in the registry. Set this value to zero to prevent any user from automatically logging in when the computer starts up.
3.2.2.7 Disable automatic reboots after a Blue Screen of Death: HKLM\System\CurrentControlSet\Control\CrashControl\AutoReboot	(REG_DWORD) 0	If someone manages to get enough control of your computer that they can plant an application there, the next step is to force your computer to restart to register that app. One easy way to accomplish this task is to programmatically force an error that causes the computer to crash, or “Blue Screen” which will reboot the machine by default. Set this Value to zero to prevent this behavior from happening, and at least alert the user that something is wrong.
3.2.2.8 Disable CD Autorun: HKLM\System\CurrentControlSet\ Services\CDrom\Autorun (REG_DWORD)	(REG_DWORD) 0	If malicious software is written to a CD, it can be executed by Windows Explorer just by putting the CD in the drive. Set this value to zero to prevent any applications from automatically launching from the CD-ROM drive.
3.2.2.9 Remove administrative shares on workstation (Professional): HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\AutoShareWks	<Not Defined>	Every Windows NT/2000 computer automatically has “Administrative Shares” installed by default. These are restricted to use by Administrators, but they expose each volume root, and the %systemroot% folder to the network as Admin$, C$, etc. These make remote administration convenient, but they also present a risk if someone manages to guess the password to an administrative account. WARNING: If you use administrative shares on your network for remote backups, antivirus support, or general remote administration, this will break your applications. Please ask your software vendors to design around this requirement in future versions of their applications.
3.2.2.10 Protect against Computer Browser Spoofing Attacks: HKLM\System\CurrentControlSet\Services\MrxSmb\Parameters\RefuseReset	(REG_DWORD) 1	Although this standard advises end-users to shut down their Computer Browser service, it is also likely that not everyone will be able or willing to do so. This registry setting provides protection against a vulnerability that allows the Computer Browse to be shut down. Set this value, to protect against this specific vulnerability. If you are not running the Computer Browser service, this setting will have no effect. More information is available at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262694.
3.2.2.11 Protect against source-routing spoofing: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DisableIPSourceRouting	(REG_DWORD) 2	If a Windows computer has two valid networking devices installed, it can be configured to act as a router or a firewall, and pass network traffic from one interface to another. Whether this is the intended purpose or not, it can be done on any Windows computer. “Source Routing” traffic that passes through such a router can bypass certain routing rules by “spoofing” the device to think malicious network activity came from the protected side. Set this value to 2 in order to drop all source routed packets.
3.2.2.12 Protect the Default Gateway network setting: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\EnableDeadGWDetect	(REG_DWORD) 0	When one TCP/IP Default Gateway fails, it is possible to force one computer to use a second default gateway to complete the route path. In most cases, computers are not set up with multiple default gateways, relying on redundant routers instead. If an attacker can manipulate your default gateway, and this setting is not set to zero, he could route your network traffic to an alternate address. Set this value to zero to protect against this kind of attack.
3.2.2.13 Ensure ICMP Routing via shortest path first: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirect	(REG_DWORD) 0	In order to prevent network ICMP traffic from being redirected from one computer to another, set the EnableICMPRedirect value to zero. There is some confusion as to whether or not the value name is pluralized. For more information, please refer to the Microsoft article at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q293626.
3.2.2.14 Help protect against packet fragmentation: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery	(REG_DWORD) 0	When data is transferred across a network, the data is broken down into packets. These packets are not always a uniform size. When these packets are broken down into smaller sizes, they are supposed to be reassembled at the other end of a network route in the same order. This does not always go as planned, and can used in some network attacks. Set this value to 0 to force Windows to use a consistent 576 byte packet. More details are available at http://support.microsoft.com/?kbid=315669.
3.2.2.15 Manage Keep-alive times: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime	(REG_DWORD) 300000	The KeepAliveTime determines how often the network subsystem attempts to verify that a TCP session is still active. The setting of 300,000 works out to one request every five minutes.
3.2.2.16 Protect Against Malicious Name-Release Attacks: HKLM\System\CurrentControlSet\Services\Netbt\Parameters\NoNameReleaseOnDemand	(REG_DWORD) 1	By default, a computer running NetBIOS will release its name upon request. In order to protect against malicious name-release attacks, set this value to 1. Microsoft also references in at least one place that this is for Windows 2000 Service Pack 2 or greater.
3.2.2.17 Ensure Router Discovery is Disabled: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\PerformRouterDiscovery (REG_DWORD)	(REG_DWORD) 0	This setting prohibits the workstation from caching router advertisements. Since router advertisements propogate through UDP, they can easily be spoofed.
3.2.2.18 Protect against SYN Flood attacks: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\SynAttackProtect	(REG_DWORD) 2	One of the first methods of launching Denial of Service attacks was to send a flood of incomplete 3-way handshake requests. Each time the incomplete request was received by the target, a small portion of the target’s resources were set aside, waiting for the request to finish. When all of the resources were set aside, the target machine was no longer able to serve any more requests, and further service was denied. In order to prevent the success of this attack, set the SynAttackProtect value to 2, which allows the operating system to limit the amount of resources that are set aside until the 3-way handshake is completed. Setting SynAttackProtect to 1 provides minimal security, but for maximum protection, set it to 2. The next few settings also provide a measure of protection against Denial of Service or Distributed Denial of Service attacks.
3.2.2.19 SYN Attack protection – Manage TCP Maximum half-open sockets: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxHalfOpen	(REG_DWORD) 100	This value determines how many incomplete handshake requests the network will allow at one time. This provides protection if SynAttackProtect is set to 1. 100 is the default value on Windows XP Professional.
3.2.2.20 SYN Attack protection – Manage TCP Maximum half-open retired sockets: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxHalfOpenRetired (REG_DWORD)	(REG_DWORD) 80	This value indicates how many retransmitted SYN sessions are permitted. The Default value is 80 for Windows XP Professional.
3.2.2.21 Enable IPSec to protect Kerberos RSVP Traffic: HKLM\System\CurrentControlSet\Services\IPSEC\ NoDefaultExempt	(REG_DWORD) 1	When Kerberos authentication information is transferred between domain controllers, or between domain controllers and member servers or workstations, it is not secured by default. Even when IPSec is used to encrypt that traffic, the Kerberos information is considered “exempt”. Set this value to 1 to ensure that all traffic, including Kerberos information is protected by IPSec.
3.2.2.22 Hide workstation from Network Browser listing: HKLM\System\CurrentControlSet\Services\Lanmanserver\Parameters\Hidden	(REG_DWORD) 1	If the Computer Browser service is disabled, or if this computer is not part of a domain, this setting has no effect. Otherwise, it will prevent the computer from announcing itself to the browser services of other computers, and only act as a “listener” on domain browse lists.
3.2.2.23 Enable Safe DLL Search Mode: HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode	(REG_DWORD) 1	This setting modifies the way in which Windows locates driver files (.dlls). A value of 0 forces the operating system to search the current directory first; when set to 1, the system searches the windows system directory first
4 Additional Security Protection
4.1 Available Services (Permissions on services listed here: Administrators: Full Control; System: Read, Start, Stop, and Pause)
4.1.1 Alerter	Disabled	The alerter service is normally used to send messages between processes on one computer “alerting” the status of certain functions to the user’s console, including the execution of print jobs. It also works in conjunction with the Messenger service to send these same messages between computers on a network.
4.1.2 Automatic Updates	<Not Defined>	The Automatic Updates service was first published with Windows XP. It regularly checks the Microsoft web site in the background, and initiates the download of any new Critical Updates as they become available. It is designed to NOT use excessive network bandwidth. This service does not install anything itself, it makes updates ready to install.
4.1.3 Background Intelligent Transfer Service	<Not Defined>	The BITS service works in conjunction with the Automatic Updates service to download Critical Updates from Microsoft’s Internet site, and make them available for installation. The service runs in the background, and makes use of unused and available bandwidth.
4.1.4 Clipbook	Disabled	The Clipbook service is used to share clipboard information between computers on a network. In most cases, users don’t want to share that information with other computers.
4.1.5 Computer Browser	<Not Defined>	The Computer Browser (not to be confused with Internet browsers, such as Internet Explorer or Netscape) keeps track of the computers on a network within a domain. It allows users to “browse” through Network Neighborhood to find the shared resources they need without knowing the exact name of that resource. Unfortunately, it allows anyone to browse to those resources before checking any sort of authentication or authorization. Disabling this service will require users to know the resources they are looking for, by name, and may result in an increased number of help desk calls.
4.1.6 Fax Service	<Not Defined>	The fax service is used for the unattended reception of incoming faxes. It is not required for the sending, or manual reception of faxes. It does require that a computer be left running all the time, and have the modem set to auto-answer. Generally speaking, with the low cost of dedicated fax machines, the secure answer to most faxing needs would be to have a dedicated fax machine to receive faxes, while still using the computer to manually send faxes when appropriate.
4.1.7 FTP Publishing Service	Disabled	The FTP Publishing Service is part of the Internet Information Server suite of Internet applications. It is not installed by default. It is used for making files on your local machine available to other users on your network or the Internet. Generally speaking, workstations do not share files with other computers. This service should be disabled, or removed. If it is going to be installed, it should be properly maintained, which is a subject beyond the scope of this benchmark.
4.1.8 IIS Admin Service	Disabled	Also part of the IIS suite of services, the IIS Admin Service manages the other IIS services. If this service is not running, the other services that are part of the IIS suite will not function either. Disable this service. If possible, this should be removed from workstations.
4.1.9 Indexing Service	<Not Defined>	This service indexes files on the system in an attempt to improve search performance. However, the service may occasionally consume excessive resources when compared to its usefulness.
4.1.10 Messenger	Disabled	The Messenger service works in tandem with the Alerter service. It allows Alerter services of multiple computers to send alerts to each other over a network. Most users can live without the messenger and alerter services and still accomplish the tasks they need to do in the course of a normal day. On October 15, 2003, Microsoft released Security Bulletin 03-043. This bulletin is an advisory of a vulnerability in the Messenger service that allows an attacker to execute application code of his or her choice. Disable this service to prevent this, or as-yet unknown similar vulnerabilities from affecting a system.
4.1.11 Net Logon	<Not Defined>	The Net Logon service establishes the NetLogon secure channel with a domain controller. See 3.2.1.18 above.
4.1.12 NetMeeting Remote Desktop Sharing	Disabled	Microsoft has made one of the better collaboration tools that is available on the market today, but at the same time they took that tool – NetMeeting – and tried to make it into a remote control utility for help desk personnel to take control of your computer in time of need. In a world of hacker attacks and buffer overflows, it seems like only a matter of time before an exploit is discovered, or it is just abused. If you don’t have a dedicated help desk, or your help desk doesn’t use NetMeeting Remote Desktop Sharing, disable this service. If your organization requires this service, it should understand that there may be a risk involved.
4.1.13 Remote Desktop Help Session Manager	<Not Defined>	This service supports the Remote Assistance functionality. Disable the service to prohibit the use of Remote Assistance.
4.1.14 Remote Registry Service	<Not Defined>	The Windows Registry is essentially a database of settings and configuration options that affect almost every function of a Windows XP computer. It determines how everything behaves at startup, shutdown, and everything in between. The purpose of the Remote Registry Services is to expose that database to the rest of the network through a NetBIOS connection.
4.1.15 Routing and Remote Access	Disabled	The Routing and Remote Access service is normally used either to facilitate servers are Remote Access Servers, or to allow computers from one network to interact with computers on another. RRAS is not fully implemented on Windows XP Professional like it is in the server operating systems. Users generally don’t need RRAS on workstations. If this service can not be disabled, it should be locked down as much as possible. More information is available at http://www.microsoft.com/TechNet/columns/cableguy/cg0601.asp.
4.1.16 Simple Mail Transfer Protocol (SMTP)	Disabled	Workstations are not normally used as SMTP mail servers. This service is installed as part of the IIS suite of applications. It should be disabled or removed entirely.
4.1.17 Simple Network Management Protocol (SNMP) Service	Disabled	The Simple Network Management Protocol (SNMP) has long been the accepted standard for remote management through all network devices – routers, hubs, Unix, and Windows alike. It was recently discovered that SNMP has been proliferating a dangerously exploitable flaw for the past ten years or so. If you do not have a system actively using SNMP for remote management, disable it or remove it from the system
4.1.18 Simple Network Management Protocol (SNMP) Trap	Disabled	Another part of the SNMP protocol is the SNMP Trap service. Just like its counterpart, it should be disabled and/or removed.
4.1.19 Task Scheduler	<Not Defined>	The Task Scheduler service supports queuing batch programs for future execution. This could include virus scans, backups, or other system maintenance functions. With Windows XP, the task can run under alternate credentials, and does not necessarily have to run under the local system account.
4.1.20 Telnet	Disabled	The Telnet service is not often installed on workstations. It is used for remote management of network devices, and offers a command-shell based form of network access to a computer. This is all well and good, but the traffic transferred by Telnet is not protected or encrypted in any way. If this is a requirement, take the time to look into a Secure Shell (SSH) remote management solution to fulfill your needs in a more secure manner. It is well worth the time and expense.
4.1.21 Terminal Services	<Not Defined>	Terminal services allow a remote graphical interface to the workstation. Similar to pcAnywhere or Virtual Network Client (VNC) software packages, Terminal Services share using the Remote Desktop Protocol (RDP). Normal use of the terminal service on a workstation terminates the existing interactive logon session; however, if remote assistance is enabled, any existing session can be shared between two computers.
4.1.22 Universal Plug and Play Device Host	Disabled	Universal Plug and Play (UPnP) devices can be added to the network, and broadcast their availability for management. UPnP should not be confused with the more common Plug and Play (PnP) features useful for hardware management. UPnP finds devices on the network; PnP finds devices physically installed into the computer. Few devices on the market currently require UPnP, and this service should be disabled unless explicitly required.
4.1.23 World Wide Web Publishing Services	Disabled	The grand-daddy of all exploitable services is Microsoft’s World Wide Web service. It is the most often attacked web-server platform on the Internet today. As a result, it has had the most bugs found, and the most flaws exploited. This server is not installed by default, but should not exist on your average workstation. If it is not going to be properly maintained by personnel with an education in IIS security, it should be disabled or removed.
4.2 User Rights
4.2.1 Access this computer from the network	Administrators	The ability to access a computer from the network is a user right that can be granted or revoked on any machine as appropriate. If this list is left empty, no user accounts can be used to gain access to the resources of this computer from the network.
4.2.2 Act as part of the operating system	<None>	The operating system works in a special security context called “LocalSystem”. This security context has the ability to do things that normal users and administrative users can not. Granting this user right to users or groups will give them the ability to exceed normal privilege, regardless of their group membership.
4.2.3 Add workstations to domain	<Not Applicable>	This user right only applies to domain controllers, and has no effect on Windows XP Professional.
4.2.4 Adjust memory quotas for a process	<Not Defined>	This policy setting defines the accounts which can adjust the maximum amount of memory assigned to a process.
4.2.5 Allow logon through terminal services	Administrators	If terminal services are enabled, use this setting to explicitly control which users are allowed to remotely access the workstation.
4.2.6 Back up files and directories	Administrators	This user right grants a user or group the ability to circumvent normal Windows file security for the purposes of backing up files and folders. It should be restricted when possible.
4.2.7 Bypass traverse checking	Users	The Bypassing Traverse Checking user right allows access to files or folders regardless of the user’s permissions to the parent folder. In other words, prevents the inheritance of permissions. Unfortunately, it is necessary to grant this right to users to allow normal operation of applications on a workstation.
4.2.8 Change the system time	Administrators	Changing the system time on Windows XP computers is especially important to restrict in a domain environment because of the role that time synchronization plays in Kerberos authentication. This should not be configurable to anyone except Administrators.
4.2.9 Create a pagefile	Administrators	In order to protect the potentially sensitive information that can be stored in a pagefile, the creation of pagefiles should be restricted to Administrators.
4.2.10 Create a token object	<None>	Allows the creation of a security access token. This right should never be given to any user.
4.2.11 Create permanent shared objects	<None>	The right to create permanent shared objects should only be used by applications in the Windows kernel. The kernel already has the right to create such objects, so no users should ever be granted this right.
4.2.12 Debug Programs	Administrators	Any user can debug his or her programs, but this right allows a user to debug other processes on a machine. Users should not be granted this right except in an isolated development environment where possible. Microsoft is soon to release new Hotfix application technology that will require this right to apply patches. It promises fewer reboots for patches that need to be applied. In this light, Administrators still need this right to do their jobs. Hopefully, this will not be a permanent requirement, and can be eliminated in the future.
4.2.13 Deny access to this computer from the network	Guests	The “Deny Access” user rights always supercede the “Allow Access” user rights, so that if a user is listed under both user rights, that user will be denied access. If there are no users who should be allowed access to a computer from the network, the Everyone group should be listed in the “Deny Access to this computer from the network” user right.
4.2.14 Deny logon as a batch job	<Not Defined>	Just like the other “Deny…” user rights, a user listed here will be denied access to logon as a batch job, even if he has been explicitly granted that right.
4.2.15 Deny logon as a service	<Not Defined>	Just like the other “Deny…” user rights, a user listed here will be denied access to logon as a service, even if he has been explicitly granted that right.
4.2.16 Deny logon locally	<Not Defined>	Just like the other “Deny…” user rights, a user listed here will be denied access to logon to the console, even if he has been explicitly granted that right.
4.2.17 Deny logon through Terminal Service	<Not Defined>	Similar to the other “Deny…” rights, groups and accounts in this list will not be able to connect to the workstation using terminal services.
4.2.18 Enable computer and user accounts to be trusted for delegation	<Not Applicable>	This user right only applies to Domain Controllers. It has no effect on Windows XP Professional.
4.2.19 Force shutdown from a remote system	Administrators	This grants a user the right to shut down a computer from the network. It should only be granted to Administrators, and may be restricted to no users or groups at all.