[Freeipa-users] Re: Extraction timestamp of nsAccountLock change

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 >