Export (0) Print
Expand All
27 out of 41 rated this helpful - Rate this topic

AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

Updated: August 20, 2012

Applies To: Windows Server 2008, Windows Server 2008 R2

This step-by-step guide provides instructions for configuring and applying fine-grained password and account lockout policies for different sets of users in Windows Server® 2008 domains.

In Microsoft® Windows® 2000 and Windows Server 2003 Active Directory domains, you could apply only one password and account lockout policy, which is specified in the domain's Default Domain Policy, to all users in the domain. As a result, if you wanted different password and account lockout settings for different sets of users, you had to either create a password filter or deploy multiple domains. Both options were costly for different reasons.

In Windows Server 2008, you can use fine-grained password policies to specify multiple password policies and apply different password restrictions and account lockout policies to different sets of users within a single domain. For example, to increase the security of privileged accounts, you can apply stricter settings to the privileged accounts and then apply less strict settings to the accounts of other users. Or in some cases, you may want to apply a special password policy for accounts whose passwords are synchronized with other data sources.

To store fine-grained password policies, Windows Server 2008 includes two new object classes in the Active Directory Domain Services (AD DS) schema:

  • Password Settings Container

  • Password Settings

The Password Settings Container (PSC) object class is created by default under the System container in the domain. It stores the Password Settings objects (PSOs) for that domain. You cannot rename, move, or delete this container.

For more information, see Appendix A: Fine-Grained Password and Account Lockout Policy Review.

This guide is intended for the following audiences:

  • Information technology (IT) planners and analysts who are evaluating the product from a technical perspective

  • Enterprise IT planners and designers for organizations

  • Administrator or managers who are responsible for IT security

Before you configure fine-grained password and account lockout policies, define your organizational structure by creating necessary groups and adding or moving users to or between the groups. It is important to consider the unique nature of your organization when you plan for the most efficient use of the fine-grained password and account lockout policies feature. How many different password policies do you need? A typical scenario might include 3 to 10 PSOs and the following password policies:

  • An Administrator password policy with a strict setting (passwords expire, for example, every 14 days)

  • An average user password policy with a setting that is not strict (passwords expire, for example, every 90 days)

  • A service account password policy targeted at service accounts (minimum password length, for example, 32 characters)

Taking advantage of your existing group structure is equally important. What are its characteristics? Do you have existing Administrators or Users groups? The goal is to shape your group structure so that it maps directly to the desired application of the newly defined fine-grained password and account lockout policies.

PSOs cannot be applied to organizational units (OUs) directly. If your users are organized into OUs, consider creating global security groups that contain the users from these OUs and then applying the newly defined fine-grained password and account lockout policies to them. If you move a user from one OU to another, you must update user memberships in the corresponding global security groups.

Applying PSOs directly to global security groups, as opposed to directly to OUs, provides the following benefits:

  • Groups offer better flexibility for managing various sets of users than OUs.

  • Most Active Directory deployments use a systematic group structure to organize their users. Also, by default AD DS in Windows Server 2008 creates various groups for administrative accounts: Domain Admins, Enterprise Admins, Schema Admins, Server Operators, Backup Operators, and others.

  • Group structure offers easier deployment of fine-grained password policies, and you do not have to restructure your organizations’ directories by creating OUs. Modifying an OU hierarchy requires detailed planning, and it increases the risk of introducing unforced errors because it has a significant effect on Group Policy application and access control list (ACL) inheritance.

  • Domain functional level: The domain functional level must be set to Windows Server 2008 or higher.

  • Permissions: By default, only members of the Domain Admins group can create PSOs. Only members of this group have the Create Child and Delete Child permissions on the Password Settings Container object. In addition, only members of the Domain Admins group have Write Property permissions on the PSO by default. Therefore, only members of the Domain Admins group can apply a PSO to a group or user. You do not have to have permissions on the user object or group object to be able to apply a PSO to it. To apply a PSO to the user object or group object, you must have Write permissions on the PSO object.

  • Permissions delegation: You can delegate Read Property permissions on the default security descriptor of the PSO object in the schema to any other group (such as Help desk personnel or a management application) in the domain or forest. This can also prevent a user from seeing his or her password settings in the directory. The user can read the msDS-ResultantPSO or the msDS-PSOApplied attributes, but these attributes display only the distinguished name of the PSO that applies to the user. The user cannot see the settings within that PSO. For more information, see Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies.

  • Applying fine-grained password policies: Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups. They cannot be applied to Computer objects.

    noteNote
    Because fine-grained password policies apply only to user objects, they do not affect password reset intervals for managed service accounts. For more information about managed service accounts, see Service Accounts Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=134695).

  • Password filters : Fine-grained password policies do not interfere with custom password filters that you might use in the same domain. Organizations that have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 can continue to use those password filters to enforce additional restrictions for passwords.

  • Custom PSCs: In addition to the default PSC, administrators can create their own custom PSCs under the System container. However, this action is not recommended because the PSOs that are held in these custom PSCs are not taken into consideration by the Resultant Set of Policy logic.

  • Exceptional PSOs: If you want a certain group member to conform to a policy that is different from the policy that is assigned to the entire group, you can assign the exceptional PSO directly to that particular user. If you apply a PSO directly to the user, it takes precedence over all implicit PSOs that might be linked to it when msDS-ResultantPSO for that user is being determined. Although not recommended as a practice, if two or more exceptional PSOs are applied directly to the user object, the resultant exceptional PSO is determined in the same manner as any PSO:

  • Password complexity errors on Windows XP® client computers: When a user to whom an FGPP applies attempts to change his or her password on a client computer that is running the Windows XP operating system, an error message appears, informing the user that the new password does not conform to the settings that are defined in the domain policy, instead of informing the user that the new password does not conform to the settings that are defined in the FGPP. The following illustration describes this error message:

    e2eda066-d362-4b51-8517-2ca39c9a48a4

The recommended approach is to ignore this error message and to make sure that the new password matches the minimum password length, password complexity, and password history requirements that are defined in the FGPP.

When the group structure of your organization is defined and implemented, you can configure and apply fine-grained password and account lockout policies to users and global security groups. Configuring fine-grained password and account lockout policies involves the following steps:

ImportantImportant
You can also manage fine-grained password and account lockout policies by creating corresponding global security groups for all existing PSOs and by assigning (delegating) appropriate permissions on these global security group objects to the selected users or groups from your organization, for example, support personnel. For more information, see Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies

For more information, see

Change History

 

Date Revision

Aug 20, 2012

Revised description of how the resultant exceptional PSO is determined when multiple exceptional PSOs are used.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.