Useradd/del needs to be logged in syslog

[P Arumugavel]

Hi All,

Please help me how we can edit /etc/syslog.conf or any other changes for syslog.log to capture useradd and userdel commands.

Rgds...

[g3jza]

Hi,
don't know whether this is possible, but you can implement auditing to possibly select type of commands that you want to log.

#man audsys
#man audomon

[E.Gopi Kannan]

Hello All,

Even I got the same request...!!

After logged in as root, Is ther any possiblities to log the useradd/del in syslog.log????

Here we dont ve sudo facility..!!

Thanks in adavance!

[Matti_Kurkela]

The regular useradd/userdel commands won't generate any syslog messages. So if you want the commands logged using the syslog mechanism specifically, you must replace the regular useradd/userdel with something that will do it.

For example:

# mv /usr/sbin/useradd /usr/sbin/useradd.real
# vi /usr/sbin/useradd
-----
#!/usr/bin/sh
/usr/sbin/useradd.real "$@"
RESULT=$?
if [ $RESULT -eq 0 ]; then
logger -t useradd -p local0.notice -i "\"useradd $*\" executed successfully by $(whoami)"
else
logger -t useradd -p local0.notice -i "Failed \"useradd $*\" attempt by $(whoami)"
fi
return $RESULT
----
# chmod a+x /usr/sbin/useradd

... and similarly for userdel.

Note: when you install Quality Packs or other patches, the patch may replace the modifications with HP standard useradd/userdel commands.

Note 2: nothing prevents a sysadmin from running /usr/sbin/useradd.real instead of the "normal" useradd command, bypassing the logging. But nothing also prevents a sysadmin from creating/deleting users by editing the necessary files manually, without using the useradd command at all!

The audit subsystem, as suggested by g3jza, would be better if it's a requirement that bypassing the logging should not be easy.

MK

[Arockiasamy K]

Hi Arumugavel,

One more way is make sudo and configure it for the user.
If anyone uses the sudo, that will be reflected in syslog.log.

Regards,
Arockiasamy K

[klb]

Matti wrote: "nothing also prevents a sysadmin from creating/deleting users by editing the necessary files manually"

Right. This is the way I and those that I learned from have been doing it since the beginning: manually.

Good point.

[Bill Hassell]

Here's a preliminary copy of a blog by Patrick Walleck:

The self-auditing explanation is below (from â man 5 auditâ ):

Self-auditing Programs
To reduce the amount of log data and to provide a higher-level
recording of some typical system operations, a collection of
privileged programs are given capabilities to perform self-auditing.
This means that the programs can suspend the currently specified
auditing on themselves and produce a high-level description of the
operations they perform. These self-auditing programs are described
in the following manpages: at(1), chfn(1), chsh(1), crontab(1),
login(1), newgrp(1), passwd(1), audevent(1M), audisp(1M), audsys(1M),
audusr(1M), cron(1M), groupadd(1M), groupdel(1M), groupmod(1M),
init(1M), lpsched(1M), sam(1M), useradd(1M), userdel(1M), and
usermod(1M).

To enable auditing of these functions, do the following:

1) Create a new rule in /etc/audit/audit.conf. This is a regular text file and can be edited with â viâ . Create a new line like the one below:

EVENT admin2= SELFAUD_EVENT admin

This category will just record audit events from programs that are self-auditing at the admin level. However, during my testing it appears that some of the commands listed above did not self-audit. I did not find any entries in the audit file for the following commands when I ran them: at; crontab; newgrp; getting into SAM doesn't seem to be audited, but actions taken in sam (usermod for example) seem to be; lpsched; init (at least 'init q')

2) Edit the /etc/rc.config.d/auditing file so it looks like the following:

AUDITING=1
PRI_AUDFILE=/var/.audit/audfile1
PRI_SWITCH=1000
SEC_AUDFILE=/var/.audit/audfile2
SEC_SWITCH=1000
AUDEVENT_ARGS1="-P -F -e admin2"
AUDEVENT_ARGS2=""
AUDEVENT_ARGS3=""
AUDEVENT_ARGS4=""
AUDOMON_ARGS=" -p 20 -t 1 -w 90"

The location of the audit files can be changed to whatever is required. With the limited set of actions being audited I would not expect the audit files to grow very fast.

An explanation of the arguments used for the AUDEVENT_ARGS and AUDOMON_ARGS are at the end of this document.

3) Start auditing by doing:

/sbin/init.d/auditing start

4) Once auditing is running you can display the audit data with the â audispâ command.
To create a viewable file of the audited info: 'audisp /var/.audit/audfile1 > auditfile.txt' or
'audisp /var/.audit/audfile2 > auditfile.txt'



AUDEVENT ARGS meanings:
===========================================

-P - Audit successful events

-F - audit failed events

-e admin2 - audit only based on the admin2 rule above

AUDOMON ARGS meanings:

-p 20
-p fss
Specify the FileSpaceSwitch by a number ranging from 0 to 100. When the file system that contains the current audit trail has less than fss percent free space remaining, audomon looks for a backup audit trail. If available, the backup trail is designated as the new audit trail. If no backup trail is available, the auditing system creates a new audit trail with the same base name but a different timestamp extension and begins recording to it.

-t 1
-t sp_freq
Specify the wake-up switch-point frequency in minutes. The wake-up frequency is calculated based on sp_freq and the current capacity of the audit trail and the file system.

The calculated wake-up frequency at any time before the switch points is larger than sp_freq. As the size of the audit trail or the file system's free space approaches the switch points, the wake-up frequency approaches sp_freq. sp_freq can be any positive real number.

The default sp_freq is 1 (minute).

-w 90
-w warning
Specify that warning messages be sent before the switch points. warning is an integer ranging from 0 through 100.

The higher the warning, the closer to the switch points warning messages are issued. For example, warning set to 50 causes warning messages to be sent half-way before the switch points are reached. warning set to 100 causes warning messages to be sent only after the designated switch points are reached and a switch is not possible due to a missing backup trail.

By default, warning is 90.

Note: The warning message is not sent if the audit trail size grows beyond the switch points in between two consecutive audomon wakeup intervals. In this case, audomon only performs the switch to next audit trail.

============================

However, as mentioned before vi or vipw for the /etc/passwd file is not audited. Even with full audit extension at 11.31, a single file such as /etc/passwd can't be monitored. So about all you can do is to run a cron job to check /etc/passwd for changes and log/email the findings.

[Patrick Wallek]

As per Bill's note response above, the blog post he mentions is here:

http://blog.sourcedirect.com

Look for the post â AUDITING HP-UX User Creation, Deletion and Modificationâ posted on May 23, 2011.