Installer inconsistently applies store path

[mgryka]

Manually entering network path of store defaults to the default path on some DCs, resulting in compromised passwords being approved if the request is processed on those DCs.

Solved by editing registry (Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Lithnet\PasswordFilter\Store) to correct store location path.

[ryannewington]

Thanks for reporting this @mgryka

Are you finding that this happens on reinstalls, where an existing path is reset to the default, or new installations, where the new path provided is not set at all?

[mgryka]

I was using the change function of the installer:

On DCs where it was working correctly, the path would show up like so (paths changed to protect the innocent):

On DCs that were not working correctly the default install path would show up like so:

Changing the path via installer did not work in those cases, running the installer again did not change the path to the newly specified one (repeated attempts always showed the default directory). In troubleshooting the issue, I went into the registry and noticed that the 'Store' value was set to the C:\Program Files\Lithnet.... directory.

It wasn't a big problem, but I figured I would report it to help out future troubleshooters!

Editing to add:
This seemed to be an issue on DCs running on older versions of Windows Server. DCs running 2019 did not appear to have problems.

[C493]

I can confirm (part of) this issue exists on DC running Windows Server 2016 Standard.

What I mean by "part of" is that I had originally installed using the default store path, but then created my own share and used the "Change" option in the installer to point to the new location.
The change didn't take (even after a reboot), the store was still set to the default path.

As mentioned by @mgryka the issue is easily resolved by updating the path in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Lithnet\PasswordFilter\Store).

[ryannewington]

Thanks for confirming @patrickcage

We will address this in a future release.

[ryannewington]

This should be resolved as of 1.1 using the new installer framework