Releases: ryanries/PassFiltEx
v1.6.2
v.1.6.2
-
The major feature for this release is the addition of the "ApplyToTheseGroupsOnly" setting. By specifying a comma-separated list of global security groups in this registry entry, you can have the password filter apply only to the groups you specify. Everyone else who is not a member of any of the specified groups gets a free pass from this password filter. If ApplyToTheseGroupsOnly is not used, then everyone's password will be checked. This currently only checks direct membership in global security groups. It does not expand nested group membership. This choice was made for performance reasons.
-
This will only matter to me, but I ditched MSVC for an entirely command line-based clang build. This was because the Visual Studio IDE was crushing my soul with its bugs and I had to break free from its prison.
-
Changed all instances of "blacklist" to "blocklist". IMPORTANT The default blocklist filename changed to PassFiltExBlocklist.txt. If you are upgrading from a previous version and you use the default filename, you must change your blocklist filename accordingly!
v1.5.55
v1.5.55
Added the ability to have SUPER-blacklisted strings in the blacklist text file.
Now any line in the blacklist text file that begins with an exclamation mark (!) is considered to be SUPER-blacklisted, meaning that string (excluding the preceding exclamation mark) may not appear anywhere in the password, regardless of the password's overall length. In other words, TokenPercentageOfPassword will be ignored for super-blacklisted strings.
v1.4.17
v1.3.21.2
New version v1.3.21
Highlights of this release are:
Completely removed ETW logging and moved to basic text file logging. After all these years, I am finally admitting publicly that I was just trying to be a cool Windows guru and that I was just being sadistic by trying to force people to use ETW. ETW has its uses but it's really awful for when you really just want a log file. The log file is \Windows\System32\PassFiltEx.log and the log is rotated after it reaches 1MB. By default only error messages are logged, but if you use the Debug registry setting in the PassFiltEx subkey, it will enable additional informational messages. Updated the README with this information.
Added a "BlockSequentialChars" setting. This setting adds the ability to block passwords if they contain 3 or more sequential characters such as ABC or abc or 123 or def or 456, etc. This setting was added at the request of user "L Kang".
(update 1.3.21.2: revision to BlockSequentialChars where abc and 123 will be blocked, but not !@#)
v1.3.21
New version v1.3.21
Highlights of this release are:
-
Completely removed ETW logging and moved to basic text file logging. After all these years, I am finally admitting publicly that I was just trying to be a cool Windows guru and that I was just being sadistic by trying to force people to use ETW. ETW has its uses but it's really awful for when you really just want a log file. The log file is \Windows\System32\PassFiltEx.log and the log is rotated after it reaches 1MB. By default only error messages are logged, but if you use the Debug registry setting in the PassFiltEx subkey, it will enable additional informational messages. Updated the README with this information.
-
Added a "BlockSequentialChars" setting. This setting adds the ability to block passwords if they contain 3 or more sequential characters such as ABC or abc or 123 or def or 456, etc. This setting was added at the request of user "L Kang".
v1.2.20
v1.1.10
- Added a new "require either upper case or lower case" to the RequiredCharClasses registry setting - it is 0n32.
- Changed the test program PassFiltExTest. You can use it to test whether PassFiltEx will allow a password or not without having to do all the hassle of installing it on a DC and deciphering the ETW tracing. BUT it only works on the DEBUG build.
v1.1.9
v1.1.8
Minor bug fixes:
-
The filter was allowing a blank password. Not a big deal, since other Active Directory policy would have already prevented a blank password anyway. But it's hard to imagine any scenario where an administrator would want to allow any blank passwords and also have this password filter installed at the same time.
-
The filter was not lowercase'ing the last character, meaning that a password could potentially erroneously pass the blacklist if the last character in the blacklisted token was uppercase.