Investigate password policy RFC draft implementation

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49383

• Created at 2017-09-22 18:13:50 by mreynolds (@mreynolds389)
• Assigned to nobody

---

Issue Description

https://www.ietf.org/archive/id/draft-behera-ldap-password-policy-10.txt

Investigate fully implementing this RFC for 389-ds-base-1.4.0

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-09-22 18:14:04

Metadata Update from @mreynolds389:

• Custom field component adjusted to None
• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None
• Custom field type adjusted to None
• Custom field version adjusted to None
• Issue set to the milestone: 1.4 backlog

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-10-18 21:35:26

Metadata Update from @mreynolds389:

• Issue tagged with: RFE

[droideck]

Just a note, there was a new version posted couple of years ago: https://www.ietf.org/archive/id/draft-behera-ldap-password-policy-11.txt

[tbordaz]

Looking at the RFC, the missing (doubts) parts are

• 4.2.7. Safe Modification (check previous password before changing) / 5.2.17. pwdSafeModify
• 4.3. Restriction of the Password Policy (password contains one and only one value)
• 5.2.18. pwdMinDelay / 5.2.19. pwdMaxDelay - delay to response to a failing bind
• 5.2.20. pwdMaxIdle (lockout an inactive account - it is enforced with accountpolicy plugin but not sure it enforce this specific attribute)
• 5.2.21. pwdMaxRecordedFailure (differs from pwdMaxFailure ?)
• 5.3.1. Password Policy State Attribute Option (applying password policy to others attribute)
• 5.3.4. pwdFailureTime (last failure UTC)
• 5.3.9. pwdStartTime and pwdEndTime (may be related to TPM recently implemented)
• 6.2. Response Control (not sure we conform all the error)

Then on the 8. Server Policy Enforcement Points we could implement all the described behaviour

[tbordaz]

If we are not able to work on it before summer 2026 then we should close it as wontfix