Which AD forest and domain functional level are you running in the organization? Are you…
How to 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.
Table of contents
Audit and secure account passwords
It’s important to understand that there are two critical configurations that you need to do in the organization:
- Audit account passwords: Create an export and check if there are weak/breached passwords.
- 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 Microsoft Entra hybrid identity configuration, then we recommend you Configure Microsoft Entra Password Protection for on-premises.
Setup Lithnet Password Protection for Active Directory
To setup Lithnet Password Protection for Active Directory, go through the below steps.
1. Install Lithnet Password Protection for Active Directory
Sign in to the Domain Controller.
Download Lithnet Password protection from GitHub.
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.
You installed Lithnet Password Protection for Active Directory successfully.
2. Download HIBP passwords list
Download and get the up-to-date compromised passwords from HIBP. To synchronize the Lithnet password store with the Have I been Pwned API, use the Sync-HashesFromHibp cmdlet.
Note: The HIBP Passwords are updated constantly, and you should run the below cmdlet occasionally. An excellent way is to create a scheduled task that runs the Sync-HashesFromHibp cmdlet every week or month in the background to synchronize the HIBP passwords to the Lithnet password store.
Start Windows PowerShell as administrator and run the below cmdlet.
Sync-HashesFromHibpIt will start downloading the HIBP passwords to the store.
Once it’s done, you get an output with the results.
OperationStart : 1/23/2024 7:13:35 PM
OperationFinish : 1/23/2024 8:30:35 PM
Duration : 01:17:00.2187755
PagesRetrieved : 1048576
PagesWithChanges : 1048576
PagesUnchanged : 0
NewHashesImported : 931856448
ExistingHashesDiscarded : 0
TotalHashesProcessed : 9318564483. 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\pCheck that the DB files are created.
The store size is 12.2 GB.
Note: The size can vary because the HIBP password database is constantly updated.
Lithnet Password Protection for Active Directory is set up successfully.
Check breached passwords in Active Directory
Download the Audit-Passwords.ps1 script and paste it into C:\scripts on the Domain Controller.
Ensure the file is unblocked to prevent errors when running the script. Read more in the article Not digitally signed error when running PowerShell script.
Run PowerShell as administrator. Run the PowerShell script to audit the breached passwords in Active Directory. Wait till it completes.
C:\scripts\.\Audit-Passwords.ps1The 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.
This is how it looks in our example. These accounts have passwords set that are listed in the HIBP pwned password list.
Now that you have the accounts with pwned passwords, you can email the users 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 HIBP 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.
Give the policy the name LithnetPP and click on OK.
Right-click the LithnetPP GPO object and select Edit.
In the Group Policy Editor, navigate to:
Computer Configuration\Policies\Administrative Templates\Lithnet\Password Protection for Active Directory\Default PolicyDouble-click Reject passwords found in the compromised password store.
Check the checkbox Enabled and enable both the options Enable for password set operations and Enable for password change operations. Click on OK.
Note: There are more GPO options, and you should 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.
Important: Reboot the Domain Controller for changes to take effect.
Test password policy
Test that the GPO works and go through the next steps:
- Active Directory Users and Computers: Create a new AD user account with and without a password in the HIBP list.
- Active Directory Users and Computers: Reset a password for an existing AD user account with and without a password in the HIBP list.
- 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.
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.
Fill in the password twice and click on OK. In our example, we will use Password01.
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.
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 »
Conclusion
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, 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.
What Others Are Reading
Hi,
just for the first part, when I run Audit-Passwords.ps1 my csv come with a lot of accounts.
I go to the site HIBP and manually test some of these accounts and none is pwned.
What could be? Can you help?
Tks
You need to fill in the user’s passwords in HIBP site. Then, it will tell you that the passwords are pwned. But I guess you don’t know the users’ passwords. So you can’t test it.
If you have a list of users, it means they use weak or breached passwords.
Thank you, Ali!
Hi, Thanks for post. I just want that when users change their password, be sure to use A-Z and a-z and 0-9 and special characters. unfortunately I couldn’t set it up. can you help ?
Thanks for the article.
So, how will this process be in an environment that is synced with Entra AD? If there is SSRS in the environment, the user reset his password with SSRS, but it gave an error because it did not comply with the policy applied in on Prem AD. (the method you specified in this article) The user now has two passwords. The old password is for AD, the new password in SSRS.
Can’t we apply this password protection to Entra ID as well?
Suppose you have a Microsoft Entra hybrid identity configuration, then we recommend you Configure Microsoft Entra Password Protection for on-premises (as shown in the article).
Thank you friend
I learned something very good. thanks.
It would be very helpful if you could share more articles on security. You are great.
Thanks for the post and detailed info. Really handy to know, I’ve been using a free tool, however these solutions are even better!
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?
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.
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
That’s correct.
Thanks for your help and for the information you share on your blog. You are incredible
Hi,
Just a single question: At the point 3, what do you mean when you say “install clients”? Because I just saw that we must install Lithnet, but nothing else like as client. Thanks!
Hi Ali,
at first thank you for this article! 🙂
One Question:
If i choose Option 1 and the share is not reachable no password change/set is possible till the share is reachable again? Or can the user choose than set still a (maybe breached) password?
Best regards
Gero