RE: audit-tools and SUDO
OK, thank you.
I will do/try that and see if it makes a difference and then report-back to close out this
thread.
Thanks Steve,
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 10, 2016 11:45 AM
To: Warron S French <warron.s.french(a)aero.org>
Cc: linux-audit(a)redhat.com
Subject: Re: audit-tools and SUDO
On Tuesday, May 10, 2016 03:25:36 PM Warron S French wrote:
> The lab works as expected, but my production environment does
not.
> %-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do
the same on the server to see if events are getting there. Then look
in syslog for anything that might give a clue. And then you can also
tail -f /var/log/audit/audit.log to see if things are getting written to disk.
\\ Steve, I know that I am receiving inputs to the server; because I
can see events that I am purposely triggering based on 2 rules that I
added and know how to cause an event; it is just that the node=client1
(for example) aren't being sent along with the line being recorded.
Does this troubleshooting step still make sense anyway?
No. If you are getting events at the server and audispd.conf has name_format= hostname, it
should be working.
If this was set after the audit daemon on the clients started, then you need to restart
the audit daemon for the name to take effect. As written, it collects the name one time at
start up and uses it in all future events. This could be changed but that is how its doing
today.
If you restart auditd on a non-systemd OS, this will cause the admin's auid to get
stuck into the audit daemon's task structure and will cause problems. So, the cleanest
thing to do is reboot the work station so that audispd has the hostname and your auid is
not in daemons.
-Steve