Developing a corporate security policy — whether it involves antivirus software, safe passwords or personal firewalls — means striking a balance between securing network resources and minimizing user inconvenience.
Part of designing a security policy in Windows is configuring the parameters associated with "account security."
Although systems administrators know the technical details, it is important for IT managers to know how they work so they can make the right decision when determining the configuration settings. Some decisions regarding security policies can compromise overall security because admins tend to favor the solution that solves the problem rather than the one that ensures system security.
These settings are defined in the security section of Group Policy and are referred to as "account policies." An important feature of the account policies is that they can be defined only at the domain level to be effective on domain accounts. That means you cannot define a password policy for individual organizational units. Everyone in the domain uses the same policy.
There is a way in Windows 2008 to apply it more granularly, however. Let's examine the settings of each of these policies, their effect on the overall security strategy and their recommended values.
Password policies define characteristics of a password:
Password history – This is the number of used passwords that can be stored before they can be reused again. For instance, if this value is set at 10, then the password needs to be set 10 times before it can be reused. This is a major pain for users as it regularly forces them to come up with new passwords, which they will likely forget. However some rotation of passwords is needed to make it hard to guess and to prevent reuse if the password is compromised.
Default setting: 24
Recommended setting: 10
Maximum password age – This is the maximum number of days that a password may be used before it is changed. Again, this is irritating for users because they must think up new passwords on a regular basis.
This value varies. The goal here is to set it to a low enough value to prevent giving a password cracker time to break the password, yet high enough to minimize the disruption to the user. The typical setting is between 60 and 90 days, although I've seen some set it as low as 40 days.
When combined with the password history, a setting of 90 days along with a history of 10 passwords, means it would be about three years before a user could use a password again, assuming the user waited the full 90 days before changing the password. Default setting: 42 Recommended setting: 60 to 90 days
This is probably the most common setting rather than "recommended." The longer it is, the less impact it will have on users. Sixty to 90 days is reasonable for a seven- to eight-character password.
Minimum password age – The age setting defines the minimum length of time in days that a password must be active before it can be changed. This prevents creative users from changing their passwords 10 times in a few minutes so they can keep their old passwords and effectively disable password history. In the worst-case scenario, if the minimum password age is set at 10 days and the password history is set at10 passwords, then it would require 100 days minimum to reuse a password. Default setting: 1 day Recommended setting: 1 day
Minimum password length--This is the number of characters required to be in a password and is directly responsible for the length of time it takes a password cracker to figure it out. This setting actually works with password complexity so that the password changes and the cracker must start the process all over again. Default setting: 8 characters Recommended setting: 8 characters
Password complexity – This setting forces the user to use a combination of characters. There are four types of characters recognized for "complexity," including uppercase letters, lowercase letters, numbers and special characters such as &, % and $. To meet the complexity requirement, a password must contain at least three of these features or the user will get an error stating it doesn't meet complexity requirements.
Default setting: Enabled
Recommended setting: Enabled
Store password with reversible encryption – This is for applications that require clear text passwords. Not many of them exist out there anymore.
Default setting: No
Recommended setting: No
Keeping hackers out with account lockout
When a wrong password is entered a certain number of times, the account is locked out and must be reset by the administrator. This foils hackers because even if they guess the password, the account won't work until it is reset and has a new password. It is intended as a secondary line of defense so that hackers can guess only a few combinations at a time.
But account lockout policies can also be frustrating for users and administrators alike. There are a number of normal conditions that will artificially inflate the badPasswordCount value and cause an account to lock out a valid user. Microsoft's account lockout best practices white paper covers those conditions.
For anyone who wants to use them, here are the guidelines:
Account lockout threshold – This is the number of failed password attempts allowed before the account is locked out.
Default setting: 0
This means account lockout is disabled. Leave it like this to keep account lockout turned off.
Recommended settings: If you want to enable it — High security: 10 to 20. Even applications that tend to lock out accounts can have bogus lockouts eliminated with this value.
Low security: 50. With this setting, it's unlikely any account would be locked out for a legitimate user.
Note: Setting this value to "not defined" actually sets the threshold to 5.
Lockout duration – This is the length of time the account must remain locked.
Lockout reset – This is the length of time until the account is automatically unlocked.
Default setting for duration and reset: Not defined
Recommended setting: Let the automatic calculation set it. When setting the threshold value, it will prompt you to accept the recommended values for these two settings. Accept the recommendations.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
This was first published in November 2007