skip to Main Content

Secure Active Directory passwords from breaches

Security is essential for every organization. When an account password is breached, and access is made to the environment, a lot of confidential stuff will be gathered and leaked. This is a massive problem for every company. Let alone the time that you will spend on this problem. Security starts with implementing fundamentals in the infrastructure and informing users, so they are aware. In this article, you will learn how to audit and secure Active Directory passwords from breaches.

Audit and secure account passwords

It’s important to understand that there are two critical configurations that you need to do in the organization:

  1. Audit account passwords: Create an export and check if there are weak/breached passwords.
  2. Secure account passwords: Create a policy so users and administrators can’t create weak/breached passwords.

To configure both options above, you must download and install Lithnet Password Protection for Active Directory. That’s because you will use that to check for breached passwords against the HIBP (Have I Been Pwned) passwords list and prevent creating weak/breached passwords in Active Directory (more below).

Note: Suppose you have a hybrid Azure AD configuration, then we recommend you configure Azure AD Password Protection for on-premises.

Install Lithnet Password Protection for Active Directory

Sign in to the Domain Controller.

Download Lithnet Password protection from GitHub.

Secure Active Directory passwords download Lithnet

Start the Lithnet Password Protection for Active Directory Setup and go through the installation wizard. The setup is straightforward, and you can click through it.

Secure Active Directory passwords install Lithnet

Download HIBP passwords list

Download the HIBP Pwned passwords list from Cloudflare or Torrent (step-by-step guide). Ensure that you download the NTLM order by hash file.

Secure Active Directory passwords Pwned Passwords list

Once the file is downloaded, move it to the C:\temp folder.

The downloaded .7z file is 11.7 GB.

Secure Active Directory passwords downloaded file

Extract the pwned-passwords-ntlm-ordered-by-hash-v8.7z file. You can use 7-Zip or WinRar to extract the file.

The extracted .txt file is 28.5 GB.

Secure Active Directory passwords extracted file

Remove the 7z file you downloaded because it’s extracted and will save you space.

The plain-text hash file is 28.4 GB, but when you import it into the Lithnet store, it will take 11.1 GB in size (more on that below).

Import HIBP passwords list

Run PowerShell as administrator and run the below command to import the pwned-passwords-ntlm-ordered-by-hash-v8.txt file to the Lithnet store.

PS C:\> Import-CompromisedPasswordHashes -Filename "C:\temp\pwned-passwords-ntlm-ordered-by-hash-v8.txt"

It will take time to read the text file and convert the hashes into a much smaller binary format.

Secure Active Directory passwords import

Check Lithnet Password Protection database

Start File Explorer and go to the Lithnet Password Protection database path.

C:\Program Files\Lithnet\Active Directory Password Protection\Store\v3\p

Check that the DB files are created.

Secure Active Directory passwords store

The store size is 11.1 GB.

Secure Active Directory passwords store size

Remove the text file you extracted because it’s imported into the store and will save you space.

Check breached passwords in Active Directory

Download the Audit-Passwords.ps1 script and paste it into C:\scripts on the Domain Controller.

Ensure that the file is unblocked to prevent any errors when running the script. Read more in the article Not digitally signed error when running PowerShell script.

Run PowerShell as administrator. Change the path to the scripts folder. Run the PowerShell script to audit the breached passwords in Active Directory. Wait till it completes.

PS C:\> cd c:\scripts
PS C:\scripts> .\Audit-Passwords.ps1

The PS output shows which accounts have a password that’s breached. Also, a CSV file with the name get-pwned-users.csv is generated in C:\scripts.

Secure Active Directory passwords CSV file

This is how it looks in our example. Only one account has a password set which is listed in the HIPB pwned password list.

Secure Active Directory passwords open CSV file

Now that you have the accounts with pwned passwords, you can send an email to them to change their password.

But what if they change the password and insert a breached password again? Do you want to keep checking AD for breached passwords daily or weekly and send the users emails to change their passwords? Well, that’s not something you want. It’s time-consuming, and the organization is not safe.

In the next step, you will configure a group policy that prevents users from creating a pwned password.

Prevent users from creating breached passwords

The best way is to configure a policy that when a user wants to create a password, it will use the HIPB password list for a check.

If the password is in the pwned passwords list, the user can’t use the password. However, if the password is set, it means it’s not breached and is secure enough to apply the password.

Configure Group Policy

Start Group Policy Management. Right-click the Domain Controllers OU and click on Create a GPO in this domain, and link it here.

Secure Active Directory passwords create GPO

Give the policy the name LithnetPP and click on OK.

Secure Active Directory passwords new GPO name

Right-click the LithnetPP GPO object and select Edit.

Secure Active Directory passwords edit GPO

In the Group Policy Editor, navigate to:

Computer Configuration\Policies\Administrative Templates\Lithnet\Password Protection for Active Directory\Default Policy

Double-click Reject passwords found in the compromised password store.

Secure Active Directory passwords navigate GPO

Check the checkbox Enabled and enable both the options Enable for password set operations and Enable for password change operations. Click on OK.

Secure Active Directory passwords enable reject passwords

Note: There are more GPO options, and you should have a look through them. But be aware that the more options you configure, the more complex it will become for the users to create a password.

Reboot the Domain Controller for changes to take effect.

Test password policy

Test that the GPO works and go through the next steps:

  1. Active Directory Users and Computers: Create a new AD user account with and without a password in the HIBP list.
  2. Active Directory Users and Computers: Reset a password for an existing AD user account with and without a password in the HIBP list.
  3. Windows device domain joined: Sign in with a user account and reset the password with and without a password in the HIBP list.

In our example, we will show only the first example.

Start Active Directory Users and Computers. Right-click a user account and select Reset the password.

Secure Active Directory passwords reset

Fill in a password that appears in the HIBP list, or you can always go to HIBP Pwned Passwords and fill in the password to check if it has previously appeared in a data breach.

Secure Active Directory passwords test password

Fill in the password twice and click on OK. In our example, we will use Password01.

Secure Active Directory passwords new password

The error appears:

Windows cannot complete the password change for user because: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.

Secure Active Directory passwords cannot complete

Now do the same steps but with a password that’s not breached, and it will complete the password change successfully.

Read more: Bulk create AD Users with random passwords »


You learned how to audit Active Directory passwords and secure Active Directory passwords from breaches. Always run an audit and inform the management on how to make the password requirements more strict with the help of Lithnet Password Protection. Don’t forget to configure MFA on top of this. So if the password is breached in the future, then there is always a second layer of protection.

Did you enjoy this article? You may also like Force password sync with Azure AD Connect. Don’t forget to follow us and share this article.



ALI TAJRAN is a passionate IT Architect, IT Consultant, and Microsoft Certified Trainer. He started Information Technology at a very young age, and his goal is to teach and inspire others. Read more »

This Post Has 7 Comments

  1. I learned something very good. thanks.

    It would be very helpful if you could share more articles on security. You are great.

  2. Thanks for the post and detailed info. Really handy to know, I’ve been using a free tool, however these solutions are even better!

  3. A password change request can be processed by any controller. Does this solution need to be installed on every controller in the network?
    I guess in this case, we need to create a base in some place that will be accessible to all controllers.
    Uploading this to some kind of network share seems like a bad option, since every request would have to go through the network infrastructure.
    How to make the password database available to all domain controllers?

    1. I showed “Option 2” because there was only 1 DC. If you have more than one DC, do the same steps on the other DCs. But, you can also use “Option 3”.

      Option 1: Each server accesses a single copy of the store via a file share

      In this configuration, each server with LPP installed points to a network share that contains the single copy of the store. The benefits are that there is only one copy of the store to be managed, but the downside is that if the file server goes down, the password filter will be unable to perform compromised password checking. This might also be an issue for distributed environments, where bandwidth and latency between domain controllers and the file server is an issue. Remember, the agent must be installed on every writable domain controller in your environment, so they will all need read access to this store. If this is your preferred strategy, create your share, and grant the server’s computer accounts read access to the store before you proceed. Users who be managing the store will need read and write access to this folder.

      Option 2: Each server has its own copy of the store

      In this configuration, each server with LPP installed has a local copy of the store. This means the store will always be available, and there will be no bandwidth or latency issues. The downside is that if you want to update the store with new passwords, you need to update it on each server manually. Updates to the store will be infrequent, so this may not be an issue. As the store is flat-file based, it is easy to copy around with a tool like robocopy and xcopy.

      Option 3: Each server has its own copy of the store, but it is replicated with DFS-R

      This is the configuration we recommend. Each server with LPP installed has its own copy of the store, but DFS-R is used to replicate and keep changes in sync. This means that new passwords can be added to a single server, and DFS-R will replicate those changes to the other servers. Do NOT place the store in the SYSVOL folder. Create a dedicated replication group for the LPP store.

      1. By option 3. Do I understand correctly that I should do the following:
        1. Install Lithnet (For example, on D:\Bases), load password databases into it as written in your instructions.
        2. On all domain controllers, enable the DFS replication role, select this folder and replicate it between all.
        3. Install clients on the remaining controllers, specifying replicated folder

          1. Thanks for your help and for the information you share on your blog. You are incredible

Leave a Reply

Your email address will not be published. Required fields are marked *