Version 1.0
Author: Tom Adelstein <tom [dot] adelstein [at] gmail [dot] com>
Falko Timme <ft [at] falkotimme [dot] com>
Last edited 04/04/2006
Employee turnover in most organizations runs high. So unless you run a small shop with a stable user base, you need to learn how to clean up after an employee leaves. Too many so-called system administrators do not understand the stakes involved when they manage users. Disgruntled former employees can often cause significant trouble for a company by gaining access to the network.
To remove a user, you need to learn to manage all of his or her files, mailboxes, mail aliases, print jobs, recurring –(automatic) personal processes such as the backing up of data or remote syncing of directories, and other references to the user. It is a good idea at first to disable the account in /etc/passwd, after which you can search for the user’s files and other references. Once all traces of the user have been cleaned up, you can remove the user completely—but if you remove the entry from /etc/passwd while these other references exist, you have a harder time referring to them .
When you remove a user, it’s a good idea to follow a pre-determined course of action so you don’t forget any important steps; it may even be a good idea to make a checklist so that you have a routine. Following, you will find several items requiring attention.
1 Disable The User’s Password
The first task is to disable the user’s password, effectively locking him out. For example:
# passwd -l bwilson
Sometimes it’s necessary to temporarily disable an account without removing it. For example, the user might go on maternity leave or take a post for 90 days in another country. You may also discover from your system logs that someone has gained unauthorized control of an account by guessing the password. The passwd -l command is useful for these situations. It locks (therefore -l) the account by changing the password to a value that cannot be matched by any possible encrypted value.
2 Find The User’s Files
Next, you have to decide what to do with the user’s files. Remember that users may have files outside their home directory. The find command can find them:
# find / -user bwilson
You can then decide whether to delete these files or keep them as discussed later in the section “Sealing the home directory.” If you decide to delete them, back them up in case you need data from them later.
3 Change The Login Shell
As extra security, you can change the user’s login shell to a dummy value. Simply change the last line in the /etc/passwd file to something like * or /dev/null.
For example, if you have this line for bwilson in /etc/passwd:
bwilson:x:1023:1023:Brian Wilson:/home/bwilson:/bin/bash
|
you can change it to this:
bwilson:x:1023:1023:Brian Wilson:/home/bwilson:/dev/null
|
4 Remove SSH Keys
If your organization uses Secure Shell (SSH, usually provided on Linux by OpenSSH) and you allow remote RSA or DSA key authentication, a user can get access to the system even if the password is disabled. This is because SSH uses separate keys. For instance, even after you have locked Brian Wilson out of your system using the steps shown up to now, he could get on another computer somewhere and run a command such as:
bwilson:~$ ssh -f -N -L8000:intranet.yourcompany.com:80 my.domain.com
This forwards traffic to port 80 (the port on which a web server usually listens) on your internal servert. We will discuss this type of activity in more detail in the security section of this book. Obviously, if your system offers SSH, you should remove authorized keys from ~bwilson/.ssh or ~bwilson/.ssh2 directories in order to stop a user from regaining access to his account this way. Likewise, look for shosts and rhosts files in the user’s home directory: ~bwilson/.shosts and ~bwilson/.rhosts.
For example, if bwilson’s home directory is /home/bwilson, you can remove these keys like this:
# rm -fr /home/bwilson/.ssh/*
# rm -fr /home/bwilson/.ssh2/*
# rm -fr /home/bwilson/.shosts
# rm -fr /home/bwilson/.rhosts
5 Kill The User’s Processes
Also, check to see if the user still has any processes running on the system. Such processes might act as a backdoor to allow a user into a network The following command will tell you if any are running currently.
# ps aux | grep -i ^bwilson
If you get an output like this:
bwilson 1960 0.0 0.2 1684 628 ? Ss 10:10 0:00 /usr/sbin/someprocess
|
Then you can kill the process like this:
# kill -9 1960
where 1960 is the process ID (pid).
Some other questions a system administrator might ask about a personal user who has left the company include:
- Could bwilson execute Common Gate Interface (CGI) scripts from his home directory or on one of the company’s web servers?
- Do any email forwarding files such as ~bwilson/.forward exist? Users can utilize forwarders to send mail to their accounts and cause programs to be executed on the system where they supposedly do not have access.
6 Remove The User’s Cron Jobs
The next step is to check whether the user has cron jobs, and to delete or disable them if he does. We can use the crontab command to find out if he has cron jobs:
# crontab -u bwilson -l
If you see that bwilson has cron jobs, you can disable them by running
# crontab -u bwilson -e
In the crontab editor that pops up you can simply disable all cron jobs by commenting them out (i.e., by prepending with a #). For instance, you can disable
50 23 * * * /usr/bin/someprocess
|
like this:
#50 23 * * * /usr/bin/someprocess
|
Instead of disabling the cron jobs of bwilson, you can as well delete them by running
# crontab -u bwilson -r
7 Sealing The Home Directory
You will often find that management wants to retain the information in the directory of an employee who leaves. All the email and other documents in a personal user’s account belong to the company. In the event a disgruntled former employee becomes litigious, the company’s legal counsel may want these files. Many analysts consider the keeping such directories as good practice.You can save the contents of a user’s home directory by renaming it. Simply execute a move command:
# mv /home/bwilson /home/bwilson.locked
In this way, the former employee cannot log in or make any use of configuration files such as the .forward file discussed in the previous section. The contents remain intact if needed later.
8 Remove The User From sudoers
If you have sudo installed, you should also remove the user from /etc/sudoers or at least disable him there. You can do this with the visudo command:
# visudo
9 Check All Other Applications For Logins Of That User
You might also want to check all your other applications (e.g. MySQL) that don’t use system user logins but where the user to be removed might have logins under another username. You should check your web site, PHP scripts, etc. for user logins and disable the login for the user to be removed. I will give three other examples here:
9.1 Web Directories Protected By .htaccess/.htpasswd
You might have some directories on your web site that are password-protected by .htaccess/.htpasswd (for example, the web site statistics folder), and until now the user to be removed (I’ll name him bwilson here again, although the username might be completely different from the username we used so far because it is no system user this time) had access to these directories. You can remove bwilson’s login with the htpasswd command.
Let’s assume the .htpasswd file is /var/www/.htpasswd. Then you can remove bwilson’s login like this:
# htpasswd -D /var/www/.htpasswd bwilson
9.2 MySQL
If bwilson has a login for the company’s MySQL database, you can remove the login like this:
# mysql -u root -p
REVOKE ALL PRIVILEGES, GRANT OPTION FROM bwilson;
quit;
9.3 Postfix
If Postfix uses sasldb2 instead of the passwords in /etc/shadow, you must delete the user bwilson from /etc/sasldb2 – otherwise he will be able to send emails. You can do that with the saslpasswd2 command:
# saslpasswd2 -d bwilson
If you’re using SASL version 1 instead of version 2, then you must use the saslpasswd command:
# saslpasswd -d bwilson
The passwords are then stored in /etc/sasldb instead of /etc/sasldb2.
Quoted from: taft @ http://www.howtoforge.com/linux_remove_users
