Providing an HIBP Database

If you use multiple domain controllers, which is generally recommended in production operations, you have to decide where to store the database with the compromised passwords. Lithnet provides three strategies from which to choose: a shared repository in the form of a file share, local storage on each individual domain controller with manual replication by Robocopy or XCopy, and local storage with automatic replication by Microsoft's Distributed File System (DFS).

Because HIBP's list rarely changes, manual replication is a viable option for smaller environments. The manufacturer recommends DFS especially for geographically distributed infrastructures, explicitly pointing out that you should not misuse the existing SYSVOL share replication but create a dedicated DFS replication group.

Once you have decided where the database will be located, download the LPP installation package and install the software in the context of a domain administrator, putting all components on each domain controller. In the second step of the dialog, proceed to configure the path to the database. The installation requires a reboot to enable the password filter. The following PowerShell commands,

Import modules LithnetPasswordProtection
Open-Store 'C:\Program Files\Lithnet\Active Directory Password Protection\Store'
Import-CompromisedPasswordHashes -Filename C:\temp\pwned-passwords-ntlm-ordered-by-hash-v4.txt

use a PowerShell module provided by Lithnet to convert the HIBP list to an LPP database on a domain controller.

Preparing Group Policies

While this process is running, use the time to make further preparations. If you use a central repository for Group Policy templates in your domain, and this is the best choice for multiple domain controllers, then copy the two administrative templates (ADMX files) lithnet.activedirectory.passwordfilter.admx and lithnet.admx on a domain controller where LPP is installed from the local C:\Windows\PolicyDefinitions path to the central location: \\<domain-name>\SYSVOL\<domain-name>\Policies\PolicyDefinitions. Drop the associated ADML files into the appropriate subfolders, or at least populate the en-US folder.

Now you want to open Group Policy Management and, under Default Domain Policy , disable Microsoft's defaults for password length and complexity, because LPP will take care of that in a moment. Now create a new Group Policy Object (GPO), which you need to link at the top level of the domain or with the organizational unit (OU) of the domain controllers.

Next, open the new GPO in the Group Policy Management Editor and navigate to Computer Configuration | Policies | Administrative Templates | Lithnet | Password Protection for Active Directory | Default Policy . This folder contains the settings for configuring LPP (Figure 2). In the first step, enable the Reject passwords found in the compromised password store setting and check the options Enable for password set operations and Enable for password change operations .

Figure 2: LPP group policies allow far more granular settings than Microsoft's onboard tools.

Few Meaningful Messages

You can wait for the Group Policy to update on all domain controllers, or you can enforce it with

gpupdate /force

In the next step, working in the context of any user on a client machine, try setting a password that is blacklisted by HIBP (e.g., P4ssw0rd! ). You should get two results: LPP basically works and refuses to implement the change, and Windows acknowledges this action with the typical, uninformative default message.

Although LPP supports detailed password requirements under the hood, it unfortunately cannot influence client behavior. Therefore, end users don't find out what exactly caused their password change to fail. Administrators can discover the reason, though, in the Application event log of the domain controller that processed the password change attempt. LPP logs in detail which group policy setting intervened (Figure 3). All event IDs that you might encounter are documented [7].

Figure 3: The local message on a Windows client is not very informative, but the event log on a domain controller reveals why a password change failed.

Two settings reject passwords that contain the user's account or display name, thus preventing users from including their own names in the password, regardless of the password length and complexity. Regular expression fans can also look forward to two settings that allow or reject passwords on the basis of freely definable rules.

The Passwords must meet specified number of complexity points option provides you with an individually configurable system that allows you to specify a minimum number of points that a password must meet, as well as a number of points per uppercase letter, lowercase letter, number, and symbol. A user then accumulates approximately one point per uppercase letter, two for each number, and three for each special character. LPP only accepts the password if it reaches the minimum total number of points.