Every so often when I am engaged in an Active Directory project the topic of password security comes up. Many IT people have strong feelings about password policies which may not align with current best practices or real-world threats. As such, sometimes policies are implemented which unnecessarily increase helpdesk calls or frustrate users yet do not address how malicious people are attacking systems in 2008.
Microsoft provides several group policy settings which can be used to customize password policies. I will discuss each of these settings and current Microsoft best practice recommendations. If you have read my Hashes to Hashes Domain Admins to Dust blog, you will remember that even the most stringent password policies can be easily bypassed in less than thirty seconds given the right circumstances. However, it is still important to have a solid password policy foundation, and then address other threats such passing the hash attacks.
Password History: This policy configures how many passwords Active Directory will store and compare against password change requests. Should a user try and re-use a password before the policy allows, the password change will be disallowed. The maximum setting is 24, and this is the setting Microsoft recommends.
The longer a user continues to use a password the more likely an attacker can determine what the password is be it through spyware, keystroke logging, watching you type your password, etc. So an organization must strike a balance between usability of passwords, but also keep in mind that re-using passwords should be a concern. Users will generally not raise a fuss about a strong password history, so I’ve found enforcing 24 is fairly easy to do.
Maximum Password Age: For this policy Microsoft recommends 90 days. Most organizations I’ve dealt with follow the 90-day rule, including Government agencies. Users are generally OK with changing passwords four times a year. Forcing users change passwords more frequently can have unattended consequences such as an increase in sticky-note based passwords and more helpdesk calls. For users disconnected from the corporate network, changing passwords can be challenging as well.
Minimum Password Age: A minimum password age is very important to thwart users from bypassing the password history in a short amount of time. With an age of 0, a user could cycle through new passwords in a few minutes and re-use their old one which totally defeats the password history setting. A minimum age of 1 day would require the user to change their password every day for a month (assuming a history of 24 passwords) to re-use their old one. Microsoft recommends two days, which is generally what I recommend. Some companies may choose one day.
This policy can create issues if a password reset is needed for troubleshooting and a user wants to revert back to their prior password. If security policy allows, a domain administrator could reset the user’s password and bypass the minimum age and password history policy.
Minimum Password Length: Minimum password lengths can cause quite a debate in organizations due to some legacy issues regarding LAN Manager (LM) passwords, and general user acceptance as well. As many people know, LM is a very insecure way of storing and transmitting passwords. Microsoft realized this many years ago, and implemented stronger algorithms such as NTLMv2.
Any script kiddy can pluck LM passwords off the network and decrypt them, regardless of password length. Unless there is an application or legacy OS that absolutely requires LM, I always strongly recommend to explicitly prohibit LM use on a corporate network via GPOs. There are two settings to prohibit LM usage: One is Network security: Do not store LAN Manager hash value on next password change and the other is Network security: LAN Manager authentication level.
The first policy should always be enabled across every computer in the enterprise which will prohibit Windows from storing LM hashes of passwords in the SAM and AD. Generally I will put this in the domain wide group policy. The second GPO is trickier, due to some applications or legacy OS issues. The minimum setting to ensure no LM is used is "Send NTLMv2 response only, refuse LM." I always recommend the strongest setting of "Send NTLMv2 response onlyrefuse LM and NTLM" if it does not break applications. However, thorough testing needs to be conducted to see if any applications or other devices that authenticate to Windows may break. VPN appliances, printers, scanners, Unix systems, and other devices may not support NTLMv2.
If an enterprise takes the above steps to eradicate LM usage from the network, then password length need not take into consideration the legacy rules surrounding LM passwords. Thus password lengths of eight characters are stronger than seven character passwords. A typical password of eight characters for users is widely accepted, and is the minimum recommended by Microsoft.
Service accounts, and accounts with elevated rights should have stronger passwords. Some organizations may enforce 15 character passwords or longer on service, administrator, or other privileged accounts. Windows Server 2008 supports multiple password policies (unlike Windows Server 2003), and third-party add-ons can be used as well for Windows Server 2003 based domains. Users are encouraged to use longer passwords, or passphrases, as they can be easier to remember and more secure.
Password Complexity: Complexity is key for strong passwords. Allowing a user to use eight A’s or their last name is not secure. Unfortunately, Microsoft does not have a granular complexity policy. Either you enable complexity or you don’t. Third party products, such as nFront Password Filter, give IT policy makers much more control over the complexity requirements. Microsoft recommends their complexity rules be enabled, which provides basic protection against weak passwords.
Enabling this policy will enforce six character passwords, and one or more characters from three of the four categories must be used: upper case, lower case, numerals, and special characters. There are also additional rules regarding the use of portions of a user’s name in the password. Microsoft also provides information on how to create a DLL which can enforce custom password policies as well. But generally a company will use the built-in complexity rules or use a commercial product rather than develop an in-house solution.
Account lockout duration: Account lockouts are implemented to prevent brute force attacks against accounts. The modern hacker will rarely use brute force, as there are many more reliable ways to "0wn" an account, such as hash injection, spyware, keyboard loggers, etc. Account lockout policies can be easily used as a DoS attack by malicious users, locking out hundreds or thousands of users at once. In fact, one of my clients had a virus which locked out hundreds of accounts over a short period and we had to disable the lockout policy until the virus was eradicated. Service accounts were also being locked out, with caused line-of-business application outages as well.
Lockouts also frustrate users and cause helpdesk calls as well with little return on thwarting attackers. Sometimes accessing a workstation is a time sensitive operation, so excessively long lockouts can cause user backlash or lost productivity. Personally, lockout durations of five to ten minutes seem reasonable. Microsoft provides no official guideline on lockout duration, as there is no one size fits all answer.
Account lockout threshold: This can be hotly debated among security professionals. A low threshold will likely increase helpdesk calls, user frustration, and present only a small barrier to the determined attacker. The latest Microsoft security documents recommend the threshold be set to 50. Yes, 50. Enforcing a password length of eight and complexity rules, there are billions of possible combinations. The chances of an attacker guessing a password in a few dozen attempts is extremely remote. The damage from a DoS (denial of service) lockout attack could be much greater and is much more likely.
In fact, to avoid a possible DoS situation, disabling the lockout threshold is the best solution. However, I would only disable the lockout threshold if there was robust auditing and alerting on invalid password attempts. Products such as Microsoft Systems Center Operations Manager (SCOM) can easily be configured to alert on bad password attempts and notify security persons without placing undue burden on users or creating a possible DoS situation. Quest also makes a great auditing tool that will also notify security personnel to suspicious activity.
For organizations without robust auditing and alerting I recommend using the Microsoft threshold of 50. I would have a better chance of winning the lottery than a brute force attacker guessing a strong password in 50 attempts. If a user can’t remember their password in 50 attempts, they should contact the helpdesk for a reset.
Reset account lockout counter after: This setting must be equal to or longer than the account lockout duration. A timer keeps track of the time after the last bad password attempt and will reset the count to zero when the specified time is reached. To keep things simple I always set this equal to the account lockout duration.
A comprehensive password policy requires an evaluation of current threats, existing security policies, and your user community. There is no one size fits all solution and a balance needs to be struck between countering security threats and end-user frustration. Strong password policies are only a small part of a security plan, and should be looked at in the context of the entire network.
For additional reading on this subject and discussion of the myriad of other security policies in Windows Server 2003, I strongly recommend reading the Threats and Countermeasures guide for Windows Server 2003 and Windows XP.
