Removing A User

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.