Employee turnover in many 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.
Removing a user isn't a one-step process—you need to manage all of the user's 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 to first disable the user's account in /etc/passwd; after that, 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 (if you remove the entry from /etc/ passwd while these other references exist, you have a harder time specifying them).
When you remove a user, it's a good idea to follow a predetermined course of action so you don't forget any important steps; you may even want to make a checklist so that you have a routine laid out.
The first task is to disable the user's password, effectively locking him out. You can do this with a command like the following:
# passwd -l tadelste
Sometimes it's necessary to temporarily disable an account without removing it. For example, a 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 its password. The passwd -l command is useful for these situations as well.
Next, you have to decide what to do with the user's files. Remember that users may have files outside their home directories. The find command can find them:
You can then decide whether to delete these files or keep them. If you decide to delete them, back them up in case you need data from them later.
As extra security, you can change the user's login shell to a dummy value. Simply change the last field in the passwd file to /bin/false.
If your organization uses Secure Shell (SSH, usually provided on Linux by OpenSSH-server) and you allow remote RSA or DSA key authentication, a user can get access to your system even if his password is disabled. This is because SSH uses separate keys.
For instance, even after you have disabled Tom Adelstein's password, he can get on another computer somewhere and run a command such as:
$ 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 server.
Obviously, if your system offers SSH, you should remove authorized keys from the appropriate directories (e.g., ~tadelste/.ssh or .~tadelste/.ssh2) in order to stop the user from regaining access to his account this way:
:~/.ssh$ ls authorized_keys known_hosts :~/.ssh$ rm authorized_keys
Likewise, look for .shosts and .rhosts files in the user's home directory (for example, ~tadelste/.shosts and ~tadelste/.rhosts).
Also, check to see if the user still has any processes running on the system. Such processes might act as a backdoor to allow the user into your network. The following command will tell you if a user currently has any running processes:
Some other questions a system administrator might ask about a personal user who has left the company include:
• Could the user execute CGI scripts from his home directory or on one of the company's web servers?
• Do any email forwarding files such as ~tadelste/.forward exist? Users can use forwarders to send mail to their accounts and cause programs to be executed on the system where they supposedly do not have access.
Was this article helpful?