Udostępnij za pośrednictwem

AD DS: Fine-Grained Password Policies

  • Artykuł

Applies To: Windows Server 2008

The Windows Server® 2008 operating system provides organizations with a way to define different password and account lockout policies for different sets of users in a domain. In Microsoft® Windows® 2000 and Windows Server® 2003 Active Directory domains, only one password policy and account lockout policy could be applied to all users in the domain. These policies were specified in the Default Domain Policy for the domain. As a result, organizations that wanted different password and account lockout settings for different sets of users had to either create a password filter or deploy multiple domains. Both options are costly for different reasons.

What do fine-grained password policies do?

You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain.

For example, you can apply stricter settings to privileged accounts and less strict settings to the accounts of other users. In other cases, you might want to apply a special password policy for accounts whose passwords are synchronized with other data sources.

Who will be interested in this feature?

The following individuals should review this information about fine-grained password policies:

  • Information technology (IT) planners and analysts who are technically evaluating the product

  • Enterprise IT planners and designers for organizations

  • Administrators or managers who are responsible for IT security

Are there any special considerations?

Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups. By default, only members of the Domain Admins group can set fine-grained password policies. However, you can also delegate the ability to set these policies to other users. The domain functional level must be Windows Server 2008.

Fine-grained password policy cannot be applied to an organizational unit (OU) directly. To apply fine-grained password policy to users of an OU, you can use a shadow group.

A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this shadow group. You can create additional shadow groups for other OUs as needed. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups.

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.

What new functionality does this feature provide?

Storing fine-grained password policies

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

A Password Settings Container (PSC) is created by default under the System container in the domain. You can view it by using the Active Directory Users and Computers snap-in with advanced features enabled. It stores the Password Settings objects (PSOs) for that domain.

You cannot rename, move, or delete this container. Although you can create additional custom PSCs, they are not considered when the resultant set of policy (RSOP) is computed for an object. Therefore, they are not recommended. For more information about how the RSOP is computed, see "RSOP" later in this topic.

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:

  • Enforce password history

  • Maximum password age

  • Minimum password age

  • Minimum password length

  • Passwords must meet complexity requirements

  • Store passwords using reversible encryption

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

  • Account lockout duration

  • Account lockout threshold

  • Reset account lockout after

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

  • PSO link. This is a multivalued attribute that is linked to users and/or group objects.

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

These nine attributes are mustHave attributes. This means that you must define a value for each one. Settings from multiple PSOs cannot be merged.

Defining the scope of fine-grained password policies

A PSO can be linked to a user (or inetOrgPerson) or 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 settings that are applied are calculated by RSOP. For more information, see "RSOP" later in this topic.

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

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.

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

  1. Directly: PSO is linked to the user

  2. Indirectly: PSO is linked to group(s) that user is a member of

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

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

  1. A PSO that is linked directly to the user object is the resultant PSO. (Multiple PSOs should not be directly linked to a user object.)

  2. If no PSO is linked directly 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 precedence value is the resultant PSO.

  3. If no PSO is obtained from conditions (1) and (2), 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 conditions (1) and (2), the PSO with the smallest 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.

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

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 create an exceptional PSO and link it directly to that particular user. When msDS-ResultantPso for that user is calculated, the exceptional PSO that is linked directly to the user takes precedence over all other PSOs.

The user object has three bits 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). You can set these bits in the userAccountControl attribute of the user object:

  • Reversible password encryption required

  • Password not required

  • Password does not expire

These bits continue to override the settings in the resultant PSO that is applied to the user object.

Security and delegation

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 can delegate this permission to other groups or users.

You do not need permissions on the user or group object to be able to apply a PSO to it. Having Write permissions on the user or group object does not give you the ability to link a PSO to the user or group. The owner of a group does not have permissions to link a PSO to the group because the forward link is on the PSO. The power of linking a PSO to the group or user is given to the owner of the PSO.

The settings on the PSO may be considered confidential; therefore, by default Authenticated Users do not have Read Property permissions for a PSO. By default, only members of the Domain Admins group have Read Property permissions on default security descriptor of the PSO object in the schema.

You can delegate these permissions 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 only display the distinguished name of the PSO that applies to the user. The user cannot see the settings within that PSO.

How should I prepare to deploy this feature?

Before you can add a domain controller running Windows Server 2008 to an existing Active Directory domain, you must run adprep. When you run adprep, the Active Directory schema is extended to include the new object classes that fine-grained password policies require.

If you do not create fine-grained password policies for different sets of users, the Default Domain Policy settings apply to all users in the domain, just as they do in Windows 2000 and Windows Server 2003.

Is this feature available in all editions of Windows Server 2008?

Fine-grained password policies are available in all editions of Windows Server 2008.

Additional references

For information about how to implement AD DS Fine-Grained Password and Account Lockout Policy, see the AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkID=128039).