#49039 RHDS should ignore passwordMinAge if "password must reset" is true
Closed: wontfix 7 years ago Opened 8 years ago by nhosoi.

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

8 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

7 years ago

Metadata Update from @mreynolds:
- Custom field component reset
- Custom field reviewstatus adjusted to review
- Issue close_status updated to: None

7 years ago

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to ack (was: review)

7 years ago

ack, this looks good. Just a curious question, why are we removing the internal_op check?

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)

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

4 years ago

Log in to comment on this ticket.

Metadata