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.
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.
Installing
Installing is pretty easy, you just need to run the installer and click next, next, next.
If you want, you can decide which features to install but I decided to install all in this lab.
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.
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.
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.
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
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.
Configure this for set and change password operations. We don’t want even our administrators to be able to set up weak passwords.
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.
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$.
Great it didn’t change because the password was in our banned words.
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.
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.