This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 2294901 - [RHOSP16] last_active_at column is not updated in user table after authentication
Summary: [RHOSP16] last_active_at column is not updated in user table after authentica...
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 16.2 (Train)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: async
: 16.2 (Train on RHEL 8.4)
Assignee: Douglas Mendizábal
QA Contact: Jeremy Agee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-07-01 13:33 UTC by Alex Stupnikov
Modified: 2025-01-07 11:30 UTC (History)
6 users (show)

Fixed In Version: openstack-keystone-16.0.3-2.20230826184852.el8ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-12-20 19:28:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-32412 0 None None None 2024-07-01 13:35:55 UTC
Red Hat Issue Tracker OSP-33329 0 None None None 2025-01-06 16:16:06 UTC
Red Hat Issue Tracker   OSPRH-12618 0 None None None 2024-12-20 19:28:52 UTC

Internal Links: 2294892 2294900

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.
Note You need to log in before you can comment on or make changes to this bug.