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.