Removing A User - Page 2

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

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.

Share this page:

14 Comment(s)

Add comment


From: Anonymous at: 2006-04-05 23:38:46

I'm still reading through the article, but for step three I've allways used:


I'm not sure if all distro's use this but all the ones I administer do.


From: jack at: 2009-06-01 19:07:25

Very good article...


From: Anonymous at: 2006-04-06 13:33:11

You can change the user's shell without editting the /etc/passwd file by hand, using "chsh -s /path/to/shell userid" (e.g., "chsh -s /dev/null bwilson"). Thanks for the list, there was one I had left out of my own user_delete script!

From: Aji Prabowo at: 2011-05-20 11:52:41

Permission to repost it in my blog. Looking forward to have your visit.

Thank you.

From: Anonymous at: 2006-04-04 16:40:07

It is a good idea to disable bwilson on samba, by issuing a

smbpasswd -d bwilson

From: Anonymous at: 2006-04-05 21:10:56

In some organizations at least there are some common accounts that are setup so that any user who needs to use the accounts gets his/her ssh public key appended to the common user's authorized_keys. You need to find and delete these as well.

From: Anonymous at: 2006-04-05 18:33:09

Use ldap to provide authenication data for everything that you can. Write a script to automate the creation and deletion (archiving) of accounts.

From: Anonymous at: 2006-04-05 18:44:16

LDAP is also popular, and should not be neglected. I would recommend that the user's ldap password get locked, or even have the user deleted from LDAP as well.

Interestingly, this site (run on Drupal) would still have Mr. Wilson's user/pass, so don't forget to remove him from such applications as Dotproject, SugarCRM (all those client phone #s) or other internet available sites.

From: Anonymous at: 2006-04-05 18:58:26

You neglected to mention changing all passwords for profile accounts the user had access to. If bwilson was a dba who knew the database's root password it needs to be changed also.

From: Anonymous at: 2006-04-05 19:05:44

I think doing mv /home/bwilson /home/bwilson.locked is sufficient to disallow use of SSH keys as a way to login.

So no need to do booth ?

From: Anonymous at: 2006-04-05 23:51:44

Some distributions create a specific group for every user (usually with the same name). Be sure to remove those as well.

From: Anonymous at: 2006-04-06 01:45:45

You 'll also want to reload the privileges after the revoke command:

# mysql -u root -p

From: Anonymous at: 2006-04-06 19:40:54

Reading this makes me think about how difficult linux really is. Maybe it is time for a new linux-distro with builtin ldap(??) where all identification was made up against. Easy to create a user and easy to delete.


From: Anonymous at: 2006-04-07 12:42:52

Also watch out for firewall and /etc/hosts.* entries that may allow the employee direct external access from a fixed IP address (DSL/cable) or using VPN/IPSEC tunnels.

Reset all root passwords, but also passwords belonging to accounts that may be escalated to root (like the wheel accounts on *BSD).