While deploying an Active Directory (AD) password policy is technically easy, most of the time, the proper planning and design are not considered. Therefore, the expected results of the policy are not always obtained.

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.

There are, at the most basic level, five settings you can configure that relate to password characteristics: Enforce password history, Maximum password age, Minimum password age, Minimum password length, and Passwords must meet complexity requirements. 

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 this value is set to 0, enforce password history is disabled.

Maximum password age determines how many days a password can be used before the user is required to change it. The value of this is between 0 and 999; if it is set to 0, passwords never expire. Setting this value too low can cause frustration for your users; setting it too high or disabling it gives potential attackers more time to determine passwords.

Minimum password age determines how many days a user must keep new passwords before they can change them. 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.

Minimum password length determines how short passwords can be.

Passwords must meet complexity requirements determines whether password complexity is enforced. If this setting is enabled, user passwords meet the following requirements:

  • The password is at least six characters long. The password contains characters from at least three of the following four categories: English uppercase characters (A – Z)English lowercase characters (a – z)Base 10 digits (0 – 9)Non-alphanumeric (For example: !, $, #, or %) The password does not contain the user’s entire Account Name or entire Full Name. The Account Name and Full Name are parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the Account Name or Full Name are split and all sections are verified not to be included in the password. There is no check for any single character or any three characters in succession.

When checking against the user’s full name, several characters are treated as delimiters that separate the name into individual tokens. Commas, periods, dashes/hyphens, underscores, spaces, pound signs, and tabs. For each token that is three or more characters long, that token is searched for in the password; if it is present the password change is rejected.

  • English uppercase characters (A – Z)English lowercase characters (a – z)Base 10 digits (0 – 9)Non-alphanumeric (For example: !, $, #, or %)

For example, the name “Erin M. Hagens” would be split into three tokens: “Erin,” “M,” and “Hagens.” Because the second token is only one character long, it would be ignored. Therefore, this user could not have a password that included either “Erin” or “Hagens” as a substring anywhere in the password. All of these checks are case insensitive.

Deploy the Password Policy

It is quite common for an administrator that does not understand how password policies are stored to wonder if the policy should be applied at the Domain level, Domain Controllers level, or at the individual OU level. Prior to Active Directory 2008 and the introduction of Fine Grained Password Policies (FGGP), you can only apply one password policy to your user objects. I will discuss the use of FGGPs briefly in this article.

So, if there can only be one password policy for the pre-2008 domain, where do I link the policy to, the domain object or Domain Controllers OU. The answer is, that the account policies must be applied at the domain object level. Domain Controllers will ignore account policy settings that are configured in any GPO linked to the Domain Controllers OU.

If we look at a sample GPO, the first thing that you should note is that Password Policy settings are stored in the Computer Configuration section, not the User Configuration section. This is critical in understanding how to apply this policy.

Since the Password Policy settings are stored in the Computer Configuration section, the settings you define will apply to computer objects. If you apply the GPO at the domain level, it will apply to ALL computer objects under the root (including DCs which share the account database).

If you link it to an OU in the tree, it will be applied only to those computers located in that OU and any child OU.  When applying account policy at the OU level, the user accounts defined locally on those computers in the OU will be affected, not the user objects in the OU.

Now that we have determined that Password Policy is applied to computers and not users, how is it that domain users are bound by the policy? Well, think about this logically, when you link the policy at the domain object level (root), the computers that are impacted include… DOMAIN CONTROLLERS.

Account policy is actually propagated via the Domain controller holding the PDC emulator role, by writing the values to the root of the Domain Naming Context (DC=domain, DC=tld). Each domain controller in the domain replicates a copy of the domain NC. The rest of the DCs in the domain read the info from the domain NC head (and not from GPO holding the policy settings) and apply it.

I suspect that is why Account Policies must be linked to the domain level. If you were to link it to the Domain Controllers’ OU and the DC holding the PDC Emulator role was moved out of that OU, that would be problematic. By linking it to the domain object level, the PDC Emulator will in fact be targetted.

If you are now following this concept, this question should be easy to answer. So what will happen if I apply a password policy at the OU level? The answer should be simple at this point. The policy will impact the computer objects within the OU and the LOCAL USER accounts defined in those computers will be bound by this policy.

With the recent deployment of Windows 2008, we now have the ability to apply Fine Grained Password Policies at the user or group level. The method for deployment is quite different than what has been explained above. I hope that this information was helpful.