Closed v-p-b closed 1 year ago
You refer to a CIS benchmark list, there the CIS specifications are implemented accordingly in HardeningKitty finding lists and I have no influence on which values are set
I think - considering the meaning of possible values - CIS is vague here, as "lockout never expires" can be interpreted as "lockout expires later than 15 minutes".
Note that this requirement is also reflected in MS Security Baseline lists, but I can't test the official compliance tool right now.
Since this case is unclear even at the level of the compliance requirement definitions, I think it'd be fair to close this issue, but I also see the benefit in having this documented at least as part of this issue.
CIS sees an impact with setting the value to 0 (never):
Although it may seem like a good idea to configure this policy setting to never automatically unlock an account, such a configuration can increase the number of requests that your organization's help desk receives to unlock accounts that were locked by mistake.
This would make it possible to deliberately block users and to launch a kind of denial of service attack, as they would have to be manually unlocked by admins
Thanks for the feedback, I definitely don't want to start arguing about CIS here. Closing this one.
According to my tests when Account Lockout Duration is set to 0, Windows reports the value as "Never", which is also reflected in HardeningKitty's output.
According to documentation:
HardeningKitty specifies a numeric threshold for this value, while a) the "Never" string can't be handled with such a rule b) 0 as a special case can't be handled by a "bigger is better" kind of rule
I think the "0" setting is more secure than any expiring value, so it should be accepted, but I don't know how much flexibility the rule format of HardeningKitty provides to handle the above edge case.