> For the complete documentation index, see [llms.txt](https://docs.lithnet.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lithnet.io/password-protection/v1.0/installation/installing-the-module.md). # Installation of Password Protection Download the latest version of the installer from the [releases](https://github.com/lithnet/ad-password-protection/releases) page. In order to enable password filtering on your domain users, the application will need to be installed on all writable domain controllers in the domain. You can install the PowerShell module and group policy templates on any x64 machine. You can install and test the module using *local* accounts on any x64 Windows workstation or server. However, if you want to test against domain accounts, you will need to install the module on your domain controllers. ## Installation options The installer presents several options for you to choose from * Lithnet Password Protection for Active Directory * Enable password filtering on this computer * PowerShell module * Group policy templates (ADMX) ### Lithnet Password Protection for Active Directory This is the component that contains the logic to test passwords against your policy. It is required to be installed to use any of the other functions ### Enable password filtering on this computer When you select this option, the installer will register the password filter with the local security authority subsystem (LSASS) on the local computer. After a reboot, Windows will pass all password changes to the filter for validation. Note that you still need an appropriate [group policy ](/password-protection/v1.0/installation/configure-group-policy.md)configured before the filter will be configured to reject any passwords. When you select this option on a domain controller, this means that the password filter will process any password change or set operations for any user. > Note that as any writable domain controller in a domain can process a password change, the module must be installed on every domain controller. When you select this option a member server or workstation, enabling this option will mean that password changes for local accounts are checked by the filter for approval. Password changes for domain accounts are always processed by the domain controller, so this setting has no effect for domain account password changes performed on member servers and workstations. ### PowerShell module The PowerShell module allows you to build your store, add passwords and banned words and test passwords against the policy. For managing the password store, the PowerShell module can be installed on any machine that has access to the store folder. For testing passwords, the PowerShell module should be installed on a machine that has the domain's group policy applied to it. In order to audit existing user's passwords against the compromised password store, we recommend installing this module on the domain controller and running the appropriate cmdlet from there. ### Group policy templates The group policy templates should be installed on any machine that you need to configure the password settings group policy on. We recommend copying the ADMX files to a [central policy store](https://support.microsoft.com/en-au/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra), which will enable you to see and manage the group policy settings from any machine in the domain. ### Choosing a store path If you are going to use the compromised password and banned word functionality, you'll need to create a[ password store](/password-protection/v1.0/installation/create-a-new-store/understanding-the-store.md). The store is a file-based data structure containing the NTLM hashes of the compromised passwords and banned words. We recommend creating a folder, and replicating it with DFS-R to all the machines that will be performing password filtering. This means all servers have the same copy of the password store, and by having a local copy, they are immune to network or connectivity problems. Otherwise, you can manually copy the store to all nodes, and just ensure that any updates you make are copied to each host as well. If you prefer, you can configure a network share to host the store. You'll just need to ensure that the machine accounts for all servers performing filtering have read access to the share. See the guide on[ Creating a store](/password-protection/v1.0/installation/create-a-new-store.md) for instructions on populating your store with compromised passwords. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lithnet.io/password-protection/v1.0/installation/installing-the-module.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.