Add parameter to Test-IsBannedWord to skip inbound normalization

[ryannewington]

suggestion.... you have Test-IsBannedWord which normalizes and it gives an unexpected result, IMHO

for example: "activedirectory" is in the Banned Words list

[1] Test-IsBannedWord "activedirectory" returns TRUE (expected) [2] Test-IsBannedWord "activedirect0ry" returns TRUE (expected) [3] Test-IsBannedWord "@ctivedirectory" returns FALSE (not expected)

with the last one it took some time to understand and I think the issue is due to the normalization rules where numbers and symbols at the beginning and end are stripped

Suggestion: Test-IsBannedWord --> no normalization and just to test is a word in its form is in the banned word list Test-IsBannedPassword --> supporting the actual password and the password after normalization rules

still does not solve the issue that I would be able to use @ctivedirectory as a password. The only thing I can think of is to test both the actual password and the stripped version after using normalization rules. Would require additional processing

Originally posted by @zjorz in https://github.com/lithnet/ad-password-protection/issues/22#issuecomment-517704607