Republished with permission from WatchGuard Technologies, Inc.


Securing XP Desktops:

Account and Auditing Policies

by David M. Piscitello, President, Core Competence, Inc.

If asked to name one of the most neglected security processes, I'd probably answer, "Securing user (client) computers." Organizations still struggle to find time, talent and budget to administer servers and security systems. The predictable result is that client computer security policy and implementation is often relegated to some of the least capable staff in your company: the users themselves. This is true for businesses in general, but especially true in small to medium businesses today.

Every organization can take measures to reduce the many risks poorly administered client computers create. Many companies manage the obvious ones (antivirus measures, personal firewall and especially VPN software) fairly well. Ironically, often the same companies that insist on "strongly authenticated tunnels" make little effort to assure that PCs configured with VPN adapters have equally strong user account and auditing policies. Let's look at ways to remedy this inconsistency using Windows XP.

Why these benchmarks?

In this article, I recommend specific security settings. Here's how I chose them.

The Center for Internet Security (CIS) has developed a set of security configuration benchmarks for Windows, Solaris, Linux and HP-UX systems, ranging from account and auditing policies to permissions for accessing file systems, running services, and accessing the configuration data (e.g., the Windows registry). These draw from the recommended best configuration practices of the NSA, Microsoft's best practices, and the accumulated expertise of security experts worldwide. CIS offers security templates for Windows 2000 (Professional and server) that codify its benchmarks in a format you can import through the Local Security Policy editor or the Security Configuration and Analysis Tool (a plug-in of the Microsoft Management Console). You can also develop a group policy template from CIS's templates, and distribute this to client machines using Active Directory. CIS is in the process of developing XP templates, so until they are available, I've extrapolated the security settings I recommend from the Windows 2000 Professional settings.

So, these settings represent more than my considered opinion alone. Ready to take a look? Here we go.

User Accounts and Windows XP Account Policies

Too many users operate client systems under the local administrator account. Too often, they don't bother to change the account name from the default (administrator), or even create a logon password. And users who log on as administrators can install unauthorized software, create file shares, and run unauthorized and unprotected services. If you provide company-owned computers to employees, you might conclude that granting users these freedoms is too great a risk. To help the user keep the computer available, and to prevent unlicensed, unstable, or potentially malicious software from being installed, create accounts for users in a Users Group, where access permissions will prevent them from making system-wide changes. From the Administrative Tools Control Panel (visible in Classic View), choose Computer Management => Local Users and Groups => Users. Highlight the Administrator account, right-click on it, rename it to something else, password protect it, and do not share it with system users. While you're here, disable guest and unwanted account(s), and make certain all authorized users must change passwords periodically. These actions won't make you popular, but you'll probably receive fewer helpdesk calls from users who took advantage of local administrator authority, only to mess up their own machines.

Once you've forced all accounts to use passwords, you can use Windows XP account policies to compel users to create passwords that are difficult to guess or crack. Account policies are accessed through the Local Security Policy editor, which is accessible from the start menu (Start =>Run => secpol.msc). You will also find it in the Administrative Tools folder.

Launch the editor, open Security Settings, and open the Account Policies folder. To meet the emerging consensus benchmark security configuration (see Why These Benchmarks?), change the security settings in the Password Policy folder to the following values:


Security Setting


Enforce password history

24 passwords remembered

Preventing users from re-using passwords and "root" information of previous passwords (e.g., piscitello1234, piscitello1235)

Maximum password age

42-90 days

Passwords should be changed with reasonable frequency

Minimum password age

1 day

Prevents users from cycling through the 24 passwords remembered so they can re-use their favorite password

Minimum password length

8-12 characters

8 is an acceptable minimum for users, but 12 is preferred for privileged (e.g., administrator) accounts

Passwords must meet complexity requirements


Users must create passwords using upper and lowercase alphabetic characters, numbers, and special characters to make passwords difficult to crack.

Store passwords using reversible encryption


This setting causes passwords to be encrypted using a one-way hash. Passwords can't be derived from the hash.

Next, change the security settings in the Account Lockout Policy folder to the following values. Cumulatively, these settings are intended to frustrate repeated attempts to guess an account and password:


Security Setting

Account Lockout Duration

15 Minutes

Account Lockout Threshold

3 Bad Login Attempts

Reset Account Lockout After

15 Minutes

(If your Account Lockout Duration says "Not applicable," it's because you haven't set the Account Lockout Threshold yet. Enter a number greater than zero in Account Lockout Threshold, then you can set the Duration.)

Admittedly, passwords are not the most desirable authentication method, but unless you deploy Kerberos for Windows Domain accounts or a third party authentication method (e.g., a token), it's worth your while to configure XP systems with password and account lockout policies that will help prevent unauthorized access.

Windows XP Auditing Policies

Auditing user activities is an essential complement to account administration. If you don't audit logon events, how can you know whether someone has attempted to break into your system, succeeded in adding an account, or has escalated privileges from Plain Old User to Administrator? Generally speaking, you should keep a log of security-related events that either forewarn or provide post-incident evidence of attacks or misuse of account privileges, on company-owned client systems as well as servers.

Using the Local Security Policy editor, you can direct Windows XP to record account activities in the Security Event Log. Launch the editor (Start => Run => secpol.msc), open Security Settings, and open the Local Policies folder. Open the Audit Policy and change these security settings, as follows:


Security Setting


Audit account logon events

Success, Failure

Records the result of every logon attempt using domain logon credentials.

Audit account management

Success, Failure

Records attempts to create, rename, enable, or disable users and groups and account passwords

Audit policy change

Failure only, or
Success and Failure

Records attempts to modify the audit policy and other security settings you've made

Audit privilege use

Failure only, or
Success and Failure

Records each time a user invokes a "privileged" operation on the system such as a Backup or Restore operation.

Audit object access

Failure only, or
Success and Failure

Use this in conjunction with security properties you set on individual files and folders to record user attempts to access those "objects"

Audit logon events

Success, Failure

Records the result of every logon attempt using a local logon credentials

Audit system events

Success and Failure

Records system shutdown and restart events, log full events, and other events that have system-wide significance.

Audit and other security related events are recorded in XP's Security Event Log. Protecting this log from unauthorized access and assuring that entries won't be overwritten are critical security configuration tasks. Go to Administrative Tools => Computer Management. Open System Tools, then open Event Viewer. Select Security with your right mouse button, and choose Properties. From the Properties Window, increase the default size of the Security Event log from 512 Kb to 80 Mb, and select Overwrite Events As Needed as the action to perform when the maximum log file size is exceeded. To restrict guest access to the log, you must edit the Registry (sorry!). Run Registry Editor (Start => Run => regedit) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog. Choose the Security subkey. Select the REG_DWORD RestrictGuestAccess, and set the value to one (1). If Restrict GuestAccess is not there, you must create it by right-clicking on Security, then choosing New => DWORD Value. The value is case sensitive, so capitalize the R, G, and A when typing RestrictGuestAccess.

While you're here, you can make the same change for the Application and System log subkeys as well.

'tis but the first step...

User account and auditing policies play an important role in securing client systems, and should not be neglected. Nor should logging, here as well as at your firewall! Considerably more can be done to secure Windows XP Professional. In upcoming articles, we'll consider user rights assignments, public key policies, and additional security options configurable through local security policies. ##


Microsoft TechNet

Center for Internet Security

Step-by-Step Guide to Securing Windows XP Professional in Small and Medium Businesses

LiveSecurity article: The Problem with Passwords

LiveSecurity article:

Microsoft Windows XP Security Guide Overview

Windows 2000 Default Security Policy Settings

Copyright© 2004, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.

Copyright © 1996 - 2004 WatchGuard Technologies, Inc. All rights reserved.