User Manager Software

One of the most time-consuming tasks of every system administrator (Linux or not) is user account maintenance. Whether adding or removing accounts, or even occasional suspending or enabling, it is definitely something that can be done by a user other than root. Why spend time going through a stack of papers on your desk with one thousand user accounts to modify when the person who wrote the work orders in the first place could just as easily do it?

Now you may ask, “How are these people supposed to do this job? I am not giving out the root password!” Well, to get around the password problem, I have a quite simple response: use sudo (pronounced soo-doo). You can get this neat little gem from http://www.courtesan.com/sudo/. sudo allows a permitted user to execute a command as superuser (real and effective UID is set to 0, and GID is set to root's group ID as set in the password file). Using a utility like this, you can permit certain users to run certain programs, such as an adduser script or a chfn command. Although certain sanity checks must be in place, I have found sudo to be a viable solution to keeping the root password secure.

To get around the problem of letting others mess with user accounts, I created User Manager. Now I rarely spend time dealing with user accounts. User management is done by the technicians, the billing department and the salespeople. User Manager, primarily a Korn shell script, does it all. (The Korn shell can be obtained from ftp://ftp.cs.mun.ca/pub/pdksh/.)

The User Manager script is a framework for your system that can be customized to add in RADIUS support, multi-homing support and domain management. For example, one system I set up builds all DNS, web and stats package configurations and sets up the user account for a multi-home web customer. It was fairly simple to add this support to the script, and it provides a great learning base in system automation.

The User Manager tar archive file can be found at ftp://ftp.inetinc.net/pub/usrmgr/usrmgr.tgz. It includes the usrmgr Korn shell script, a C program and a simple Perl script, a README file, an INSTALL file and an ASCII welcome screen. The C program, newpass.c, helps with encrypting new user passwords and the Perl script, loginterp.pl, generates reports from information logged when User Manager is run.

In order to configure the User Manager software, you should know the locations of several common utilities on your system. Some of these include finger, sed, edquota, sort and mail. You can see the complete list in the sidebar “Programs and their Locations”. Make sure all of these are set correctly in usrmgr before running the script. If they are not, the script will not execute properly—steps may be left out.

Once you have the locations of the programs set up, you have some choices to make. Where do you want your log file to go? Where do you want the scripts to reside? Which administrator (or administrators) will be receiving e-mail messages noting the user's actions? Here are the answers I gave when I set up my system:

Note that the administrators can be local user names and/or full Internet e-mail addresses. For multiple entries, simply separate each address with a comma and no spaces.

The reports generated by User Manager's Perl script can be very helpful tools, not only for your system administration team but also for the billing and administrative personnel at your company. With sudo installed, the reports list the user name of each person who ran User Manager, instead of just logging everything as root. Listings 1 and 2 show the two different report formats available.

The simple log in Listing 1 is summary information aimed at system administrators. It lists the number of adds, suspends, enables and deletes performed by each user and can be used to track any unwanted or unauthorized users who might be abusing User Manager. If you set up your system to allow only administrators to access User Manager through sudo, you can easily track malicious activity by checking what root is doing. If the machine where I obtained the Listing 1 data was a production machine, I would be very wary of the one add done by root, and would check the detailed logs for more information.

Listing 2 shows a more detailed report that can be turned on or off by setting verbose to 0 or 1 in the loginterp.pl script. My personal recommendation is to leave it on so that you can send these reports to your billing and account managing crew. It is also helpful in investigating any malicious activities which may have shown up in the summary reports.

For example, one entry in the summary report detected root doing an add to a user's record:

Function Performed:  User Added
Done by:    root
Login:     jhanish
Password:    ilovesouthpark
UID:      1003
GID:      1003
Real Name:   Joe Hanish
Home:      /home/jhanish
Shell:     /bin/tcsh
Date:      07.29.1998

One might deduce that a possible security hole was exploited and now a new user, jhanish, has been added to the system. So, we take a look at the /etc/passwd entry to see what else may have happened.

jhanish:x:0:1003:Joe Hanish:/home/jhanish:/bin/tcsh

You may want to set a cron job to run loginterp.pl on a weekly or monthly basis to generate report files and send them automatically to administrators through e-mail. For example:

6 0 1 * * root /usr/local/bin/loginterp.pl |
mail -s UserMGRLogs root,billing