Configure account lockout duration and failure-counter reset window.
389-AC-009 - severity: medium
| Field | Value |
|---|---|
| Control ID | 389-AC-009 |
| Severity | medium |
| Type | preventive |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | AC-7 |
| DISA SRG | SRG-APP-000065 |
Rationale¶
Enabling account lockout (389-AC-004) creates the mechanism, but the lockout duration and failure-counter reset window determine whether that mechanism is effective against real-world attack patterns. A lockout duration that is too short (or zero, which means permanent lock) either allows rapid retry after an insignificant delay or generates excessive help-desk load that prompts operators to disable lockout entirely. The failure-counter reset window (passwordResetFailureCount) is equally critical: without it, an attacker using a slow, distributed approach that spaces failures minutes apart can evade the counter indefinitely, bypassing lockout while still guessing thousands of passwords over time. A 15-minute reset window (900 seconds) forces failures to cluster within a meaningful interval to count toward lockout, defeating slow-and-low attacks that 389-AC-004 alone cannot catch. Both this control and 389-AC-004 must be applied together; neither is sufficient on its own.
Check¶
Verify that the lockout duration is at least 1800 seconds and the failure-counter reset window is set.
dsconf <instance> pwpolicy get | grep -i -E "passwordlockoutduration|passwordresetfailcount"
Expected: passwordLockoutDuration: 1800 / passwordResetFailureCount: 900
Remediation¶
Set the account lockout duration to 30 minutes and the failure-counter reset window to 15 minutes.
dsconf <instance> pwpolicy set --pwdlockoutduration=1800 --pwdresetfailcount=900
References¶
Implementation Notes¶
--pwdlockoutduration sets the number of seconds a locked account remains unavailable before automatically unlocking (0 = permanent lock until administrator intervention). --pwdresetfailcount sets the observation window in seconds: the failure counter is reset to zero if no additional failures occur within this window, preventing scattered failures from accumulating across hours. Both values must be tuned together with the threshold from 389-AC-004 - a very short reset window combined with a high threshold weakens the control. Permanently locked accounts (lockout duration 0) provide stronger security but increase operational burden; use 1800 s as the default and accept a help-desk workflow for edge cases. Locked accounts can always be manually unlocked with dsidm <instance> user unlock <uid>.