allow change password upon first use as user

[Paul Peereboom]

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)

Desired situation: User can reset it's own password on first use.

[Lance Bragstad (lbragstad)]

Hi Paul,

Do you know if the user being locked out has the appropriate user options set?

https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#force-users-to-change-password-upon-first-use

[Paul Peereboom (peereb)]

Hi Lance,

I've created a regular user that should change it's password when logging in for the first time. I did not set "ignore_change_password_upon_first_use": true because I want the user to be forced to change it's password.

I'm not sure what user options I need to set for the user in order for the user to be able to change it's own password.

Regards,
Paul

[Morgan Fainberg (mdrnstm)]

Keystone does not allow "login" for locked passwords, which includes ones marked for "change before first use". Horizon needs to implement a "change password form" (or a user must use the /v3/users/password API directly).

This is not something that can/will be fixed in keystone.

[Morgan Fainberg (mdrnstm)]

I have added horizon to the bug, as they would need to implement this feature directly.

[Morgan Fainberg (mdrnstm)]

Horizon needs to implement a "change password form" (or a user must use the /v3/users/password API directly) that does not require direct (normal token) login first. * [in addendum to comment #3]

[Lance Bragstad (lbragstad)]

I was able to verify this feature works, but more importantly why this was failing for Paul. I did the following

 1. Created a new user called lbragstad with a password of `password`
 2. Set keystone.conf [security_compliance] change_password_upon_first_user = True
 3. Restarted keystone to apply the config changes
 4. Attempted to change my password as lbragstad using python-openstackclient

This actually fails because python-openstackclient is going to attempt to get a token from keystone as the user authenticating (lbragstad in this case). This is doine for discovery purposes, but it results in a 401 because of the logic in keystone.

Alternatively, if I build a request to change my password and use keystone API directly, I can successfully change my password [0].

Hopefully this helps. I agree with Morgan in that we need to update the clients and horizon to be smarter about this specific API and forego getting a token to avoid the 401.

[0] http://paste.openstack.org/raw/731863/

[Paul Peereboom (peereb)]

Thanks for clarifying Lance and Morgan, we have a lot of customers who only uses horizon or openstackclient so forcing a password change via API is something we cannot do. But I agree this is more a rfe for horizon/openstackclient than for keystone.

[Ziyu Bai (baiziyu-inspur)]

Should this be forced? For example, one user has to change the password when first use, otherwise he cannot do anything.

[Paul Peereboom (peereb)]

Yes, i believe it is forced already. A user that has password expired has only access to the /v3/users/password API. And cannot change anything else.

[Ziyu Bai (baiziyu-inspur)]

So this might be a huge change.

[Radomir Dopieralski (deshipu)]

I'm working on implementing this for Horizon, and I have a working view where the user can change their password (https://review.opendev.org/672289). However, for this to be actually usable, the user has to know their user_id somehow. As far as I can tell, there is no way to determine the user_id from username without first authenticating, so the users still can't change their expired passwords.

[Colleen Murphy (krinkle)]

Since this is for new users only, the admin will need to provide the user with enough information to be able to change their password before first login, like some kind of onboarding packet. This would have to include their user ID. There's no way that keystone could supply the user's ID without the user first authenticating. Re-marking this as invalid for keystone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/692945
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=c0cc0433c645181a9031b99d23954ae9bece9542
Submitter: Zuul
Branch: master

commit c0cc0433c645181a9031b99d23954ae9bece9542
Author: Ivan Kolodyazhny <email address hidden>
Date: Tue Nov 5 12:20:28 2019 +0800

    Fix change expired password feature

    Closes-Bug: #1791111
    Change-Id: I5f2a027149be490613e7661b895325a63374334d

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/697630

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/697630
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=1229bd4bb43882d681937ad799a3a2c8a37193e6
Submitter: Zuul
Branch: stable/train

commit 1229bd4bb43882d681937ad799a3a2c8a37193e6
Author: Ivan Kolodyazhny <email address hidden>
Date: Tue Nov 5 12:20:28 2019 +0800

    Fix change expired password feature

    Closes-Bug: #1791111
    Change-Id: I5f2a027149be490613e7661b895325a63374334d
    (cherry picked from commit c0cc0433c645181a9031b99d23954ae9bece9542)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/horizon 17.1.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/horizon 16.1.0 release.