Description of problem: Customer has specified the following password policy: nsslapd-pwpolicy-local: on passwordLockout: on passwordUnlock: off passwordLockoutDuration: 3600 passwordIsGlobalPolicy: on passwordChange: on passwordGraceLimit: 3 passwordExp: on passwordMustChange: on passwordMaxAge: 7776000 passwordWarning: 604800 passwordMinAge: 86400 passwordHistory: on passwordInHistory: 6 passwordCheckSyntax: on passwordMinLength: 8 passwordMinAlphas: 1 passwordMinDigits: 1 passwordMinSpecials: 1 passwordMinCategories: 3 Customer noticed that if an user's password is reset by "cn=directory manager", the user gets "Password change failed. Server message: Please make sure the password meets the complexity constraints" when ssh into a sssd client, even though the same password gets accepted happily via ldapmodify! $ ldapmodify [...] -D "uid=ASmith,ou=People,dc=example,dc=com" -w T0_change_n0w Sat 12 Nov 06:29:34 EST 2016 dn: uid=ASmith,ou=People,dc=example,dc=com changetype: modify replace: userpassword userpassword: Ge9EiG#oh5Ee <<<<<<< From a sssd client: $ ldappasswd -ZZ [...] -D "uid=ASmith,ou=People,dc=example,dc=com" -w T0_change_n0w -s Ge9EiG#oh5Ee "uid=ASmith,ou=People,dc=example,dc=com" Result: Constraint violation (19) Additional info: Failed to update password also via ssh: $ ssh asmith@myhost.redhat.com asmith@myhost.redhat.com's password: Password expired. Change your password now. Last login: Mon Nov 14 21:17:05 2016 from localhost.redhat.com ... WARNING: Your password has expired. You must change your password now and login again! Changing password for user asmith@example.com. Current Password: New password: <<<<type in Ge9EiG#oh5Ee <<<<<<< Retype new password: <<<<type in Ge9EiG#oh5Ee <<<<<<< Password change failed. Server message: Please make sure the password meets the complexity constraints. passwd: Authentication token is no longer valid; new one required Corresponding DS' access log shows: [14/Nov/2016:08:10:26.499614367 -0500] conn=314 op=2 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin" [14/Nov/2016:08:10:26.500434883 -0500] conn=314 op=2 RESULT err=19 tag=120 nentries=0 etime=0 The reason of the failure is due to the following: nscpentrywsi: passwordAllowChangeTime: 20161121112040Z nscpentrywsi: passwordGraceUserTime: 0 nscpentrywsi: passwordExpirationTime: 19700101000000Z nscpentrywsi: passwordExpWarned: 1 Resetting the password as "cn=directory manager" change passwordExpirationTime to 19700101000000Z, i.e. no password expiration date, but the passwordAllowChangeTime is still in the past! Version-Release number of selected component (if applicable): sssd-1.13.0-40.el7_2.12.x86_64 RHDS10 How reproducible: Steps to Reproduce: 1. Setup a RHDS10 server, configure the password policy as above. 2. Setup RHEL7.2 sssd client 3. Configure TLS on RHDS10 server 4. Create an user on RHDS10 and then reset the user's password as "cn=directory manager" 5. Attempt to update the user's password via ldapmodify as well as via ldappasswd on sssd client. Actual results: Expected results: If password policy enforces "passwordMustChange: on" then we should not check passwordMinAge. This should be independent of whether update is done via ldapmodify or ldappasswd. Additional info:
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Issue assigned to mreynolds
<img alt="0001-Issue-49039-password-min-age-should-be-ignored-if-pa.patch" src="/389-ds-base/issue/raw/files/3a1577378989e434ec0c52110cd7fff241aee6bd1dadf16d4c3559f3d9052c6e-0001-Issue-49039-password-min-age-should-be-ignored-if-pa.patch" />
Metadata Update from @mreynolds: - Custom field component reset - Custom field reviewstatus adjusted to review - Issue close_status updated to: None
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to ack (was: review)
ack, this looks good. Just a curious question, why are we removing the internal_op check?
Because when we use the password extended op it is also an internal operation. I'm not sure why that check was there, but it breaks the logic of the policy.
Ahhh makes sense. Cool, so long as there is a reason for removal, I'm all good. ack :)
e59420e..3129a94 master -> master
3ec54f8..ca10ec7 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
636b0f4..a736032 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2098
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Log in to comment on this ticket.