Closed dgr-en closed 1 year ago
After further investigation, this appears to be a bug
and not an enhancement
and a fix is underway.
Upon further review, we've noticed that there need to be some modifications to Test-PasswordPolicyConfig
.
While it won't make the v1.3.0 release, it has been set to the v1.4.0 milestone.
I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Code of Conduct
Description
If I give the
Invoke-PasswordPolicyManager
a drift JSON that does not explicitly contain the ESXi policy "retry=3 min=disabled,disabled,disabled,7,7," then the cmdlet fails.I suspect there is an ESXi policy check.
I would like to check against my specifications and not be bound by the default specifications of the module.
Use Case(s)
I would like to be free in my decision whether I use a password with 15 characters from 4 character classes or a password with 20 characters from 3 character classes. (lenth beats complexity).
I don't want to be restricted by the module.
A check against your own PasswordPolicyConfig JSON should be possible with all values.
Potential Configuration
Removed the hard ESXi policy check which causes the cmdlet to fail if the drift JSON does not contain specific ESXi policy values.
References
If I check against a JSON which contains the ESXi Policy "retry=3 min=disabled,disabled,disabled,20,20" then the cmdlet failed with the following messages: