Jim Kinney via FreeIPA-users wrote: > Is there a way get the timestamp of when a user account was marked locked? > > I'm trying to show that a locked out user had an existing open > connection before the lockout happened. The next process that ran > through a pam login was properly denied but the screen shot indicates > they were already on a system. > > And, yes, policy change will include the account lock followed by an > aggressive kill -9 of all running process on all nodes. You're right in that locked means "can no longer authenticate" but it doesn't affect any existing connections. I think of a few ways. 1. The most efficient would be to write a 389-ds plugin to monitor mods such that when this attribute goes to TRUE then trigger something. The downside is you'd have to install and maintain this yourself, and deal with conflicts vs single-point-of-failure. And how/what the trigger is. 2. Write a service that does a persistent LDAP search on nsAccountLock and does...something. 3. Otherwise you're left with scraping logs, either the 389-ds audit log (best, and requires enablement) or the httpd error log (fine for any changes done via the API). rob

Jim Kinney wrote: > I've got a process killer for cluster switch over. Just need to call it > as part of the manual (for now) lock out process. > > My audit logs are empty. Looks like I have a config issue there. You have to explicitly enable the audit log. See the 389-ds docs. rob > I see nsAccountLock in the access logs but no indication of if there's a > value change. It shows up with SRCH but nothing else. > > The user admins work on a single server so I'm expecting to find the > data in those logs. But I'm not. > > On Thu, Sep 22, 2022, 1:19 PM Rob Crittenden <rcritten(a)redhat.com > <mailto:rcritten@redhat.com>> wrote: > > Jim Kinney via FreeIPA-users wrote: > > Is there a way get the timestamp of when a user account was marked > locked? > > > > I'm trying to show that a locked out user had an existing open > > connection before the lockout happened. The next process that ran > > through a pam login was properly denied but the screen shot indicates > > they were already on a system. > > > > And, yes, policy change will include the account lock followed by an > > aggressive kill -9 of all running process on all nodes. > > You're right in that locked means "can no longer authenticate" but it > doesn't affect any existing connections. > > I think of a few ways. > > 1. The most efficient would be to write a 389-ds plugin to monitor mods > such that when this attribute goes to TRUE then trigger something. The > downside is you'd have to install and maintain this yourself, and deal > with conflicts vs single-point-of-failure. And how/what the trigger is. > > 2. Write a service that does a persistent LDAP search on nsAccountLock > and does...something. > > 3. Otherwise you're left with scraping logs, either the 389-ds audit log > (best, and requires enablement) or the httpd error log (fine for any > changes done via the API). > > rob >