Understanding Password Policies

Hey everybody, its Randy again to discuss Password Policies. I recently had a case that required excruciating detail of how Password Complexity is calculated and I will now take that opportunity to discuss some interesting facts. I need to begin this discussion by directing you to the Account Lockout Best Practices Whitepaper. This paper explains all the meanings of the various password policy settings that can be defined in the domain group policy.

Most of these settings are pretty self explanatory. If you open your default domain policy and editAccount Lockout Policy, you will see that we have several settings listed.

Enforce Password History: When changing your password, will you be required to use a different password than previous passwords and how many previous passwords are remembered. One additional note to Password History is that it is not case sensitive. See example below:

- For uniqueness comparison, a new password must be at least one character different than the passwords in history, with the exception that upper and lower letters do NOT count.

That is, if “Password1” is in password history then the following will be unique since there is at least 1 character different.

Password2 (due to 2).

Passw0rd1 (due to numeral “0” instead of o).

Password[ (due to symbol “[” instead of 1).

But following will NOT be unique since upper and lower letters are the same.

PASSWORD1

pAsSWoRd1

password1

Minimum Password Length, Maximum Password Age, and Minimum Password Age are all self-explanatory and are well explained in the Account Lockout Best Practices Whitepaper.

Password Complexity: When changing a password, you will be required to use a password that meets the domain password complexity requirements. In Windows NT, this was controlled by an add-on password filter named passfilt.dll. A password filter is a procedure that is called during the password change request. LSA (Local Security Authority) will take the incoming password change request and load the password filter and then perform whatever task the filter has defined. You can make a password filter do just about anything, but typically it is used for password synchronization between separate platforms or a series of validations to confirm that a password change meets the company requirements. It is possible to create your own password filters as well, if you’re handy with C++. In Windows 2000 and later password complexity policies are now coded directly into the operating system as part of LSA, but the complexity requirements remain the same. You can find articles on MSDN with simplified explanations of these grammar checks, hopefully the information below will provide more detail:

From this Microsoft TechNet article, I found the following discrepancies in our documentation:

If this policy is enabled, passwords must meet the following minimum requirements when they are changed or created:

From this Technet article:
1. Not contain significant portions of the user's account name or full name.

Actually:
We look at the entire Account Name and the Full Name. We ensure that the Password does not contain the entire name of either. We also parse through the Account Name and Full Name for delimiters: commas, periods, dashes/hyphens, underscores, spaces, pound-signs and tabs. If any are found, the Account Name or Full Name are split and all sections are verified not to be included in the password. We do not check for any character or any three characters in succession.

From this Technet article:
2. Be at least six characters in length.

Actually:
Password complexity does NOT check passwordlength.

From this Technet article:
3. Contain characters from three of the following four categories:

English uppercase characters (A through Z)
English lowercase characters (a through z)
Base 10 digits (0 through 9)
Non-alphabetic characters (for example, !, $, #, %)

Actually:
It is three of 5 categories. The four categories listed above and a catch-all category of any Unicode character that does not fall under the above four categories. This fifth category can be regionally specific.

Complexity requirements are enforced when passwords are changed or created.

 The last setting, Store Passwords using reversible encryption, should never be used with a specific need. It is just available for compatibility with legacy apps using CHAP authentication. If you have an application or remote access policy requiring this setting then update it or replace it. You are essentially storing your passwords in plaintext.

I just touched on a couple of points here, but the Account Lockout Best Practices Whitepaper is filled with a lot of really good information. I can’t leave without dropping some Windows 2008 science on you. So here is a tidbit of information on Fine-Grained Password Policies:

One big concern from customers of Windows Server 2003 was that you could only set Password Policy at one location in the domain and the only way to separate these policies in your organization was to create separate domains. This has changed with Windows 2008 and Fine-Grained Password Policy. With Fine-Grained Password Policy, you can create different Password Settings Objects (PSO) and assign these PSOs to security groups in your organization. A PSO is simply a Password Policy stored in Active Directory to hold all the defined settings of that Password Policy. You can then associate the PSO to the security groups that you want to adhere to these settings. Here is a good step-by-step to setting this up in your 2008 domain.

[Editors note: We are working to get that TechNet article with the incorrect info (and any others like it) hunted down and fixed.]

- Randy Turner

Comments

• Anonymous
  May 19, 2009
  The comment has been removed

• Anonymous
  May 20, 2009
  No, you do not have to create a separate PSO for domain users.  Any user not associated with a PSO will get the Default Domain Password Policy.

• Anonymous
  May 20, 2009
  The comment has been removed

• Anonymous
  May 21, 2009
  The comment has been removed

• Anonymous
  May 25, 2009
  242 Microsoft Team blogs searched, 113 blogs have new articles in the past 7 days. 292 new articles found

• Anonymous
  May 29, 2009
  Thanks for the article and the link to the Account Lockout Best Practices Whitepaper. Two comments on the whitepaper:

1. It needs to have a date.
2. It needs to be updated. Remove anything pre-Server 2003 and include server 2008 information.

• Anonymous
  June 17, 2009
  Hello everyone, David Everett and Scott Goad here to discuss a recent issue that we thought you might