I’m creating a script that creates a new AD user. I’m trying to determine not the “good enough”-way, but thee way, to enforce password complexity requirements upon entering a new password for a newly created user.
I’ve seen several posted examples that test AD password complexity requirements with IF blocks and all have fallen short in terms of correctly implementing the official MS documentation password complexity requirements. One example of a commonly overlooked complexity requirement is:
“The samAccountName is checked in its entirety only to determine whether it’s part of the password. If the samAccountName is fewer than three characters long, this check is skipped.”
This silly example is easy to incorporate into an IF block. The one requirement that has fallen short in every script I’ve seen thus far (in terms of using an IF block) is this:
Any Unicode character that’s categorized as an alphabetic character but isn’t uppercase or lowercase. This group includes Unicode characters from Asian languages.
The solutions suggested and posted have ranged from “This regex gets you 91% of the way there, why isn’t that good enough for prod? Why isn’t ‘good enough’ good enough for you?” to leveraging a try/catch block.
This example evidently worked in 2014 but isn’t working for me in PS 5.1/Server 2019. The current (as of 9/2021) online Help documentation for New-ADUser (this applies to Server 2012 through 2019) mentions that the account will be created anyways, even if setting the password fails:
If you provide a password, an attempt will be made to set that password however, this can fail due to password policy restrictions. The user account will still be created and you may use Set-ADAccountPassword to set the password on that account.
I am guessing this is why try/catch doesn’t work, because the command New-ADUser didn’t fully fail, although it will throw the exception [Microsoft.ActiveDirectory.Management.ADPasswordComplexityException]
I’m skeptical of solutions that involve using regex and if blocks to test for compliance for the unicode clause because of the sheer volume of chars allowed, even though using a regex to filter seems tempting because of the amount of ground it can cover. This example seemed like a good starting point, but a user mentions in the comments section a few tests that prove that script as another example that falls short of going the full distance in checking every possible exception (e.g. they used the copyright symbol for one particular test - which is an allowed char in passwords). I’ve read up on regex and still cannot determine what perfect regex pattern can fulfill the demands of the password complexity requirements as they are officially documented. This is has me leaning towards try/catch, but I can’t figure out why that won’t work - again, probably because the cmdlet New-ADUser doesn’t fully fail in the case of a bad password, yet it throws an exception.
Clearly there is code running under the hood that catches a password complexity violation when using the GUI wizard in ADUC to make a new user (and it doesn’t create a new disabled user). Is there an exposed DLL function I can invoke that will do this check instead of a try/catch or worse, using a regex to recognize all allowed unicode chars that are neither upper or lowecase? I’ve used procmon to see what DLLs are being used in the GUI ADUC new user wizard – and Dependencies to inspect their exposed functions (in addition to spending time combing through Win API documentation) – but I haven’t come up with anything.
My question is:
How can I prevent a new disabled user from being created if the password complexity requirements are NOT met, as indicated by the presence of [Microsoft.ActiveDirectory.Management.ADPasswordComplexityException] ?
