{"id":30716,"date":"2019-10-31T21:37:05","date_gmt":"2019-10-31T18:37:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-zapretit-standartnye-paroli-i-zastavit-vseh-tebya-nenavidet\/"},"modified":"2019-10-31T21:37:05","modified_gmt":"2019-10-31T18:37:05","slug":"kak-zapretit-standartnye-paroli-i-zastavit-vseh-tebya-nenavidet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-zapretit-standartnye-paroli-i-zastavit-vseh-tebya-nenavidet","title":{"rendered":"How to prohibit standard passwords and make everyone hate you","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

As we know, humans are lazy creatures.
\nEspecially when it comes to choosing a strong password.<\/p>\n

I believe every administrator has faced the issue of using easy and standard passwords at some point. This phenomenon is quite common among the upper echelons of company management. Yes, indeed, among those who have access to secret or commercial information, and it would be extremely undesirable to deal with the consequences of a password leak\/hack and subsequent incidents.
\n<\/a><\/noindex>
\nIn my experience, there was a case where in an Active Directory domain with password policy enabled, accountants independently came up with the idea that a password like 'Pas$w0rd1234' fits the policy's requirements perfectly. The result was widespread usage of this password everywhere you looked. It sometimes only differed by a few digits. <\/p>\n

I really wanted to have the ability not only to enable a password policy and define the character set but also to filter against a dictionary. To exclude the possibility of using such passwords.<\/p>\n

Microsoft kindly informs us via a link that anyone who knows how to handle a compiler, an IDE, and can correctly pronounce C++ can compile the necessary library for themselves and use it as they see fit. Your humble servant is not capable of such things, so I had to look for a ready-made solution.<\/p>\n

After a long hour of searching, two solution options were presented to my eyes. I am, of course, talking about the OpenSource solution. After all, there are paid options\u2014from A to Z.<\/p>\n

Option \u21161.<\/u> OpenPasswordFilter<\/b><\/a><\/noindex><\/p>\n

No commits for about two years. The native installer works inconsistently, requiring manual adjustments. It creates its own separate service. When updating the password file, the DLL does not automatically pick up the modified content; you need to stop the service, wait for a timeout, edit the file, and restart the service. <\/p>\n

Not great!<\/u><\/b><\/p>\n

Option \u21162.<\/u> PassFiltEx<\/b><\/a><\/noindex><\/p>\n

The project is active, alive, and doesn't even need a push to keep going.
\nSetting up the filter involves copying two files and creating several registry entries. The password file is not in a lock, meaning it is editable and, according to the author's design, is simply read every minute. Additionally, with extra registry entries, you can perform further customization of both the filter itself and the intricacies of the password policy.<\/p>\n

So.
\nGiven: Active Directory domain test.local
\n test workstation Windows 8.1 (which is irrelevant for the task conditions)
\n PassFiltEx password filter<\/p>\n