Bug 2294901

Summary: [RHOSP16] last_active_at column is not updated in user table after authentication
Product: Red Hat OpenStack Reporter: Alex Stupnikov <astupnik>
Component: openstack-keystoneAssignee: Douglas Mendizábal <dmendiza>
Status: CLOSED MIGRATED QA Contact: Jeremy Agee <jagee>
Severity: high Docs Contact:
Priority: high    
Version: 16.2 (Train)CC: alee, dwilde, jjoyce, mariel, oblaut, pweeks
Target Milestone: asyncKeywords: Reopened, Triaged
Target Release: 16.2 (Train on RHEL 8.4)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-keystone-16.0.3-2.20230826184852.el8ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-12-20 19:28:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alex Stupnikov 2024-07-01 13:33:51 UTC 
This bug was initially created as a copy of Bug #2294900

I am copying this bug because: a separate discussion is needed to figure out if this is going to be backported to RHOSP 16.2 in the first place.


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.