Multiple Password Policies in an Active Directory Environment

You are here:
< Back

Goal / Scope

This information will identify the proper process for implementing fine-grain password polices, or implementing several different password policies in a single Active Directory domain.  By default, only a single password policy can only be set per domain.  Beginning in Windows 2008 Active Directory domains, the ability to set several password policies was enabled.  The process is not straight forward.

Background

The new functionality Fine-grained password policies can provide are leveraged by the following changes to the Active Directory Domain Services schema:

  • A Password Settings Container (PSC) is created by default under the System container.  This container stores the Password Settings objects (PSOs) for the domain
  • Password Settings (PSO) is the object that contains the attributes for all the settings that can be modified in regards to passwords.  The following are the settings that can be used:
    • Enforce password history
    • Maximum password age
    • Minimum password age
    • Minimum password length
    • Passwords must meet complexity requirements
    • Store passwords using reversible encryption

There are also attributes for account lockout settings shown below:

    • Account lockout duration
    • Account lockout threshold
    • Reset account lockout after

In addition to these attributes, the PSO also has the following new attributes:

  • PSO link

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

The PSO link can be found in the attribute named msDS-PSOAppliesTo, and it is a multivalued attribute which means you can apply a PSO to multiple users or groups. When troubleshooting a PSO, it is important to note that all user and group objects in Windows Server 2008 domain now have an attribute called msDS-PSOApplied and it contains the value of the PSO which is applied to the user or group object.

  • Precedence

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

Precedence is determined by the msDS-PasswordSettingsPrecedence attribute of the PSO if all else is equal.  The following is a guide that can be used to determine how PSOs are determined and applied:

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

Methodology / Process Steps

In order to correctly set a password policy, at first glance it may be a temptation to use Active Directory Group Policy.  In fact, the default password policy for a domain is set using the default domain policy.  However, building and implementing, even enforcing a Group Policy object with password policy settings enabled will do nothing to update the password policy for the objects it applies to. There are a couple of considerations to note before starting to work with fine-grained password policies:

  • Fine-grained password policies can only be applied to user objects and global security groups
  • Only members of the Domain Admins group can set policies by default, other users can be delegated this right
  • The domain functional level must be at least Windows Server 2008
  • Fine-grained password policies can not be applied to an organizational unit directly (shadow groups can be used)
  • Fine-grained password policies do not interfere with custom password filters potentially used in the same domain.  Custom password filters may have been deployed to domain controllers running Windows 2000 or Windows Server 2003 and these filters can continue to be used to enforce additional restrictions for passwords.

Creating a PSO

There are a couple of methods for viewing and modifying PSOs but only 1 way to create them.  ADSI edit is the tool necessary to create PSOs. Once ADSI edit is open, right click “ADSI edit” in the left hand pane and select “Connect to…” from the menu.

ADSI Edit Connection Menu

This will open a dialog window that will allow you to choose the connection.  Default Naming Context should be selected, all other options can be left as defaults.

ADSI Edit Connection Settings Window

Once this window is open, clicking on the items in the tree reveal anything that is listed below the item.  So clicking on Default naming context [domain name] should reveal a plus [+] next to the item, and clicking on this [+} will expand the list below.  Click on DC=[domainname] below default naming context to reveal the [+] and click it to expand the list of items below it.  Now locate CN=System and under that CN=Password Settings Container.

ADSI Edit Tree View

This is the location of the PSOs.  It should be empty by default.  Right clicking the middle pane and selecting “new” and then “Object” from the list will allow creation of a new PSO.

ADSI Edit Create New PSO Menu

Below is an example of an Existing PSO.

ADSI Edit PSO list

When “New” and then “Object” is selected a wizard runs.  This wizard asks a number of questions and requires that all the questions are answered before finishing the creation of the new PSO.

The following are screenshots of the different choices that need to be made to complete the creation of the PSO.

Initially it is going to show the class types of the policy object that can be created shown below.

ADSI Edit Create PSO Window

In this case, only 1 type of class can be selected, clicking next will move to the next step.

In the next step, a name must be selected for the password policy.

ADSI Edit Name PSO

The next step requests the precedence.  This will be important when determining which policy will be applied when using group membership.

ADSI Edit Set Precedence

The next step sets the store passwords using reversible encryption option and takes a boolean (true or false)

ADSI Edit Store Passwords Reverse

The next step configures the option for password history length, meaning “How many passwords would you like the system to remember and prevent the password from being set to these.”

ADSI Edit Password History

The next step is password complexity.  This is another boolean input, either true or false.  This sets default password complexity rules of the following:

  • Passwords must not contain the user’s entire samAccountName (Account Name) value or entire displayName (Full Name) value.  Both checks are not case sensitive.
    • The samAccountName is checked in its entirety only to determine whether it is part of the password.  If the samAccountName is less than three characters long, this check is skipped.
    • The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs.  If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password.  Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked.  For example, the name “Erin M. Hagens” is split into three tokens: “Erin,” “M,” and “Hagens.”  Because the second token is only one character long, it is ignored.  Therefore this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password.
  • Passwords must contain characters from three of the following five categories:
    • Uppercase characters (A – Z)
    • Lowercase characters (a – z)
    • Base 10 digits (0 – 9)
    • Nonalphanumeric characters: (~!@#$%^&*()-_+=`|\[]{}:;”‘<>,.?/)
    • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase.

ADSI Edit Password Complexity

The next step is setting the minimum password length.

ADSI Edit Password Length

The next step is setting the minimum password age.  This option sets how much time needs to pass before a password can be changed once a password has been changed.  The input of this option is the following format:

0:00:00:00, where the first 0 is the number of days, the second section is the number of hours, the 3rd section is the number of minutes and finally the last section is the number of seconds.  In this example, 1:00:00:00 is configured for the value of 1 day.

ADSI Edit Minimum Password Age

The next step sets the maximum password age, or the length of time before a password needs to be changed, and is in the same format as the minimum password age (0:00:00:00)

ADSI Edit Max Password Age

The next step is defining the lockout policy.  How many attempts can be made before the account is locked out.

ADSI Edit Lockout

The next step is to set the lockout duration time.  This setting defines how long the lockout of the account will last.  This setting is again formatted as the examples above (0:00:00:00)

ADSI Edit Lockout Duration

The final step is accepting what was created and completing the PSO.

ADSI Edit PSO Wizard Final Window

There is an option / button to modify other attributes, but these base attributes will be enough for most scenarios.

The final step is to apply the newly created PSO to a user or group.  This can be completed by right clicking the newly created PSO, and selecting “Properties”.  This will bring up the attribute editor window.   Locate the “msDS-PSOAppliesTo” attribute select it and click the edit button.

ADSI Edit PSO AppliesTo

This will allow the addition of the user or global security group.  This completes a setup of a fine-grain password policy for windows 2008 or later.

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions. Problem: | The password policy was assigned to a security group and accounts have been added to the security group, but the policy is not being applied to these accounts. Solution: | The most likely reason for this to occur is if the security group is not a global group.  If a universal or domain local group is used, it will fail to apply the password policy.  NOTE:  It is possible to link a PSO to other types of groups and objects in the domain, 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 any other type of objects will be ignored. Problem: | A password policy seems to be applied, but it is not the right policy or the setting don’t match what is expected. Solution: | The precedence values could be playing a role in this scenario.  Verify the attribute named msDS-PasswordSettingsPrecedence.  The key to this attribute is as follows:  The lower the number the higher the precedence to other PSOs.  Example:  2 PSOs are created and have been applied to  a user object via group membership.  The names of the groups are PasswordsA and PasswordsB respectively.  The preferred PSO or PSO that is expected is the PSO associated with the PasswordsA group.  However, this PSO has a msDS-PasswordSettingsPrecedence of 5 and the PSO associated with the group PasswordsB has a msDS-PasswordSettingsPrecedence of 2.  Due to the fact the PSO associated with the PasswordsB group has a lower msDS-PasswordSettingsPrecedence value, it will be the PSO applied to the user.

References

Setup Fine-grain password policy
http://www.grouppolicy.biz/2011/08/tutorial-how-to-setup-default-and-fine-grain-password-policy/

Fine-grain password policies
http://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx

Passwords must meet complexity requirements
http://technet.microsoft.com/en-us/library/cc786468(v=ws.10).aspx

Last Updated On October 24, 2017