copyright notice
accesses since January 4, 2007

Better-than-Nothing Security Practices™

for Securing Windows XP Professional

v 1.1.1

Hal Berghel

Jacob Uecker

 

This web page is a checklist for securing a Windows XP Professional workstation. The best way to implement security for such a workstation is through a domain controller using Active Directory and Group Policy. Given that an administrator for such a domain is unavailable there must be a way to implement some form of security, even if it's not the best methodology. We have tried to provide such an implementation, in the form of a checklist. Keep in mind that these steps are only recommendations to help harden a system; they are not concrete. We have tried to make this from the standpoint of a secure environment. With this in mind, you might find that our ideas don't match your environment. If you decide that such a setting is too strict, you can relax it a bit, but be aware of the possible attack vectors (which is just as important).

Many of these settings were meant for the default install of Windows XP Professional. If you have Service Pack 1 or 2 installed as well, some of the configuration changes will have been changed for you and they have been noted in red italics. However, all configurations should be checked on the box to make sure nothing has changed.

We take no responsibility whatsoever for the implications that these settings will have on your computer. It is always important to try these changes on a test machine before changing your infrastructure. We have tried to provide the consequences of each setting, but there is no doubt many more exist.

If you have any suggestions or comments please let us know.

The checklist steps are followed by a detailed description of why the steps are necessary.  

Copyright © 2003 by Hal Berghel and Jacob Uecker. All Rights Reserved.

 

Note: These instructions assume that Windows Start menu is set to Classic View. The necessary steps will be different if your Start menu is not set to Classic View. To change this, simply right-click on the Start button and select properties. Click on the "Start Menu" (top) radio button.

 

1. Account Policies
  1. Disable Guest Account
    1. Create Guest Password
      1. Open a Command Prompt
      2. Enter command: (drive\path)\:>net user guest password:<password>
      3. In place of <password>, hit random keys (the more the better; upper bound is 128 characters. Make sure to include characters from all of the character sets: upper and lowercase, numbers, and symbols. Don't forget to use the space too!)
      4. Press Enter
    2. Disable Guest and Support accounts (Pre-Service Pack 1 only)
      1. Start>Settings>Control Panel>Administrative Tools>Computer Management>Local Users and Groups>Users
      2. Double-click on "Guest"
      3. Inspect the value: "Account is disabled". The most secure setting is when the box is checked, meaning it is disabled.
      4. Click OK
      5. Repeat for all accounts that are not valid user accounts. This includes HelpAssistant, Support accounts, ASPNET, SQLDebugger, etc.
  2. Disable Remote Access to computer
    1. Right Click on "My Computer" on the desktop or right-click on the "My Computer" icon in Windows Explorer
    2. Click on "Properties"
    3. Click on the "Remote" tab
    4. Inspect the checkboxes: "Allow Remote Assistance invitations to be sent from this computer" and "Allow users to connect remotely to this computer". The most secure setting is to unclick the checkboxes.
    5. Hit "OK"
  3. Disable Simple File Sharing
    1. Open "My Computer"
    2. Open "Folder Options..." from the Tools menu
    3. Click the "View" tab
    4. In the Advanced Settings scroll menu, go to the bottom
    5. Inspect the checkbox: Unchecking "Use simple file sharing (Recommended)" is more secure.
  4. Change Access Privileges to Hard Drives
    1. Make sure Simple File Sharing is off (above step)
    2. Open "My Computer"
    3. For each hard drive :
      1. Right Click on the drive
      2. Select Properties
      3. Click on the "Security" tab
      4. Click on the "Advanced" button
      5. Highlight the "Everyone" list item by clicking once on it
      6. It is most secure to click "Remove"
      7. Click OK to exit the Advanced Security Settings window
      8. Click OK to exit the drive properties window
  5. Stop "Everyone" from Sharing
    For every share created:
    1. Right-click on the share
    2. Choose Properties
    3. Select the "Sharing" tab
    4. Click on the "Permissions..." button
    5. Adding all users that should have access to the share with the appropriate permissions is the most secure option
    6. Remove the "Everyone" group

2. Local Security Policies

Initiate each of the following changes with the following:

  1. Start>Settings>Control Panel
  2. Double Click on "Administrative Tools"
  3. Double Click on "Local Security Policy "

Account Policies

Password Policies

For each of the following, expand "Account Policies" and click on "Password Policy"

  1. Enforce Password History
    1. Double click "Enforce password history"
    2. Check the value. We consider 24 (or some reasonably large number) reasonable
    3. Click OK
  2. Maximum Password Age
    1. Double click "Maximum password age"
    2. Check the value. We consider 30 (or a reasonable password cycling period) reasonable
    3. Click OK
  3. Minimum Password Age
    1. Double click "Minimum password age"
    2. Check the value. We consider 1 reasonable.
    3. Click OK
  4. Minimum Password Length
    1. Double click "Minimum password length"
    2. Check the value. The most secure setting is 14 (the largest value allowed)
    3. Click OK
  5. Password Complexity
    1. Double click "Password must meet complexity requirements"
    2. Check the value. The most secure setting is "Enabled"
    3. Click OK
  6. Reversible Encryption (already set by default, but wise to check)
    1. Double click "Store password using reversible encryption for all users in the domain"
    2. Check the value. The most secure setting is "Disabled"
    3. Click OK

Account Lockout Policy

For each of the following, expand "Account Policies" and click on "Account Lockout Policy

  1. Account Lockout
    1. Double click "Account lockout threshold"
    2. Check the value. We consider 5 to be reasonable.
    3. When dialog box comes up and suggests 30 minutes for the duration and reset time click OK
    4. Click OK

Local Policies

Audit Policies

For each of the following, expand "Local Policies" and click on "Audit Policy"

  1. Audit Account Logon Events
    1. Double Click "Audit account logon events"
    2. Inspect the values. The most secure setting is "Success" and "Failure"
    3. Click "Apply"
    4. Click "OK"
  2. Audit Account Management
    1. Double Click "Audit account management"
    2. Inspect the values. The most secure setting is "Success" and "Failure"
    3. Click "Apply"
    4. Click "OK"
  3. Audit Directory Service Access (already set by default, but wise to check)
    1. Double Click "Audit Directory Service Access"
    2. Inspect the values. The best setting is "No Auditing" (uncheck both "success" and "failure")
    3. Click "Apply"
    4. Click "OK"
  4. Audit Logon Events
    1. Double Click "Audit  logon events"
    2. Inspect the values. The most secure setting is "Success" and "Failure"
    3. Click "Apply"
    4. Click "OK"
  5. Audit Object Access
    1. Double Click "Audit object access"
    2. Inspect the values. The best setting is "Failure"
    3. Click "Apply"
    4. Click "OK"
  6. Audit Policy Changes
    1. Double Click "Audit policy changes"
    2. Inspect the values. The most secure setting is "Success" and "Failure"
    3. Click "Apply"
    4. Click "OK"
  7. Audit Privilege Use
    1. Double Click "Audit privilege use "
    2. Inspect the values. They best setting is "Failure"
    3. Click "Apply"
    4. Click "OK"
  8. Audit Process Tracking (already set by default, but wise to check)
    1. Double Click "Audit Process Tracking"
    2. Inspect the values. The best setting is "No Auditing" (uncheck both "success" and "failure")
    3. Click "OK"
  9. Audit System Events
    1. Double Click "Audit system events"
    2. Inspect the values. The most secure setting is "Success" and "Failure"
    3. Click "Apply"
    4. Click "OK"

User's Rights

For each of the following, expand "Local Policies" and click on "User Rights Assignment"

  1. Who can access the computer from the network
    1. Double Click on "Access this computer from the network"
    2. The most secure option is to remove all the groups except "Administrators"
    3. Click OK
  2. Who can act as part of the operating system (should be set correctly by default)
    1. Double Click on "Act as part of the operating system"
    2. The most secure option is to remove all the groups from the list
    3. Click OK
  3. Who can add workstations to domain (should be set correctly by default)
    1. Double Click on "Add workstations to domain"
    2. The most secure option is to remove all the groups from the list
    3. Click OK
  4. Who can adjust memory quotas for a process (should be set correctly by default)
    1. Double Click on "Adjust memory quotas for a process"
    2. The most secure setting is to remove all groups except "Administrators", "LOCAL SERVICE", and "NETWORK SERVICE"
    3. Click OK
  5. Who can logon through Terminal Services
    1. Double Click on "Allow logon through Terminal Services"
    2. The most secure setting is to remove all groups from the list
    3. Click OK
  6. Who can backup files and directories
    1. Double Click on "Back up files and directories"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  7. Who can bypass traverse checking
    1. Double Click on "Bypass traverse checking"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  8. Who can change the system time
    1. Double Click on "Change the system time"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  9. Who can create a pagefile (should be set correctly by default)
    1. Double Click on "Create a pagefile"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  10. Who can create a token object (should be set correctly by default)
    1. Double Click on "Create a token object"
    2. The most secure setting is to remove all groups from the list
    3. Click OK
  11. Who can create global objects (should be set correctly by default -- Service Pack 2 option only)
    1. Double Click on "Create global objects"
    2. The most secure setting is to remove all groups except "Administrators", "INTERACTIVE", and "SERVICE".
    3. Click OK
  12. Who can create permanent share objects (should be set correctly by default)
    1. Double Click on "Create permanent shared objects"
    2. The most secure setting is to remove all groups from the list
    3. Click OK
  13. Who can debug programs (should be set correctly by default)
    1. Double Click on "Debug programs"
    2. The most secure setting is to remove all groups from the list except "Administrators"
    3. Click OK
  14. Explicitly deny access to computer from the network
    1. Double Click on "Deny access to this computer from the network"
    2. The most secure setting is to remove all groups from the list except "Guest", "SUPPORT_388945a0" (or subsitutes), and "HelpAssistant"
    3. If they are not listed, click on "Add User or Group..."
    4. Type in "Guest"
    5. Click "Check Names"
    6. The name of the computer with Guest should appear, click OK
    7. Repeat for "SUPPORT_388945a0" and "HelpAssistant" (use check names to determine if these accounts are on the computer. If not, ignore).
  15. Who is denied ability to log on as a batch job (should be set correctly by default)
    1. Double Click on "Deny logon as a batch job"
    2. The most secure setting is to remove all groups from the list
    3. Click OK
  16. Who is denied log on as a service (should be set correctly by default)
    1. Double Click on "Deny logon as a service"
    2. The most secure setting remove all groups from the list
    3. Click OK
  17. Who is denied from logging on locally
    1. Double Click on "Deny logon locally"
    2. The most secure setting is remove all groups from the list except "Guest", "SUPPORT_388945a0", and "HelpAssistant"
    3. If they are not listed, click on "Add User or Group..."
    4. Type in "Guest" and click "Check Names"
    5. The name of the computer with Guest should appear, click OK
    6. Repeat for "SUPPORT_388945a0" and "HelpAssistant"
  18. Who is denied from logging on through Terminal Services
    1. Double Click on "Deny logon through Terminal Services"
    2. The most secure setting remove all groups except "Everyone"
    3. If "Everyone" is not listed click on "Add User or Group..."
    4. Type in Everyone, and click "Check Names"
    5. Click OK
    6. Click OK
  19. Enable computer and user accounts to be trusted for delegation (should be set correctly by default)
    1. Double Click on "Enable computer and user accounts to be trusted for delegation"
    2. The most secure setting is to remove all users from the list
    3. Click OK
  20. Who can force a shutdown from a remote system (should be set correctly by default)
    1. Double Click on "Force shutdown from a remote system"
    2. The most secure setting is to remove all users and groups from the list except "Administrators"
    3. Click OK
  21. Who can generate security audits (should be set correctly by default)
    1. Double Click on "Generate security audits"
    2. The most secure setting is to remove all groups except "LOCAL SERVICE" and "NETWORK SERVICE"
    3. Click OK
  22. Who can impersonate clients after authentication (Service Pack 2 option only)
    1. Double click on "Impersonate a client after authentication"
    2. The most secure setting is to remove all groups from the list.
    3. Click OK
  23. Who can increase scheduling priority (should be set correctly by default)
    1. Double click on "Increase scheduling priority"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  24. Who can load and unload drivers (should be set correctly by default)
    1. Double Click on "Load and unload device drivers "
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  25. Who can lock pages in memory (should be set correctly by default)
    1. Double Click on "Lock pages in memory"
    2. The most secure setting is to remove all groups from the list
    3. Click OK
  26. Who can log on as a batch job
    1. Double Click on "Log on as a batch job"
    2. The most secure setting is to remove all groups from the list except "Administrator"
    3. Click OK
  27. Who can log on as a service (should be set correctly by default on Service Pack 1 and 2 machines)
    1. Double Click on "Log on as a service"
    2. The most secure setting is to remove all groups from the list except "NETWORK SERVICE" and "SYSTEM" (Note: Some SP2 machines only have "NETWORK SERVICE" listed. This is normal and doesn't need to be changed)
    3. Click OK
  28. Who can login locally
    1. Double Click on "Log on locally"
    2. The most secure setting is to remove all groups except "Administrators" and authorized "Users"
    3. Click OK
  29. Who can manage auditing and security logs (should be set correctly by default)
    1. Double Click on "Manage auditing and security log"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  30. Who can modify firmware environment values (should be set correctly by default)
    1. Double Click on "Modify firmware environment values"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  31. Who can perform volume maintenance tasks (should be set correctly by default)
    1. Double Click on "Perform volume maintenance tasks"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  32. Who can profile a single process
    1. Double Click on "Profile single process"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  33. Who can profile system performance (should be set correctly by default)
    1. Double Click on "Profile system performance"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  34. Who can remove computer from docking station (should be set correctly by default)
    1. Double Click on "Remove computer from docking station"
    2. The most secure setting is to remove all groups except "Administrators", "Power Users" and "Users"
    3. Click OK
  35. Who can replace a process level token (should be set correctly by default)
    1. Double Click on "Replace a process level token"
    2. The most secure setting is to remove all groups except "LOCAL SERVICE" and "NETWORK SERVICE"
    3. Click OK
  36. Who can restore files and directories
    1. Double Click "Restore files and directories"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK
  37. Who can shut down the system
    1. Double Click "Shut down the system"
    2. The most secure setting is to remove all groups except "Administrators", "Power Users", and "Users"
    3. Click OK
  38. Who can synchronize directory service data (should be set correctly by default)
    1. Double Click "Synchronize directory service data"
    2. The most secure setting is to remove all groups from the list
    3. Click OK
  39. Who can take ownership of files and other objects (should be set correctly by default)
    1. Double Click on "Take ownership of files and other objects"
    2. The most secure setting is to remove all groups except "Administrators"
    3. Click OK

Security Options

For each of the following, expand "Local Policies" and click on "Security Options"

  1. Administrator account status (should be set correctly by default)
    1. Double Click on "Accounts: Administrator account status"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  2. Guest account access (should be set correctly by default)
    1. Double Click on "Accounts: Guest account status"
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  3. Blank passwords at console only (should be set correctly by default)
    1. Double Click on "Accounts: Limit local account use of blank passwords to console login only"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  4. Rename the Administrator account
    1. Double Click on "Accounts: Rename administrator account"
    2. It's most secure to type in a name to serve as the "Administrator" account
    3. Click OK
  5. Rename the Guest account
    1. Double Click on "Accounts: Rename guest account"
    2. It's most secure to type in a name to serve as the guest account (eg sdllfhasklgfh890237)
    3. Click OK
  6. Audit access of global system objects (should be set correctly by default)
    1. Double Click on "Audit: Audit the access of global system objects"
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  7. Audit the use of Backup and Restore privilege (should be set correctly by default)
    1. Double Click on "Audit: Audit use of Backup and Restore privilege"
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  8. Shutdown computer if error in audit logs (should be set correctly by default)
    1. Double Click on "Audit: Shut down system immediately if unable to log security audits"
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  9. DCOM Access Restrictions (should be set correctly by default -- Service Pack 2 option only)
    1. Double Click on "DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) Syntax"
    2. Leave the Security Descriptor blank
    3. Click OK
  10. DCOM Launch Restrictions (should be set correctly by default -- Service Pack 2 option only)
    1. Double Click on "DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) Syntax"
    2. Leave the Security Descriptor blank
    3. Click OK
  11. Allow undock without logging in
    1. Double Click on "Devices: Allow undock without having to log on"
    2. Click on "Disabled" or "Enabled", as your prefer
    3. Click OK
  12. Who is allowed to format and eject removable media (should be set correctly by default)
    1. Double Click on "Devices: Allowed to format and eject removable media"
    2. Inspect the value. The most secure setting is to set the pulldown menu on "Administrator"
    3. Click OK
  13. Prevention of users installing printer drivers
    1. Double Click on "Devices: Prevent users from installing printer drivers"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  14. Restrict the CD-ROM to locally logged in users
    1. Double Click on "Devices: Restrict CD-ROM access to locally logged-on user only"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  15. Restrict the floppy to locally logged in users
    1. Double Click on "Devices: Restrict floppy access to locally logged-on users only"
    2. Inpect the value. The most secure setting is "Enabled"
    3. Click OK
  16. Unsigned driver behavior (should be set correctly by default)
    1. Double Click on "Devices: Unsigned driver installation behavior"
    2. Inspect the value. The most secure setting is to select "Warn but allow installation" from the pulldown menu
    3. Click OK
  17. Encrypt or sign secure channel data (always) (should be set correctly by default)
    1. Double Click on "Domain member: Digitally encrypt or sign secure channel data (always)"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  18. Encrypt secure channel data (when possible) (should be set correctly by default)
    1. Double Click on "Domain member: Digitally encrypt secure channel data (when possible)"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  19. Sign secure channel data (when possible) (should be set correctly by default)
    1. Double Click on "Domain member: Digitally sign secure channel data (when possible)"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  20. Display last username logged in
    1. Double Click on "Interactive logon: Do not display last user name"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  21. Don't require Ctrl+Alt+Del to log on
    1. Double Click "Interactive logon: Do not require CTRL+ALT+ DEL "
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  22. Number of logons to cache locally
    1. Double Click "Interactive logon: Number of previous logons to cache (in case domain controller is not available)"
    2. Inspect the value. The most secure setting is to set the value to 0
    3. Click OK
  23. Number of days before password expiration to prompt user (should be set correctly by default)
    1. Double Click "Interactive logon: Prompt user to change password before expiration"
    2. Inspect the value. We consider a setting of 14 days reasonable
    3. Click OK
  24. Domain Controller required to unlock workstation (should be set correctly by default -- Service Pack 2 option only)
    1. Double Click "Interactive logon: Require Domain Controller authentication to unlock workstation"
    2. Inspect the value. The value should be "Disabled"
    3. Click OK
  25. Smart card required to login (should be set correctly by default -- Service Pack 2 option only)
    1. Double Click "Interactive logon: Require Smart Card"
    2. Inspect the value. The value should be "Disabled"
    3. Click OK
  26. Smart card removal behavior
    1. Double Click "Interactive logon: Smart card removal behavior"
    2. Inspect the value. The most secure setting is to select "Lock Workstation" or "Force Logoff" from the pulldown menu
    3. Click OK
  27. Client - Digitally sign communications (always)
    1. Double Click on "Microsoft network client: Digitally sign communications (always)"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  28. Client - Digitally sign communications (if server agrees) (should be set correctly by default)
    1. Double Click on "Microsoft network client: Digitally sign communications (if server agrees)"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  29. Send unencrypted passwords to 3rd party SMB servers (should be set correctly by default)
    1. Double Click on "Microsoft network client: Send unencrypted password to third-party SMB servers"
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  30. Amount of time before session is suspended (should be set correctly by default)
    1. Double Click on "Microsoft network server: Amount of idle time required before suspending session"
    2. Inspect the value. We consider 15 minutes reasonable
    3. Click on OK
  31. Server - Digitally sign communications (always)
    1. Double Click on "Microsoft network server: Digitally sign communications (always)"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  32. Server - Digitally sign communications (if client agrees)
    1. Double Click on "Microsoft network server: Digitally sign communications (if client agrees)"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  33. Disconnect clients when logon hours expire (should be set correctly by default)
    1. Double Click on "Microsoft network server: Disconnect clients when logon hours expire"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  34. Allow anonymous SID/Name translation (should be set correctly by default)
    1. Double Click on "Network access: Allow anonymous SID/Name translation"
    2. Inspect the value. If available, the most secure setting is click on "Disabled"
    3. Click OK
  35. Do not allow anonymous enumeration of SAM accounts (should be set correctly by default)
    1. Double Click on "Network access: Do not allow anonymous enumeration of SAM accounts"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  36. Disable anonymous enumeration of SAM accounts and shares
    1. Double Click on "Network access: Do not allow anonymous enumeration of SAM accounts and shares "
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  37. Do not allow storage of credentials and .NET passports
    1. Double Click on "Network access: Do not allow storage of credentials or .NET passports for network authentication"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  38. Let Everyone permission apply to anonymous users (should be set correctly by default)
    1. Double Click on "Network access: Let Everyone permissions apply to anonymous users"
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  39. Named pipes that can be accessed anonymously
    1. Double Click on "Network access: Named Pipes that can be accessed anonymously"
    2. See detailed description
    3. Click OK
  40. Remotely accessible registry paths
    1. Double Click on "Network access: Remotely accessible registry paths"
    2. The most secure setting is to delete all the entries
    3. Click OK
  41. Shares accessible anonymously
    1. Double Click on "Network access: Shares that can be accessed anonymously"
    2. The most secure setting is to delete all the entries
    3. Click OK
  42. Sharing and security model for local accounts (should be set correctly by default)
    1. Double Click on "Network access: Sharing and security model for local accounts"
    2. Inspect the value. The most secure setting is to choose "Classic: local users authenticate as themselves"
    3. Click OK
  43. Do not store LAN Manager password
    1. Double Click on "Network security: Do not store LAN Manager hash value on next password change"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  44. Force logoff
    1. Double Click on "Network security: Force logoff when logon hours expire"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  45. Password authentication level
    1. Double Click on "Network security: LAN Manager authentication level"
    2. Inspect the value. The most secure setting is "Send NTLMv2 response only\refuse LM & NTLM"
    3. Click OK
  46. LDAP client signing requirements (should be set correctly by default)
    1. Double Click on "Network security: LDAP client signing requirements"
    2. Inspect the value. The most secure setting is "Negotiate signing"
    3. Click OK
  47. Minimum session security for NTLM SSP based clients
    1. Double Click on "Network security: Minimum session security for NTLM SSP based (including secure RPC) clients"
    2. Inspect the values. We find checking boxes next to "Require NTLMv2 session security" and "Require 128-bit encryption" to be reasonable
    3. Click OK
  48. Minimum session security for NTLM SSP based servers
    1. Double Click on "Network security: Minimum session security for NTLM SSP based (including secure RPC) servers"
    2. Inspect the values. We find checking boxes next to "Require NTLMv2 session security" and "Require 128-bit encryption" to be reasonable.
    3. Click OK
  49. Allow automatic administrative logon under recovery console (should be set correctly by default)
    1. Double Click on "Recovery Console: Allow automatic administrative logon"
    2. Inspect the values. The most secure setting is "Disabled"
    3. Click OK
  50. Allow floppy copy and access to all drives and folders under recovery console (should be set correctly by default)
    1. Double Click on "Recover Console: Allow floppy copy and access to all drives and folders"
    2. Inspect the values. The most secure setting is "Disabled"
    3. Click OK
  51. Allow system shutdown without logging in
    1. Double Click on "Shutdown: Allow system to be shut down without having to log on"
    2. Inspect the value. The most secure setting is "Disabled"
    3. Click OK
  52. Clear pagefile on shutdown
    1. Double Click on "Shutdown: Clear virtual memory pagefile"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  53. Use FIPS compliant algorithms for encryption, hashing and signing (should be set correctly by default)
    1. Double Click on "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing"
    2. Inspect the value. We find "Disabled" to be a reasonable setting
    3. Click OK
  54. Default owner for objects created by members of the Administrators group
    1. Double Click on "System objects: Default owner for objects created by members of the Administrators group"
    2. Inspect the value. The most secure seting is to select "Administrators Group" from the pulldown menu
    3. Click OK
  55. Require case insensitivity for non-Windows subsystems (should be set correctly by default)
    1. Double Click on "System objects: Require case insensitivity for non-Windows subsystems"
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK
  56. Strengthen default permissions of internal system objects (should be set correctly by default)
    1. Double Click on "System Objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)
    2. Inspect the value. The most secure setting is "Enabled"
    3. Click OK

3. Other Security Issues

Miscellaneous Registry Modifications

  1. Disable Memory Dump Files
    1. Stop Debugging Information Storage
      1. Right Click on "My Computer" and choose "Properties"
      2. Click on the "Advanced" tab
      3. Under Startup and Recovery, click "Settings"
      4. The most secure setting is to change the pulldown menu under "Write debugging information" to (none)
      5. Click OK
      6. Click OK
    2. Stop Dr. Watson's Storage files
      1. Start>Run...
      2. Type in "regedit" and click OK
      3. Navigate to HKEY_LOCAL_MACHINE> SOFTWARE> Microsoft> Windows NT> CurrentVersion> AeDebug
      4. Double Click on "Auto"
      5. Inspect the value. The most secure setting is to change the value to 0
      6. Click OK
      7. Navigate to HKEY_LOCAL_MACHINE> SOFTWARE> Microsoft> DrWatson>
      8. Double Click on "CreateCrashDump"
      9. Check the value. The most secure setting to change the value to 0 (should be set correctly by default on some systems -- double check)
      10. Click OK
      11. Right Click on the Start Button
      12. Choose Explore
      13. Go to Documents and Settings>All Users>Shared Documents>DrWatson
      14. If found, it is more secure to delete User.dmp and Drwtsn32.log if found
    3. Stop Hibernation File (should be set correctly by default on some systems -- double check)
      1. Start> Settings> Control Panel> Power Options> Hibernate
      2. Check the value. The most secure setting is to uncheck the "Enable Hibernation" box
      3. Click OK
  2. Automatically login administrator
    1. Open the registry editor through Start>Run...>regedit
    2. Navigate to HKEY_LOCAL_MACHINE> SOFTWARE> Microsoft> Windows NT> Current Version> Winlogon
    3. Double Click on or add the DWORD value "autoadminlogon"
    4. If the DWORD key does not exist, create it by Edit>New>DWORD and type in "autoadminlogon"
    5. Check the data. The most secure setting is 0
    6. Click OK

Misc Modifications

  1. Stop Dangerous Services controlled through Local Services Administrator
    1. Start>Settings>Control Panel>Administrative Tools>Services
    2. Double Click on "telnet"
    3. Changing the Startup type to "Disabled" is the most secure setting
    4. The service may need to be stopped if it is currently running (click on the "Stop" button in the Service status section)
    5. Repeat for these services:

 

 

Detailed Descriptions  

Create Guest Password

Why do this?

Guest accounts are problematic for a number of perspectives. For one, if guest is enabled without a password, all remote access will default to “guest” on logon if the username is not listed in the accounts database or if simple file sharing is enabled. For another, anonymous logins are handled as requests to the guest account. In general, users of system should be forced to provide some sort of credentials as authentication. This includes usage of the console, remote resource access, and any other method of system access. One of the common classifications of exploits is a privilege escalation. In this type of exploit, the attacker will do something, like execute code that gives them privileges to do something that they would not otherwise be able to do. This type of exploit is well suited to Guest account access. Someone could gain access to the computer using the guest account and exploit a vulnerability which gives them privileges to completely control the system.

According to Microsoft Knowledge Base article 300489, the following applies to the Guest account:

Although all these restrictions do apply to a new guest account, there is now substitute for blocking any user from ever using the account. There will never be the option of any exploitation of the account.

If you shut the guest account off, why assign it a complex password? Simply put, so a hacker can't turn the guest account back on and use it. If guest is reactivated, it still has a password that needs to be cracked before it can be used. This is just another instance of defense-in-depth.

Remember that the password that is typed after "net use guest password:" should be random and very long (over 100 characters). You should utilize all types of characters (upper- and lower-case, numbers, and special characters). One of the most underused character in creating a strong password is the space bar. It is a perfectly valid character and adds another level of complexity in password creation.

What consequences will there be on my system?

It completely stops people from accessing your computer through the guest account, anonymous logins through the console or terminal services, null sessions and anonymous LDAP queries.

When a long, complex password is chosen for the guest account, it becomes virtually unusable. Unless someone can guess the password (given a few thousand years) the account becomes disabled. This means that anyone who wants to access the computer will now have to get a real user account to access the information. It also means that hackers who used the guest account to anonymously access data won't be able to do this anymore. Once the Guest account has been disabled, Simple File Sharing (discussed in another section) must be disabled as well. When Simple File Sharing is enabled (which is the default when XP Pro uses a workgroup rather than a domain), all file sharing happens using the guest account. Obviously with the guest account inaccessible, the mode of file sharing has to be changed for any file sharing to operate.

Return

Disable Guest Account and Support accounts

Why do this?

For the same reasons outlined above. An active guest account is an extremely bad idea because it allows anyone access to data that possibly should not be seen. If there are people who need access to a file or program, they should have an account with a password. The Support accounts serve a number of purposes. The SUPPORT_####### (where ####### is a hexadecimal number) account that is installed in every Windows XP machine is used for Microsoft customer support. It allows remote desktop sessions to be initiated in the form of an invitation to Microsoft customer care (or malicious attacker). HelpAssistant is a similar account, but it is used to invite people outside of the Microsoft Corporation to help with computer problems. The ASP.NET account is installed when Microsoft .NET framework is installed. It is necessary for Windows to run the asp.net worker process within the Internet Information Services. It is created so that the necessary process is not run with Administrator privileges. The SQLDebugger account is created by the install of applications Microsoft Visual Studio or SQL server. It serves much the same purpose of the ASP.NET account. These accounts are necessary for specific functions by specific programs. There are a number of ways that securing these accounts can be approached. If there is no need for the accounts, because there functionality is not required, they can be safely disabled. It is also possible to stop the use of these accounts from remote computers, on the console, as batch jobs, etc.

What consequences will there be on my system?

It completely stops people from accessing your computer through the guest account. Since the guest account shouldn't be used for normal purposes anyway, it should be not available for hackers to access your box without your permission. By disabling the other accounts, functionality that is needed from programs that require the accounts will also be disabled. While it's unlikely that the SUPPORT_ and HelpAssistant accounts will be needed, the ASP.NET and SQLDebugger accounts maybe depending on each individual situation.

Return

Disable Remote Access to Computer

Why do this?

Remote Assistance and Remote Desktop are services provided in Windows XP that allow someone to connect to your computer over the network and use it as if they were sitting in front of it. This can be used in helping someone troubleshoot a problem. Rather than having to try to communicate over the phone and explain the problem, a support person can simply take control of the computer and fix whatever problem exists. This can also be an extremely useful tool. When a Windows server is deployed remotely in the field, access can still be made through Remote Desktop. This could be an incredibly useful tool because it could save a trip to the remote location. It could make more secure by tunneling the communication through a more secure communication channel like SSH or a VPN. Unfortunately, there is a dark side to Remote Desktop. Since it is so powerful, it could be used by an attacker to gain control of the system. Should an attack be found that could grant access to anyone, the system could be completely compromised. Additionally, programs exist that continually try to guess the password of accounts on the system. Some can even do this without being detected in the system logs. Keep in mind that other programs exist that can provide remote connectivity which are a little more secure.

What consequences will there be on my system?

By disabling Remote Access, you will no longer be able to access your computer through Remote Desktop. A common example of Remote Desktop is accessing the computer while on vacation. Remote Desktop can be very helpful since you can access your computer just as you were sitting in front of it, from thousands of miles away. By disabling the "remote invitations" feature, such invitations will no be able to be used. An account will have to be setup on the machine which allows access.

Note that when using Remote Desktop, all of the same functionality is available to you from your hotel in Sri Lanka as is available at the keyboard. The problem is that other people (hackers) could also have that same functionality if Remote Desktop is enabled.

Return

Disable Simple File Sharing

Why do this?

Simple File Sharing is the mechanism by which Windows XP shares files and folders in the networked workgroup environment. The workgroup environment is generally the configuration that is used with most computers. In this mode, it is not part of an Active Directory structure. Under this policy, resources are shared without access restrictions. There are no passwords, so anyone can see everything that is shared. This way, if one of the computers in your network is compromised, all computers should be considered as such because there is open sharing. This can be replaced with a more secure policy by shutting off Simple File Sharing. Each shared disk or folder then has an Access Control List (ACL) which describes who can use the shared resources. This setting is also accessible through the registry key: HKLM> System> CurrentControlSet> Control> Lsa> forceguest. The value should be 0. File sharing in general is something that should not be done in a secure environment because of the risks of exploitation. There is a small possibility that the file sharing itself could be exploited to gain access to other files. If this were to happen, an attacker could possibly add malicious files or delete critical files.

What consequences will there be on my system?

By shutting off Simple File Sharing users who count on the fact that there is no access restriction for the resource will now not have access. If your network can operate under the system of complete trust, then Simple File Sharing might work fine, but it is much safer to shut it off and follow the policy of least privilege. This dictates that each user should have the minimum amount of privilege to do their necessary tasks. While this model of sharing is much more usable, the additional effort involved in Advanced File Sharing is much more secure. In short, some network resources will be unavailable until redesigned.

Return

Change Access Privileges to Hard Drives

Why do this?

Windows XP Professional has the default setting of giving the Everyone group read access to the drives. This means that all the users from any group (Administrators, Power Users, Guest) will have the ability to read files on the computer unless there is a Deny statement for a particular file or folder that stops access. Since deny statements take precedence over the allow statements, access can be stopped on a per file/folder basis. This is not an efficient method of limiting access. If a user would like to view a file, they should be given explicit privilege to do so. A more secure policy is to remove the Everyone group so that a user must be part of the Administrators, Power Users, or Users group could access the resources. By default, when a new user is added, they will be added to either the Administrators group or the Users group. The Guest account and anonymous logins will not be allowed read access to any resources in the system. By doing this, a user has to be granted access to the system rather than being given access.

What consequences will there be on my system?

By removing the Everyone group privileges, it effectively only removes the guest account login abilities. This is due to the fact that all other accounts on the system should belong to the Users group as well as the Everyone group. When the Everyone group is removed from the file permissions access control list (ACL), the accounts that only belong to the Everyone group (and not to any others) will not have access. Since all persons accessing the computer should be given an individual account, there really should be no affect on the system. If there is some problem that results from this, a careful audit of the users and access to the system should be reviewed.

Return

Stop “Everyone” from Sharing

Why do this?

When a share is created in Windows XP Professional, it is created with a default set of permissions. They allow anyone to read what is being shared. Of course different permissions exist to connect to the computer so the permissions for the share don't necessarily allow anyone to connect to the computer. See “Disable Simple File Sharing” and Local Security Policy settings involving network connections for more information. While giving read access to the share doesn't give people the ability to put a malicious virus, for example, but it could allow someone access to files that are private and/or proprietary. The best thing to do is not share any files over the network. When this is absolutely unacceptable, it is best to allow specific individuals or groups access to the shared resources. While this significantly increases authentication and accounting on the system this is not really a bad thing. Because authentication and account is being used, there is a record of who accessed what and when.

What consequences does this have on my system?

This will most likely have no effect on your system. The only way that connectivity would change is if Simple File Sharing were turned on, the group Everyone were allowed to access the computer in the User Right's section, and no other access restriction stops the anonymous user. While this is probably the case in a default install of Windows XP, any tightening down of security would stop the connections.

 

Enforce Password History

Why do this?

People have a habit of using the same passwords over and over. When asked to change their password, they will often choose the same password as before, or they will rotate among a small set of passwords. This gives attackers a vulnerability to exploit. If an attacker finds one user's password, they will have access to the system much longer than if the password had been changed more often. By enforcing a password history, users will have to change their password to something new because the system will not allow the user to use a password that was used previously.

What consequences will there be on my system?

One of the consequences of making users choose a new password frequently and enforcing history is that users will have a more difficult time remembering all the new passwords. As a result, the user might resort to writing down the password and sticking in an accessible place, like underneath the keyboard, which could be a greater security risk.

Return

Maximum Password Age

Why do this?

Allowing a user to use the same password for a long period of time leaves an attacker that amount of time to undermine the system, should the password become compromised. By making the users change their password after a period of time, the attacker must work to maintain a presence on the system. If the amount of effort to obtain the password in the first place is sizeable, there is a good chance the attacker will need to do all that work over again to regain access to the computer (unless a backdoor was created). With today's password cracking software and faster hardware, attackers can crack passwords using brute force faster than ever before. Making users change their password more often greatly increases security because the attacker may spend days cracking the users password, only to find the user has changed it again.

What consequences will there be on my system?

There is a fine line between making the users change their password for security purposes and making the user change the password so much that it becomes a security risk. As stated above, if the user has to change the password often, he or she will simply start writing the current password down where it could be easily seen be anyone having physical access to the paper.

Return

Minimum Password Age

Why do this?

This setting controls the amount of time the user must wait before being able to change their password again. The main goal in setting this time is to make sure users can't change their password as required by the Maximum Password Age setting, and then cycle through a series of passwords to simply change their password back to what it was before, thereby undermining the Maximum Password Age and the Password History setting.

What consequences will there be on my system?

Users on the system will simply not be able to change their passwords immediately after changing them.

Return

Minimum Password Length

Why do this?

This setting is extremely important because it can stop the use of LAN Manager passwords as well as add complexity to the password, making it significantly harder to crack. LAN Manager passwords are limited to at most 14 characters. Creating a password longer than that ensures that the insecure LAN Manager password hash is not stored. Secondly, password complexity is a function of the number of possible characters raised to the power of the length. For example, if a password can only be composed of 26 characters, a password of five characters could be any one of 26^5 = 11,881,376 possibilities. If the length is increased to 15 characters the possibilities increase to 26^15 = 1.677 x 10^21. So the easiest way to increase the difficulty in cracking a password using brute-force is using a long length password. The maximum value for the LAN Manager field is 14; thus using a password 15 characters long will prevent storing LAN Manager passwords. However, since the minimum cannot be set to more than 14, management must enforce a separate policy requiring a password length of 15 or more.

What consequences will there be on my system?

Versions of Windows prior to Windows NT 4.0, which includes Windows 9x/ME and Windows for Workgroups do not allow long passwords, so they will be incompatible. It is recommended that these older systems not be allowed on any network attached to the Internet anyway because of numerous security vulnerabilities.

Return

Password Complexity

Why do this?

Enabling this feature enforces a strong password policy: passwords have to be at least six characters and must be made up of characters from three of four different categories (uppercase letters, lowercase letters, numbers, and special characters).
An attacker must know the character set used to generate the password. A larger character set means longer times required to crack the password using brute-force methods. Given that this setting enforces strong passwords, the attacker must run the attack with a large set of characters, increasing the amount of time needed to test all the combinations of passwords. Enabling this setting also stops a user from using any part of their username as the password, which is a common practice and extremely vulnerable to attack. Often this is the first guess that an attacker will try and leads to easy access of the system.

What consequences will there be on my system?

This makes the users have to choose passwords that are possibly more complex than they had been before. It could lead to users writing down their passwords.

Return

Reversible Encryption

Why do this?

This option controls whether or not the user's passwords should be stored as a two-way hash. Some applications request access to the passwords and this is facilitated through the use of reversible encryption. This is an extremely bad idea! It is essentially the same as not encrypting the passwords in the first place.

What consequences will there be on the system?

Having this option disabled may cause some programs to request the password instead of pulling it from the reversible encryption file. This added effort is, however, preferable to the security risk of having a two-way hash function to encrypt the passwords.

Return

Account Lockout

Why do this?

One of the techniques of attacking a system to gain access is to guess user passwords. This can be straightforward in that, at the login screen different passwords are guessed until the correct one is chosen and the attacker is logged in. This can be prevented by enabling polices which lock the account out for a period of time. This means that the attacker will have the chance to guess a limited number of times before the account becomes non-operational for a period of time. This increases the time and effort that the attacker must expend to gain access to the system.

What consequences will there be on my system?

When passwords are more difficult to type a user can end up locking themselves out of their computer because they type their password wrong a number of times, consecutively. As a result, they are unable to login to their computer for a period of time. Consideration needs to be taken to ensure that the appropriate amount of guesses can be tried before account lockout. This is dependent on the policies set for password length and complexity. The right setting can then be created to minimize attacks but keep users from locking themselves out.

Return

Audit Account Logon

Why do this?

Auditing is the task of keeping a record of different actions that take place in the system for further analysis. These events can be benign but they can also provide information to aid in tracking down an attacker or security hole in the system. It is necessary to maintain a balance between too much auditing and not enough because too much auditing can lead to such a large amount of information that parsing through it is difficult, but not enough offers little assistance when needed. By Auditing Account Logon Events, a record will be made if the local machine is used in authenticating logins. This type of event is usually triggered by Kerberos authentication. For example, if a domain account is used to login to a workstation, the domain controller that authenticated the login will contain the logged event. This probably won't generate any events on a stand-alone workstation, but it should be turned on in case the system is reused.

What consequences will there be on my system?

A record will be stored on disk detailing the authentication made.

Return

Audit Account Management

Why do this?

This auditing option will save information about the changes made to user accounts. For example, if an account is created or changed, it will be recorded. This can be an important tool if users complain that their password has been changed or you notice a new account. A record of the changes can be referenced to have a starting point for tracing any illegitimate activities. Without this kind of log, a starting point would not be available.

What consequences will there be on my system?

Records will be created when any account related activity takes place.

Return

Audit Directory Service Access

Why do this?

This option will log attempted and successful accesses to Active Directory objects within a domain controller. Thus, it is not applicable to workstations and should not be enabled.

What consequences will there be on my system?

There will be no affect on your system.

Return

Audit Logon Events

Why do this?

Auditing logon events will record information about the users who login and logout. This can be useful in building a fingerprint for the system. For example, one can notice that most users login at a certain time of day, or there are usually three users logged in at night. Once this fingerprint is established, it becomes much easier to see problems before and while they are occurring. Auditing logon events also helps to track down attacks on the system. You will be able to see a large number of unsuccessful attempts, for example.

What consequences will there be on my system?

Every user login or failed login attempt will be recorded whether the user be trying to login remotely or interactively.

Return

Audit Object Access

Why do this?

Almost everything in Windows is an object. Files, folders, registry keys, printers, etc are all objects and all objects have an Access Control List (ACL) which describes who can access the object and how it is audited. When a user tries to access something that they don't have access to, it will be recorded. It is not wise to record successes on this event because successful object accesses are extremely numerous. However, failures should be recorded because they give some insight to users trying to access things that they shouldn't, as well as having a way to reference the possible reasons why something can't be used.

What consequences will there be on my system?

Records will be created each time someone tries to access something that they don't have access privileges for. It could also act as a deterrent for users if they know they will be recorded trying to do something that they shouldn't.

Return

Audit Policy Change

Why do this?

Most of what has been recommended thus far has dealt with policy changes. When a policy change is done, it will be recorded. This can be used to see when something was changed, if it was changed by someone else. If an attacker were to get in the system and allow LAN Manager hashing through the local security policy, there would be a record of it. It is important to make sure that the Security Option, "Audit: Shut down system immediately if unable to log security audits" (registry key: HKEY_LOCAL_MACHINE> SYSTEM> CurrentControlSet> Control> Lsa> crashonauditfail = 0) is disabled. If enabled, it is possible that the system might crash when rebooted and when rebooted again, only the administrator will be able to login. The value will have to be changed before other users will be able to login. This problem has been fixed by a Microsoft patch. Details can be found here .

What consequences will there be on my system?

Records will continue to be created every time a policy change is made or failed to be made. As stated above, if the crashonauditfail value is enabled, only administrator will be able to login after two restarts (the first restart being a system crash).

Return

Audit Privilege Use

Why do this?

Each time a user does something that is considered their user right, the event is logged. This doesn't include backing up and restoring files, creating a token object or debugging programs. It is important to make sure that the Security Option in the Local Security Policy, "Audit: Audit the use of Backup and Restore privilege" is disabled. When this is turned on, the audit files will quickly become filled.

What consequences will there be on my system?

Records will be created that detail the attempt to access things that the user has no privilege for, as outlined by the User's Rights Assignments.

Return

Audit Process Tracking

Why do this?

This option is used only when your computer is believed to be under attack. It records events like program and process entrance and exit. Obviously this would generate large amounts of information and should only be used when necessary.

What consequences will there be on my system?

Every time a process starts or stops a record will be created.

Return

Audit System Events

Why do this?

Anything that the user does that affects system security or the audit logs will be recorded. It is an obvious advantage to know when and who tried to modify something that would affect system security. This information can be used to reprimand users who are abusing policy and making the system more vulnerable. All events such as restarting and shutdown of the computer, or failure to do so, will be recorded.

What cnsequences will there be on my system?

Events affecting system security will be recorded.

Return

Who can access the computer from the network

Why do this?

This option allows the groups of users listed to access the computer remotely through SMB sessions. It is a good idea to limit the users who should be authorized to log in remotely. The rule of least privilege implies that if there is no need for the user to access the computer over a network, they should not be allowed to do so. This helps to limit the number of accounts exploitable to an attacker. There is no reason why the Guest account should be allowed to log in remotely; it should be eliminated. Also, the Support account(s) are not needed, and should be disabled as well. This setting won't effect services other than SMB.

What consequences will there be on my system?

All accounts that are not part of one of the groups listed will be denied access to the computer from the network. The user accounts need to be looked over to make sure that a user with legitimate purpose is able to log in remotely. By removing it from the list, the support account will not be able log in to the computer. It should, however, be disabled to keep attackers from exploiting the account.

Return

Who can act as part of the Operating System

Why do this?

Letting a user act as part of the operating system gives that user more privileges than administrator. It is a low-level account that allows that user to bypass all access privileges, security permissions, and users rights. If this account should become under control of an attackers, it would allow that person complete control of the system. All other security measures would become worthless because they could simply be bypassed. Under normal operating procedures, such an account is unnecessary and should not be allowed.

What consequences will there be on my system?

If the principle of least privilege is followed, this will have no affect on the system because all necessary functions can be done without acting as part of the operating system. Administrator should be the most powerful account on the system and that should be guarded as the key to the system. No other account should be created with that power as it adds only to security risk.

Return

Who can add workstations to the domain

Why do this?

This user right only has relevance in a domain environment. Since we are considering how individual workstations should be locked down, there is no reason to add any group to this list. If the computer were in a domain, the users who should have this privilege have it as part of that account, they do not need to be given the privilege explicitly. This will keep attackers from adding an untrusted workstation to the domain.

What consequences will there be on my system?

When all users are removed from this list on an individual workstation, there will be no effect on the system, as it is not on a domain.

Return

Who can adjust memory quotas for a process

Why do this?

This gives a user the ability to change the maximum amount of memory that a process can consume. Since there is a limited amount of computer memory, this can be used to fine tune a system. By allowing a process a little more memory, it can function faster. But this ability can also be misused in creating a denial of service attack. If an attacker gives all the available memory to a single process, no other processes will function until that process releases it's memory. Obviously an attacker can use this as a tool to cripple a system.

What consequences will there be on my system?

This will have very little, if any, effect on your system. Even though the ability to change the memory quota exists, there will be no effect until it is actually used by the proper accounts.

Return

Who can logon through Terminal Services

Why do this?

This determines who can logon to the computer remotely through terminal services. The use of Remote Desktop requires this privilege. Because Remote Desktop shouldn't be allowed on secure workstations (or notebooks), there is no group that should be allowed this privilege. By removing all users and groups from this list, will help to secure the workstation from unwanted remote attackers. Obviously, this doesn't apply to workstations that also double as servers.

What consequences will there be on my system?

This will stop Remote Desktop logins and other terminal services through the network as there will be no users or groups that have privileges to terminal services.

Return

Who can backup files and directories

Why do this?

The ability to backup files and directories is extremely important to the long-term health of any computer system. The only problem is that combined with the ability to restore files, a user can make a backup of a file and restore it with access privileges. The ability to backup files supersedes the access privileges assigned to files. So a user with backup privileges can make a backup of a file to which they don't have regular access privileges. This is an obvious vulnerability because with a few more steps, a user can access a file they normally wouldn't have access to.

What consequences will there be on my system?

Part of an administrator's job could be to backup the system and restore files, should the need arise. Since the administrator already has privileges to access most files and directories on the system, it would not be a violation of privilege for the administrator to make backups. The only effect on the system would be that backups must be performed by the administrator, if this is not already the policy.

Return

Who can bypass traverse checking

Why do this?

Bypassing traverse checking means that a user can go through a part of the directory structure that they don't have access to to get to a part of the directory structure that they do have access to. For example if there is a folder C:\>windows\system32\config and the user has been denied access to the folder system32 but granted access to config, the user will be able to go through system32 to get to config. This option isn't particularly dangerous because the user will not be able to access anything in the denied folder, just pass through it. This could be a sign of improper access control administration so if there is a problem, it can serve as an alert to that fact.

What consequences will there be on my system?

This will have no effect on the system other than not allowing users to travel through directory trees to get to another directory. If this somehow affects their work, then they should be granted access to that directory tree, not the entire system.

Return

Who can change the system time

Why do this?

The ability to change system time by any user can affect Kerberos and other time critical functions. By allowing anyone to change this time, it is possible to thwart these functions. The administrator, who is in charge of the system, should be responsible for changing the time, should it need changing. Not only could changing the system time affect critical authentication systems, for example, it could be used to annoy other users. It would be aggravating if the clock were fifteen minutes behind which resulted in arriving late to an appointment.

What consequences will there be on my system?

This will simply allow the administrator to be the only one who can change the system time.

Return

Who can create a pagefile

Why do this?

The ability to create a pagefile introduces a number of vulnerabilities to the system. Users with pagefiles can modify them or remove them which can lead to system instability. A more severe problem that is introduced with pagefiles is that nothing stored in the files are encrypted. This allows an attacker to retrieve some valuable information about the system without having to decrypt it.

What consequences will there be on my system?

Only administrators will be allowed to create pagefiles and change their size.

Return

Who can create a token object

Why do this?

A created token object can be used to access all resources. It's obvious that the ability to give access privileges to anyone could be used to give an attacker privileges to compromise the entire system. Only the Local Security Authority should be allowed to create token objects that give users privileges.

What consequences will there be on my system?

Removing everyone from the list has no effect on the system. The Local Security Authority will create the objects as necessary, and the system will function normally.

Return

Who can create global objects

Why do this?

These global objects are used within Terminal Service sessions. Although some applications may require the use of global objects, they are also a security risk. This right should only be given to trusted users.

What consequences will there be on my system?

None Administrator accounts may experience problems with some applications, but this is unlikely. This will likely be no adverse effects on the system.

Return

Who can create permanent share objects

Why do this?

Permanent shared objects are used internally by kernel-mode operations. All components that need to create these objects have the rights already assigned to them, so adding anything to the list is unnecessary.

What consequences will there be on my system?

There will be no affect on the system because all rights have been already assigned to those components that need it.

Return

Who can debug programs

Why do this?

The ability to debug programs that are being run as other users presents a tremendous vulnerability. Attackers can use a technique called DLL injection to insert malicious code into the program being debugged which allows the attacker access to system components. The ability to debug programs that are running as other users should not be permitted in a secure environment, but if it is, the rights should be assigned to a particular group only. The ability to debug also opens up another problem. Sometimes the system state is saved if a program crashes to help programmers debug the problem. This information can be used to gather information about the system which can be used later in an attack.

What consequences will there be on my system?

When your computer runs into a stop error, information about the state of the machine will no longer be recorded.

Return

Explicitly deny access to computer from the network

Why do this?

The groups and users that are on this list will not be able to access the computer from the network. By placing people on this list, it provides further security against an attacker exploiting accounts from the network. Accounts that have been disabled should be found on this list, which will ensure greater security should they be turned back on again. This list supersedes the list allowing access to the computer from the network, so even if a group or user is found on both lists, they will be denied access. If no network access is required, it would be a good idea to place everyone on the list. The remote access that this list is concerned with is SMB (Server Messenger Block) which is available in many Microsoft operating systems.

What consequences will there be on my system?

All accounts that are found on this list will not be allowed to access the computer from the network.

Return

Who is denied logging on as a batch job

Why do this?

This allows a user to log in as a batch job. For example, a user can submit a job to the task scheduler and instead of that person being logged in interactively, they will be logged in as a batch job. This does allow a user to schedule programs to be executed by the task scheduler. A determination must be made as to which user(s) should be able to do this.

What consequences will there be on my system?

All accounts that are found on this list will not be allowed to be logged in as a batch job. These users won't be able to submit jobs to the task scheduler.

Return

Who is denied logging on as a service

Why do this?

This prevents a user from registering a process as a service. Service account passwords are saved on the hard drive in near plain-text. This means that the password could easily be recovered by an attacker trying to break into the computer.

What consequences will there be on my system?

Any user or group listed will not be able to register a process as a service. Some processes need to be registered as a service. If this occurs, a change may be necessary.

Return

Who is denied from logging on locally

Why do this?

This option can be used to specifically deny users the ability to login to the computer at the console. The main security feature with this user right is that unauthorized users will not be able to login to the computer. They must be removed from this list before they are able to login from the console. This doesn't, however, affect the use of the account with telnet, SMB, or