Active Directory: Protecting the crown gems III

January 08, 2024

Banning password

I hope you manage to convince your CISO or management that this is a problem, now is the time to start with banning weak passwords from your environment. At first, I thought the only way to do this was by using Azure Password Protection but several open source projects can help with this. The one I decided to use is ad-password-protection from Lithnet. This is a really easy and powerful tool to use for this purpose.

Lithnet Github

Planning

Lithnet Password Protection uses a store that will be the database to store the banned and weak passwords. This store will need to be accessed by the domain controllers that have the password filter, we have different options for this. Lithnet suggests using DFS-R but as always analyze which of these methods works best for your environment.

Lithnet Distribution Strategy

Installing

Installing is pretty easy, you just need to run the installer and click next, next, next.

Password Protection Installer

If you want, you can decide which features to install but I decided to install all in this lab.

Password Protection Installer

Once we have it installed, we need to create our store in the server. We create a folder for our store. With the PowerShell module, we set the storepath using the full path.

Creating Store

Now is the time to open the created store and start populating it. We have different options like syncing with the compromised hashes from haveIbeenpwd and I encourage you to use this one but first read the documentation and see how much space you will need. In this case, let’s ban some of the words we identified in the last blog.

Populating Store

Remember to use the right command to test if we are blocking the password or words. One will do normalization and is more powerful the other helps you block individual passwords.

Test Store

After populating our store, we need to deploy a GPO for our domain to use this password filter. The ones we need to change our store on Policies>Administrative Template>Lithnet>Password Protection for Active Directory

Policies

There are several configurations we can do but, on this blog, I used:

  • Reject passwords found in the compromised password store.
  • Reject normalized passwords found in the compromised password store.
  • Reject normalized passwords found in the banned word store.

I would suggest also using:

  • Reject passwords that contain the user’s account name.
  • Reject passwords that contain the user’s display name.

Password Protection Policies

Configure this for set and change password operations. We don’t want even our administrators to be able to set up weak passwords.

Password Protection Policies

Testing

Before we start testing our newly deployed filter and policy we need to restart the domain controller we have configured. We will see an event from LithnetPasswordProtection that says our password filter was loaded.

Load Filter

Let’s see what will an administrator see if he/she attempts to reset the password of a used to a weak one like Peru2023$.

Change Password

Change Password

Great it didn’t change because the password was in our banned words.

Change Password

If we want to know the exact reason why it was rejected, we can look for the events in the Application log. This will be useful when a user or administrator doesn’t understand why his/her password is getting rejected. Remember to communicate to your users and team about the change to avoid too much confusion, there will always be some users that will need your help.

Change Password

Conclusion

As you can see Lithnet Password Protection for AD is powerful and free, you can use it and make a little more secure your Active Directory infrastructure. Good luck.


Profile picture

Written by Frog hi, hope you can find something useful in this blog - fr0g74