Enforcing better Active Directory passwords (Password audit part 3)

(This is the third and final post of a three part series on Microsoft Active Directory password quality auditing)

Following on from part 2 where we used DS-Internals to extract NT hashes and John the Ripper to crack them, in this post we cover what to actually do with all of this (usually worrying) information.

What to do with a list of cracked passwords

Now that John has done his good work, you will likely have a list of passwords and their associated user accounts from some of your users. Once you’ve gotten off the floor and climbed back into your chair, you may start to think: “This is great! We can see exactly who has bad passwords. If they were good we wouldn’t have cracked them so easily.” So now what…

“Your password is awful, please change it”

To put it simply, this doesn’t work. Your users chose bad passwords in the first place. Asking them to change it will likely result in ‘Password2!’ instead of ‘Password1!’ just like every other scheduled password change.

Besides, their password strength meets your password policy, doesn’t it? If you contact every person in your list and try to explain why it was bad they’re going to want to know:

• Why you have their password – it was supposed to be protected
• What you’re going to do with it, since it’s also their password for Facebook, their personal email, their bank, and who knows what else…
• Why the computer warns them for “password” but not “Password1!”
• What makes a good password, a bad password, and who gets to decide…
• The list goes on…

This does not scale well. If you do manage to convince everyone to pick a more secure password it won’t survive your next password expiry cycle.

How we can enforce stronger, usable, Active Directory passwords

Active Directory has a built in feature for a custom password filter DLL. This allows you to step inside the ‘Update Password’ mechanism inside AD and examine all proposed questions to ensure they do not meet specific criteria. In essence, a bad password blacklist.

By installing a custom password filter onto each of our domain controllers we’re able to examine password changes in real-time and provide additional password quality checks before a change goes through. Now in addition to minimum length, character types used, and recent password history, we can check for uses like Company1! or Password1!, anything in the top X thousand most commonly used passwords, or any custom word lists and patterns that you want to provide.

Choosing an Active Directory password filter

When it comes to picking an AD password filter DLL you have three options:

1. Create your own using the documentation provided by Microsoft
2. Implement an open source version such as OpenPasswordFilter from Amar Kulo/Josh Stone
3. Implement a commercial product such as One Identity Password Manager or any other suitable alternative

Creating your own is the most time consuming, complicated, and riskiest but it will give you the greatest control. The open source versions are very powerful but their ‘free at point of purchase’ price point comes at the cost of no support if you ever have any issues in production. The commercial products come with support from the vendors and easy to update rules to ensure the solution is fully supported by your first line through to vendor support teams.

Maintaining regular audits

Once you have a custom password filter deployed to our organisation’s Active Directory estate you’ll need to ensure all domain controllers have the tools installed and configured with the same blacklists. If any domain controllers are missed or have our of date lists there’s a chance that an update password will bypass any protections you’ve tried to put in place.

You’ll also need to continue to conduct regular password quality audits to ensure your blacklist is working correctly and has the right rules applied at every touch point.