Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


September 2002

Password Defense

Using password security policies to strengthen security
RSS
Subscribe to Windows IT Pro | See More Security Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

Every user account on your network needs a password, although Windows 2000 permits user logons with null passwords. After you decide to enforce password usage, you need to determine the password policies you want to enforce. You can set password policies for a domain or for an individual computer; setting a password for an individual computer is useful when you have machines that are in vulnerable locations or that hold sensitive data. Unfortunately, Win2K doesn't let you set policies on a group-by-group basis, only by domain or machine.

To view or manipulate password policies for a domain, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and right-click the domain object in the Console pane. Choose Properties from the shortcut menu to open the domain object's Properties dialog box, then select the Group Policy tab. Select the Default Domain Policy GPO link, and click Edit. Then, expand the default domain policy object to \computer configuration\windows settings\security settings\account policies\password policy. As Figure 1 shows, the Policy pane lists the available domain policies (the same policies exist for local computers). To change the current status of a domain policy (by default, domain password security policies aren't defined), double-click the policy listing to bring up the Security Policy Setting dialog box, and select the Define this policy setting check box.

Unlike domain password security policies, password security policies for individual computers are always defined by default. However, the default settings don't impose any security in addition to the domain policy. Moreover, any policy you've set for the domain overrides any policy you've set for the PC. If you've set a policy for the computer and the domain policy remains undefined, the effective policy is the computer policy. If you've set policies for both the domain and the computer, the effective policy is the domain policy. When you set a new policy for a PC, you need to restart the computer to put the policy and its security settings into effect. After restart, you can see the changes you made in the Local Security Settings window. As Figure 2, page 66, shows, the local policy Enforce password history is the effective policy, which means that no domain policy is overriding the local setting. The following password security policies are available:

  • Enforce password history denies users the ability to reuse a password that they've used previously. The number you specify for this policy is the number of unique passwords a user must use before reusing a previous password. You can enter a number between 1 and 24 (0 means the policy is disabled).
  • Maximum password age determines how often users must change passwords. The available options range from 1 day to 999 days.
  • Minimum password age determines the minimum number of days (1 day to 999 days) a password must be in effect before a user can change it.
  • Minimum password length determines the minimum number of characters for a password. The available options are 1 to 14 characters; a setting of 0 means the policy is disabled.
  • Passwords must meet complexity requirements, a policy also known as "strong passwords," is a powerful password security tool. For details, see the section "Using Strong Passwords."
  • Store password using reversible encryption for all users in the domain weakens, rather than strengthens, passwords. If you enable this policy, then user passwords are stored in clear text in Active Directory (AD), and anybody can read them. This policy exists to support applications that require knowledge of the user password; the most common example is the AppleTalk protocol. Unless your domain consists entirely of Macintosh computers, this policy is dangerous to set across the domain. Instead, apply this policy on a user-by-user basis by opening the appropriate user account object in Active Directory Users and Computers. By enabling this policy in each user's Account tab, the setting will affect only specified users instead of the entire domain.

Regardless of the domain policies you set, you can also set the User must change password at next logon, User cannot change password, Password never expires, and Store password using reversible encryption policies for any individual user by configuring the Account tab of the user's Properties dialog box. Those individual-user policies override domain policies.

Some password security policies are interdependent, and others are mutually exclusive. For example, if you permit password changes immediately by not setting a minimum password age, you can't select the Enforce password history option. If you want to permit blank passwords, you can't set a minimum password length. And if you use Enforce password history to specify the number of passwords people must use before they can employ a previous password, you must also specify a number of days in the Minimum password age section of the Security Policy Setting dialog box.

Even if you don't enable the strongest password security policies available, you need to develop a procedure for determining passwords and distribute instructions to your users. For example, set a rule that every password must contain both numbers and letters. Or tell users to avoid using any part of their names in their passwords. Users with access rights to sensitive material (e.g., company payroll records) need to avoid using any recognizable phrase in their passwords so that other staff members can't guess the password. These recognizable phrases include numbers that refer to birthdays, names of spouses or family pets, or any other references that coworkers might know.

   Previous  [1]  2  Next 


Top Viewed ArticlesView all articles
Battery Life Issues Almost Certainly Not Windows 7's Fault

While Microsoft is still investigating a notebook battery life issue that was supposedly caused by Windows 7, some interesting trends have emerged. ...

Confirmed: Battery Life Issues Not Windows 7's Fault

Microsoft on Monday issued a lengthy statement about the recent Windows 7 battery controversy, echoing my assessment from earlier in the day, but backing it up with hard, cold evidence. ...

Getting your iPhone to Sync with Exchange 2003

Follow these steps to use an iPhone with Exchange. ...


Security Whitepapers Reducing the Costs and Risks of Branch Office Data Protection

Solving Desktop Management Challenges in Healthcare

Solving Desktop Management Challenges in Education

Related Events The Increasing Threat of Financially Motivated Data Theft

Deep Dive into Windows Server 2008 R2 presented by John Savill

Introduction to Identity Lifecycle Manager "2"

Check out our list of Free Email Newsletters!

Security eBooks Spam Fighting and Email Security for the 21st Century

Understanding and Leveraging Code Signing Technologies

A Guide to Windows Certification and Public Keys

Related Security Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2010 Penton Media, Inc. Terms of Use | Privacy Statement