Description of problem: One of our customers reported a problem when setting [security_compliance]/disable_user_account_days_inactive configuration option in keystone breaks authentication in their overcloud. In their deployment and in my RHOSP 16/17 labs I see the same picture: last_active_at column contain NULL values instead of valid timestamps. As a result, when keystone checks if user is enabled, it falls back to created_at value, which happened more than disable_user_account_days_inactive days ago, so user is expired from keystone's perspective. Same behavior is observed in both RHOSP 17 and RHOSP 16 deployment. I will create a separate bug for RHOSP 16 to figure out if we are going to backport it there. Version-Release number of selected component (if applicable): RHOSP 17 How reproducible: In an old lab where some overcloud user existed for a while: 1. Use this user to run some API calls 2. Set [security_compliance]/disable_user_account_days_inactive to 1 and restart keystone services 3. Try to run API calls again Actual results: ERROR (Unauthorized): The account is disabled for user: 181a9f7d2e404301b3ecdb95ef1d56dd. (HTTP 401) (Request-ID: req-3fc80bba-f6f5-4886-9b8e-7d7532d3500d) Expected results: API calls completed Additional info: Customer's keystone SQL dump is attached to support case.
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 (RHOSP 17.1.4 bug fix and enhancement 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/RHBA-2024:9974
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days