Bug 1628541

Summary: [RFE] change_password_upon_first_use=true should allow a user to change his password upon first use
Product: Red Hat OpenStack Reporter: Luca Miccini <lmiccini>
Component: python-django-horizonAssignee: Radomir Dopieralski <rdopiera>
Status: CLOSED ERRATA QA Contact: Tatiana Ovchinnikova <tovchinn>
Severity: high Docs Contact:
Priority: high    
Version: 13.0 (Queens)CC: aguetta, augol, ccopello, dcadzow, dwojewod, gregraka, hrybacki, jrist, kmehta, mbarnett, mmethot, nchandek, nkinder, nlevinki, pkesavar, rdopiera, rmascena, scohen, svmichel, tovchinn
Target Milestone: Upstream M3Keywords: FutureFeature, Triaged
Target Release: 16.0 (Train on RHEL 8.1)   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: python-django-horizon-16.1.0-0.20191120111947.338a58f.el8ost Doc Type: Enhancement
Doc Text:
In the Red Hat OpenStack Platform 16.0 dashboard (horizon), there is now a new form for changing a user's password. This form automatically appears when a user tries to sign on with an expired password.
 Story Points: ---
Clone Of:
: 1940754 (view as bug list) Environment:
Last Closed: 2020-02-06 14:37:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1940754    

Description Luca Miccini 2018-09-13 11:50:55 UTC 
Description of problem:

see https://bugs.launchpad.net/keystone/+bug/1791111

It's impossible to reset your password in user level if "change_password_upon_first_use" is set.

keystone.conf:
[security_compliance]
change_password_upon_first_use = True

For new users it's impossible to reset your password via keystone. You can only reset the password via an admin, which created the user in the first place. So now the change_password_upon_first_use is kinda useless.

(test2@test) [root@controller1 ~]# openstack user password set
The password is expired and needs to be changed for user: bd3cc251fe694b15be88c443aa752ec1. (HTTP 401) (Request-ID: req-cdc7ddaf-d2ec-49ac-9708-2693811eb819)


How reproducible:

always

Steps to Reproduce:
1. set change_password_upon_first_use=true in keystone.conf & restart httpd
2. create a new user
3. try logging in with the new user

Actual results:

Users are locked out and can't change their password.

This happens because the feature is implemented by expiring the password immediately after it has been set.

Expected results:

Users can reset their own password on first use.
Comment 1 Sven Michels 2018-09-19 14:19:55 UTC 
The same issue blocks general password expire. As soon as the users password has expired, he will not be able to change it again.

I found a note here:
https://docs.openstack.org/keystone/pike/admin/identity-keystone-usage-and-features.html
User CRUD.

Maybe this needs to be enanbled, too. But then still the behaviour of the client would probably needs adjustment.

Regards,
Sven
Comment 3 Harry Rybacki 2018-10-10 19:07:30 UTC 
After reviewing with upstream Keystone team, I have confirmed we are seeing expected behavior. That is to say, locked users (which this flag will produce) cannot login to Keystone -- or Horizon by proxy.

There change_password API is unprotected specifically for this use case. However, we are missing the ability to hit that API without being logged into Horizon. I'm adding the UI DFG to assist in the review. If they agree, we can either create a separate RFE RHBZ for that or port this RHBZ to maintain a single tracker for the Cu.
Comment 4 Harry Rybacki 2018-11-05 15:29:09 UTC 
Re-assigning DFG:UI as primary contact for triaging this bug as required work will fall onto Horizon. More details in LP#1791111
Comment 8 Radomir Dopieralski 2019-04-17 13:38:00 UTC 
I think this upstream blueprint is related to this issue: https://blueprints.launchpad.net/horizon/+spec/allow-users-change-expired-password
Comment 22 errata-xmlrpc 2020-02-06 14:37:23 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:0283
Comment 23 Radomir Dopieralski 2021-03-19 13:43:50 UTC 
*** Bug 1940754 has been marked as a duplicate of this bug. ***