Appendix A: Fine-Grained Password and Account Lockout Policy Review

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

Storing fine-grained password policies

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

  • 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.

A PSO has attributes for all the settings that can be defined in the Default Domain Policy (except Kerberos settings). These settings include attributes for the following password settings. Attribute names appear in parentheses.

  • Enforce password history (msDS-PasswordHistoryLength)

  • Maximum password age (msDS-MaximumPasswordAge)

  • Minimum password age (msDS-MinimumPasswordAge)

  • Minimum password length (msDS-MinimumPasswordLength)

  • Passwords must meet complexity requirements (msDS-Password-ComplexityEnabled)

  • Store passwords using reversible encryption (msDS-PasswordReversibleEncryptionEnabled)

These settings also include attributes for the following account lockout settings:

  • Account lockout duration (msDS-LockoutDuration)

  • Account lockout threshold (msDS-LockoutThreshold)

  • Reset account lockout counter after (msDS-LockoutObservationWindow)

In addition, a PSO has the following two new attributes:

  • PSO link (msDS-PSOAppliesTo). This is a multivalued attribute that is linked to users and group objects.

  • Precedence (msDS-PasswordSettingsPrecedence). This is an integer value that is used to resolve conflicts if multiple PSOs are applied to a user or group object.

All attributes except msDS-PSOAppliesTo are mustHave attributes. This means that you must define a value for each one. Settings from multiple PSOs cannot be merged.

The following illustration shows the storage location of the PSOs in a given domain and the method for calculating the resultant PSO that is eventually applied to the user accounts.

For more information about password policies and account lockout settings, see Password Policy.

Defining the scope of fine-grained password policies

A PSO can be linked to a user (or inetOrgPerson) or a group object that is in the same domain as the PSO:

  • A PSO has an attribute named msDS-PSOAppliesTo that contains a forward link to only user or group objects. The msDS-PSOAppliesTo attribute is multivalued, which means that you can apply a PSO to multiple users or groups. You can create one password policy and apply it to different sets of users or groups.

  • A new attribute named msDS-PSOApplied has been added to the user and group objects in Windows Server 2008. The msDS-PSOApplied attribute contains a back-link to the PSO. Because the msDS-PSOApplied attribute has a back-link, a user or group can have multiple PSOs applied to it. In this case, the Resultant Set of Policy (RSOP), represented by the new msDS-ResultantPSO attribute, must be calculated for that user. For more information, see "The logic behind precedence: calculating RSOP."

You can link a PSO to other types of groups in addition to global security groups. However, when the RSOP for a user object is being determined, only those PSOs that are directly linked to the user object or to the global security groups that the user is a member of are considered. PSOs that are linked to distribution groups or other types of security groups are ignored.

The logic behind precedence: calculating RSOP

A user or group object can have multiple PSOs linked to it, either because of membership in multiple groups that each have different PSOs applied to them or because multiple PSOs are applied to the object directly. However, only one PSO can be applied as the effective password policy. Only the settings from that PSO can affect the user or group. The settings from other PSOs that are linked to the user or group cannot be merged in any way.

RSOP can be calculated only for a user object. The PSO can be applied to a user object in either of the following two ways:

  • Directly: The PSO is linked to the user.

  • Indirectly: The PSO is linked to groups that the user is a member of.

Each PSO has an additional attribute named msDS-PasswordSettingsPrecedence that assists in the calculation of RSOP. The msDS-PasswordSettingsPrecedence attribute has an integer value of 1 or greater. A lower value for the msDS-PasswordSettingsPrecedence attribute indicates that the PSO has a higher rank, or a higher priority, than other PSOs. For example, suppose that an object has two PSOs linked to it. One PSO has a msDS-PasswordSettingsPrecedence value of 20, and the other PSO has a msDS-PasswordSettingsPrecedence value of 40. In this case, the PSO that has the msDS-PasswordSettingsPrecedence value of 20 has a higher rank. Therefore, it is applied to the object.

Important

If multiple PSOs are linked to a user or group, the resultant PSO that is applied is determined as follows:

  • A PSO that is linked directly to the user object is the resultant PSO. If no PSO is linked to the user object, the global security group memberships of the user—and all PSOs that are applicable to the user based on those global group memberships—are compared. The PSO with the lowest msDS-PasswordSettingsPrecedence value is the resultant PSO.

  • If no PSO is obtained from the preceding conditions, the Default Domain Policy is applied.

We recommend that you assign a unique msDS-PasswordSettingsPrecedence value for each PSO that you create. However, you can create multiple PSOs with the same msDS-PasswordSettingsPrecedence value. If multiple PSOs with the same msDS-PasswordSettingsPrecedence value are obtained for a user from the preceding conditions, the PSO with the smallest globally unique identifier (GUID) is applied.

In order to determine the smallest GUID, the GUIDs are compared at the byte level. The right-most byte of the first portion of the GUID is compared first. For example, suppose that two PSOs with the following GUIDs have the same msDS-PasswordSettingsPrecedence value:

  1. d1742912-87cd-4172-ac6e-ad1e94965e6b

  2. 7b41e54e-a075-4a4d-869d-0b0e1433de89

Although you might think that PSO #2 will be applied since 7b comes before d1 numerically, PSO #1 will be applied because the memory comparison operation compares the right-most byte of the first portion of the GUID, and 12 is lower than 4e. To help prevent unexpected results, do not apply the same msDS-PasswordSettingsPrecedence value to different PSOs.

A new attribute named msDS-ResultantPSO has been added to the user object. An administrator can query on this attribute to retrieve the distinguished name of the PSO that is ultimately applied to that user (based on the rules listed previously). If there is no PSO object that applies to the user, either directly or by virtue of group membership, the query returns the NULL value.

The user object has three bits, which can be set in the userAccountControl attribute of the user object, that override the settings that are present in the resultant PSO (much as these bits override the settings in the Default Domain Policy in Windows 2000 and Windows Server 2003):

  • Reversible password encryption required

  • Password not required

  • Password does not expire

Important

It is recommended to apply PSOs to group objects as opposed to user objects directly because of the constraint of the msDS-PSOApplied user or group attribute that is especially problematic when you copy a user or a group object. The constraint of the msDS-PSOApplied attribute is that when you copy a user or a group object, its msDS-PSOApplied attribute is not also copied. As stated previously, in Windows Server 2008, a user or group can have multiple PSOs applied to it since the msDS-PSOApplied attribute of the user and group objects has a back-link to the PSO. Consider the following scenario: an administrator copies “User1” user account (a member of “Group1” group) to create a new “User2” user account which he also wants to be a member of “Group1”. “Group1” has a PSO “PSO_Group” applied to it in which msDS-PasswordComplexityEnabled attribute is set to FALSE. “User1” has a PSO “PSO_User” applied to it in which msDS-PasswordComplexityEnabled attribute is set to TRUE. Since “PSO_User” is applied directly to the user object, it has a higher rank than “PSO_Group” (applied to a group object) and is therefore the resultant PSO for “User1”. When the administrator copies “User1” in order to create a new user account “User2”, he wants “PSO_User” to also be applied to ”User2”. However, since the msDS-PSOApplied attribute is not copied for “User2” and yet the group membership to “Group1” is copied by default, “User”2 ends up with the resultant PSO of “PSO_Group” (with the msDS-PasswordComplexityEnabled attribute set to FALSE) which will cause “User2” account to silently fail to comply with the required security policies.