This step-by-step guide details methods for defining strong password policies using Group Policy objects (GPOs) to extend the security of a computing environment.
| Introduction | |
| Overview | |
| Setting Password Policies with Group Policy Objects | |
| Additional Resources |
The Windows Server 2003 Deployment step-by-step guides provide hands-on experience for many common operating system configurations. The guides begin by establishing a common network infrastructure through the installation of Windows Server 2003, the configuration of Active Directory®, the installation of a Windows XP Professional workstation, and finally the addition of this workstation to a domain. Subsequent step-by-step guides assume that you have this common network infrastructure in place. If you do not want to follow this common network infrastructure, you will need to make appropriate modifications while using these guides.
The common network infrastructure requires the completion of the following guides.
| • | Part I: Installing Windows Server 2003 as a Domain Controller |
| • | Part II: Installing a Windows XP Professional Workstation and Connecting It to a Domain |
Once the common network infrastructure is configured, any of the additional step-by-step guides may be employed. Note that some step-by-step guides may have additional prerequisites above and beyond the common network infrastructure requirements. Any additional requirements will be noted in the specific step-by-step guide.
The Windows Server 2003 Deployment step-by-step guides may be implemented within a physical lab environment or through virtualization technologies like Microsoft Virtual PC 2004 or Microsoft Virtual Server 2005. Virtual machine technology enables customers to run multiple operating systems concurrently on a single physical server. Virtual PC 2004 and Virtual Server 2005 are designed to increase operational efficiency in software testing and development, legacy application migration, and server consolidation scenarios.
The Windows Server 2003 Deployment step-by-step guides assume that all configurations will occur within a physical lab environment, although most configurations can be applied to a virtual environment without modification.
Applying the concepts provided in these step-by-step guides to a virtual environment is beyond the scope of this document.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, places, or events is intended or should be inferred.
This common infrastructure is designed for use on a private network. The fictitious company name and Domain Name System (DNS) name used in the common infrastructure are not registered for use on the Internet. You should not use this name on a public network or Internet.
The Active Directory service structure for this common infrastructure is designed to show how Windows Server 2003 Change and Configuration Management works and functions with Active Directory. It was not designed as a model for configuring Active Directory for any organization.
Most users log on to their local or remote computers by using a combination of their user name and a password typed at the keyboard. Although alternative technologies for authentication, such as biometrics, smart cards, and one-time passwords, are available for all popular operating systems, most organizations still rely on traditional passwords and will continue to do so for years to come. Therefore, it is important that organizations define and enforce password policies for their computers that include mandating the use of strong passwords.
Strong passwords meet a number of requirements for complexity-including length and character categories-that make passwords more difficult for hackers to determine. Establishing strong password policies for your organization can help prevent hackers from impersonating users and can thereby help prevent the loss, exposure, or corruption of sensitive information.
Depending on whether the computers in your organization are members of an Active Directory domain, stand-alone computers, or both, to implement strong password policies, you will need to perform one or both of the following tasks.
| • | Configure password policy settings in an Active Directory domain. |
| • | Configure password policy settings on stand-alone computers. |
This document explains how to configure password policy settings on members of an Active Directory domain through GPOs.
Once you have configured the appropriate password policy settings, users in your organization will be able to create new passwords only if the passwords meet the length and complexity requirements for strong passwords, and users will not be able to immediately change their new passwords.
| • | Part 1: Installing Windows Server 2003 as a Domain Controller |
| • | |
| • | Step-by-Step Guide to Understanding the Group Policy Feature Set |
| • | Credentials: You must be logged on as a member of the Domain Admins group to complete these exercises. |
Before configuring password policies on the computers in your network, you need to identify what settings are relevant, determine what values you will use for those settings, and understand how Windows stores password policy configuration information.
Note: The Windows 95, Windows 98, and Windows Millennium Edition operating systems do not support advanced security features such as password policies. If your network includes stand-alone computers (computers that do not belong to a domain) running these operating systems, you will not be able to enforce password policies on them. If your network includes computers running these operating systems that are members of an Active Directory domain, you will be able to enforce password policies at the domain-level only.
For Windows 2000, Windows XP, and Windows Server 2003, six settings can be configured that relate to password characteristics: Enforce password history, Maximum password age, Minimum password age, Minimum password length, Passwords must meet complexity requirements, and Store passwords using reversible encryption. For help in determining values for these settings that match the business requirements of your organization, see Selecting Secure Passwords on the Microsoft Security Guidance Web site.
| • | Enforce password history determines the number of unique new passwords a user must use before an old password can be reused. The value of this setting can be between 0 and 24; if it is set to 0, enforce password history is disabled. For most organizations, this value should be set to 24 passwords. | ||||||||||||||||||||
| • | Maximum password age determines how many days a password can be used before the user is required to change it. The value of this setting can be between 0 and 999; if it is set to 0, passwords never expire. Setting this value too low can cause users to be frustrated; setting it too high or disabling it gives potential hackers more time to determine passwords. For most organizations, this value should be set to 42 days. | ||||||||||||||||||||
| • | Minimum password age determines how many days a new password must be kept before the user can change it. This setting is designed to work with the Enforce password history setting so that users cannot quickly reset their passwords the required number of times, and then change back to their old passwords. The value of this setting can be between 0 and 999; if it is set to 0, users can immediately change new passwords. It is recommended that you set this value to 2 days. | ||||||||||||||||||||
| • | Minimum password length determines the minimum number of characters a password can have. Although Windows 2000, Windows XP, and Windows Server 2003 support passwords up to 28 characters in length, the value of this setting can only be between 0 and 14. If it is set to 0, users are allowed to have blank passwords, so you should not use a value of 0. It is recommended that you set this value to 8 characters. | ||||||||||||||||||||
| • | Passwords must meet complexity requirements determines whether password complexity is enforced. If this setting is enabled, user passwords meet the following requirements:
| ||||||||||||||||||||
| • | Store passwords using reversible encryption provides support for applications that use protocols that require knowledge of the user's password for authentication purposes. Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information.
|
Before implementing password policies, you need to understand how password policy configuration information is stored. This is because the mechanisms for storing password policy limit the number of different password policies you can implement and affect how you apply your password policy settings.
There can be only a single password policy for each account database. An Active Directory domain is considered a single account database, as is the local account database on stand-alone computers. Computers that are members of a domain also have a local account database, but most organizations that have deployed Active Directory domains require their users to log on to their computers and the network by using domain-based accounts. Consequently, if you specify a minimum password length of 14 characters for a domain, all users in the domain must use passwords of 14 or more characters when they create new passwords. To establish different requirements for a specific set of users, you must create a new domain for their accounts.
Active Directory domains use GPOs to store a wide variety of configuration information, including password policy settings. Although Active Directory is a hierarchical directory service that supports multiple levels of organizational units (OUs) and multiple GPOs, password policy settings for the domain must be defined in the root container for the domain. When the first domain controller is created for a new Active Directory domain, two GPOs are automatically created: the Default Domain Policy GPO and the Default Domain Controller Policy GPO. Default Domain Policy is linked to the root container. It contains a few critical domain-wide settings including the default password policy settings. Default Domain Controller Policy is linked to the Domain Controllers OU and contains initial security settings for domain controllers.
It is a best practice to avoid modifying these built-in GPOs. If you need to apply password policy settings that diverge from the default settings, you should create a new GPO instead and link it to the root container for the domain, or to the Domain Controllers OU and assign it a higher priority than the built-in GPO. If two GPOs that have conflicting settings are linked to the same container, the one with higher priority takes precedence.
This section provides step-by-step instructions for enhancing security by implementing password policy settings on the computers in your organization.
To create a new root domain Group Policy object
1. | Click the Start button, select AllPrograms, select AdministrativeTools, and then click GPWalkThrough. Note: The GPWalkThrough Microsoft Management Console (MMC) was created in the Step-by-Step Guide to Understanding the Group Policy Feature Set. If you have not completed the steps in that guide, you will need to modify the following steps accordingly. |
2. | In the GPWalkThrough MMC console, expand Active Directory Users and Computers, right-click contoso.com, click Properties, and then click the Group Policy tab. Note: Microsoft recommends that you create a new GPO rather than editing the built-in one called Default Domain Policy. By doing this, it is much easier to recover from serious problems with security settings. If the new security settings create problems, you can temporarily disable the new GPO until you isolate the settings that caused the problems. |
3. | Click New and type DomainPasswordPolicy for the GPO name as shown in Figure 1. ![]() Figure 1. Creating a Root Domain GPO |
4. | Press Enter. |
To enforce the Domain Password Policy GPO
Note: For a thorough discussion about Group Policy inheritance and more information about the following steps, see the Step-by-Step Guide to Understanding the Group Policy Feature Set.
1. | On the contoso.com Properties page, click to highlight the DomainPasswordPolicy, and then click the UP button. |
2. | On the contoso.com Properties page, right-click the Domain Password Policy, and then click No Override. The contoso.com Properties page should appear as shown in Figure 2. ![]() Figure 2. Establishing GPO Precedence |
To define password use policies
1. | On the contoso.com Properties page, double-click the Domain Password Policy. |
2. | In the Group Policy Object Editor and under Computer Configuration, expand Windows Settings, expand Security Settings, expand Account Policies, and then click Password Policies. |
3. | In the details pane, double-click Enforce password history, select the Define this policy setting check box, set the value of Keep password history to 24, and then click OK. |
4. | In the details pane, double-click Maximum password age, select the Define this policy setting check box, set the value of Password will expire in to 42, click OK, and then click OK to accept a suggested value change for the Minimum password age. |
5. | In the details pane, double-click Minimum password age, set the value of Password can be changed after to 2, and then click OK. |
6. | In the details pane, double-click Minimum password length, select the Define this policy setting check box, set the value of Password must be at least to 8, and then click OK. |
7. | In the details pane, double-click Password must meet complexity requirements, select the Define this policy setting in the template check box, select Enabled, and then click OK. |
8. | In the details pane, double-click Store passwords using reversible encryption, select the Define this policy setting in the template check box, select Disabled (default), and then click OK. The settings should appear as shown in Figure 3. |
To require password-secured screen savers
1. | In the Group Policy Object Editor, collapse Computer Configuration, under User Configuration, expand Administrative Templates, expand Control Panel, and then click Display. |
2. | Optional Setting: In the details pane, double-click Screen Saver executable name, select Enabled, type scrnsave.scr for the Screen Saver executable name, and then click OK. Note: Defining a screen saver executable name is an optional setting defined here for performance considerations. In Windows Server 2003 where core computing services are provided, screen savers may consume unnecessary processing power when enabled, thereby limiting resources available for organizational computing needs. If screen savers are to be deployed on servers, it is highly recommended that the blank screen saver (scrnsave.scr) be used. You may consider creating an additional GPO under the Domain Controllers container that defines the Screen Saver executable name setting. |
3. | In the details pane, double-click Password protect the screen saver, select Enabled, type scrnsave.scr for the Screen Saver executable name, and then click OK. The settings should appear as shown in Figure 4. ![]() Figure 4. Confirming a Domain Screen Saver |
4. | In the Group Policy Object Editor, click File, and then click Exit. Click Close in the contoso.comProperties page. Click File, and then click Exit to close Active Directory Users and Computers. If prompted, click Yes to save the GPWalkThrough MMC. |
To verify password-secured screen savers
1. | Click the Start button, click Run, type gpupdate /force, and then click OK. Note: Gpupdate refreshes local and Active Directory-based Group Policy settings, including security settings. The force option ignores all processing optimizations and reapplies all settings. |
2. | Right-click the Desktop, click Properties, and then click the Screen Saver tab. The Screen saver name should be Blank and the On resume, password protect check box should be selected. Both items should be grayed out as shown in Figure 5. ![]() Figure 5. Verifying a Password-Secured Screen Saver |
3. | Click Cancel. |
For more information, see the following resources.
| • | Selecting Secure Passwords in the Security Guidance Kit at http://www.microsoft.com/smallbusiness/support/articles/select_sec_passwords.mspx |
| • | Windows Server 2003 Account Passwords and Policies at http://www.microsoft.com/technet/prodtechnol/ |
| • | For the latest information about Windows Server 2003, see the Windows Server 2003 Web site at http://www.microsoft.com/windowsserver2003 |