Yep! Just the main system the user admins work from as it has storage space.
That looks like the method for this level of detail I need. Thanks Rob! On Thu, Sep 22, 2022, 4:23 PM Rob Crittenden <[email protected]> wrote: > 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 <[email protected] > > <mailto:[email protected]>> 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 > > > >
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
