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.
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
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.
Re-assigning DFG:UI as primary contact for triaging this bug as required work will fall onto Horizon. More details in LP#1791111
I think this upstream blueprint is related to this issue: https://blueprints.launchpad.net/horizon/+spec/allow-users-change-expired-password
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
*** Bug 1940754 has been marked as a duplicate of this bug. ***