locks highlighted and lined up

Active Directory weak password checker

One of the most important things that system administrators can do to keep their network resources secure is to require users to use strong passwords. After all, long and complex passwords are far less prone to being breached than simpler passwords are.

Microsoft has long provided group policy settings that administrators can use to mandate the use of strong passwords. These settings can be found in the Group Policy Object Editor at Computer Configuration \ Windows Settings \ Security Settings \ Account Policies \ Password Policy. Administrators can use the various group policy settings to set basic requirements such as a password’s length, maximum age, and complexity.

As helpful as the various password related group policy settings might be, they actually have a very limited ability to protect an organization against the use of weak passwords. While it is true that the native group policy settings can help to protect against passwords that are too short or that lack complexity, there are numerous factors that can cause a seemingly acceptable password to be weak.

Often for example, a user will use character substitution (which is sometimes called leetspeak) as a tool for beating password complexity requirements. In doing so, the user substitutes keyboard characters such as the @ sign or the zero for letters in words. For example, the word password might be expressed as P@ssw0rd. While such a password might meet the Active Directory complexity requirements, it is actually a very weak password. Modern dictionary based attack algorithms are designed to look for leetspeak versions of words that appear in the dictionary. Unfortunately, there is no native group policy setting that can be used to prevent the use of leetspeak.

Another shortcoming in Windows’ native defenses is that the Windows operating system does nothing to protect against the use of compromised passwords.

In some ways, it might be tempting to dismiss this particular shortcoming as irrelevant, because it is possible to use the native tools to address a compromised password in a roundabout way. Suppose for a moment that a user’s account were to be compromised. In such a situation, an administrator could easily force the user to change their password, and use the Password History option within the Group Policy Editor to prevent the user from using the same password again any time soon. The problem with this approach however, is that it does not account for password breaches that are seemingly unrelated to the organization.

Imagine that a hacker managed to break into an organization that is completely unrelated to the organization that you work for, and in doing so, managed to acquire the passwords used by each of that organization’s users. On the surface, such an attack would seem to have absolutely no relevance to your own organization. However, that seemingly unrelated attack actually improves a hacker’s odds of being able to access accounts in your own organization.

The main reason why most organizations require the use of long and complex passwords is because they render brute force cracks ineffective. Brute force cracks are extremely inefficient and time consuming. As such, hackers maintain lists of the passwords that they or other hackers have been able to crack. The idea is that if someone was using a particular password in a real world environment, then there may be other people who are using the same password. As such, these stolen passwords are incorporated into dictionary based attacks.

The bottom line is that if one of your users is using a password that happens to match a password that was previously cracked in an unrelated organization, then that password can put your organization at risk.

Unfortunately, Windows does not include a mechanism for checking for leaked passwords. If you suspect that a particular password might have been compromised, you can compare it against a list of passwords that are known to have been exposed. You can find the list at haveibeenpwned.

Of course one of the big problems with using this technique to ensure that your organization is not using compromised passwords is that you have to know your user’s passwords in order to put them to the test. Even if you do know those passwords, entering each one into the Pwned Passwords checker would be a time consuming and labor intensive process. A better solution would be to acquire Specops Password Policy. It can automatically compare your users passwords against passwords that are known to have been leaked. In addition, Specops Password Policy also includes tools for protecting against leetspeak and other factors that contribute to weak passwords.

(Last updated on October 30, 2023)

Brien Posey writer

Written by

Brien Posey

Brien Posey is a freelance author and speaker, and 15-time Microsoft MVP with 20+ years of IT experience.

Back to Blog