Limit the maximum password lifetime to enforce regular password changes.
389-AC-007 - severity: medium
| Field | Value |
|---|---|
| Control ID | 389-AC-007 |
| Severity | medium |
| Type | preventive |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | IA-5(1) |
| DISA SRG | SRG-APP-000174 |
Rationale¶
The maximum password age caps the lifetime of any credential, ensuring that even a silently compromised password is eventually rotated out before an attacker can fully exploit it. Without an explicit maximum age value, the server falls back to its compiled-in default (typically 8640000 seconds / 100 days), which may exceed compliance requirements and is less auditable than an explicitly configured value. This control addresses the age ceiling specifically and is documented separately from 389-AC-002 (which enables the expiration engine) to enable independent audit traceability: an auditor can verify the expiration flag and the maximum age value against separate compliance line items. Both must be present for expiration to function - passwordMaxAge has no effect if passwordExp is off (see 389-AC-002). DISA SRG-APP-000174 maps to both controls; 7776000 seconds (90 days) is the common baseline and can be reduced to 5184000 (60 days) for stricter frameworks.
Check¶
Verify that the maximum password age is set to 7776000 seconds (90 days) or less.
dsconf <instance> pwpolicy get | grep -i passwordmaxage
Expected: passwordMaxAge: 7776000
Remediation¶
Set the maximum password age to 90 days (7776000 seconds) in the global password policy.
dsconf <instance> pwpolicy set --pwdmaxage=7776000
References¶
Implementation Notes¶
This control sets the maximum age value only; --pwdexpire=on (389-AC-002) must also be set for expiration to be enforced. If only this control is applied without 389-AC-002, passwordMaxAge is present in the policy but passwords will not actually expire. Conversely, enabling expiration without setting a max age value will default to the server's compiled-in maximum (8640000 seconds / 100 days in most builds) - always set both explicitly. Service accounts that rely on long-lived bind credentials should be moved to a subtree policy with expiration disabled or with a longer max age, and their password rotation should be managed via a secrets-management process rather than left to individual users.